Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: fixup must be 8-byte aligned #11

Closed
fxcoudert opened this issue Aug 31, 2020 · 1 comment
Closed

error: fixup must be 8-byte aligned #11

fxcoudert opened this issue Aug 31, 2020 · 1 comment

Comments

@fxcoudert
Copy link
Contributor

Taken from gcc.c-torture/execute/20000822-1.c:

$ cat 20000822-1.c 
#include <stdlib.h>

int f0(int (*fn)(int *), int *p) { return (*fn) (p); }

int f1(void) {
  int i = 0;
  int f2(int *p) {
    i = 1;
    return *p + 1;
  }
  return f0(f2, &i);
}

int main() {
  if (f1() != 2)
    abort ();
}
$ ./bin/gcc 20000822-1.c
/var/folders/5b/7mrgq6j55b51p7ztj1r3gv400000gq/T//cc8QdllL.s:70:2: error: fixup must be 8-byte aligned
        ldr     x2, [x1, LTRAMP0@GOTPAGEOFF];momd
        ^

Can be further reduced to:

$ cat a.c
int f0(int (*fn)()) { return 0; }
int f1() {
  int f2() { return 1; }
  return f0(f2);
}
$ ./bin/gcc a.c
/var/folders/5b/7mrgq6j55b51p7ztj1r3gv400000gq/T//cczkuEjo.s:55:2: error: fixup must be 8-byte aligned
        ldr     x2, [x1, LTRAMP0@GOTPAGEOFF];momd
        ^
iains added a commit that referenced this issue Sep 2, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
@iains
Copy link
Owner

iains commented Sep 2, 2020

should be fixed by

9a40d27

@iains iains closed this as completed Sep 2, 2020
iains added a commit that referenced this issue Sep 5, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 7, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 12, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 25, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 29, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Oct 4, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Oct 12, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Oct 17, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Oct 25, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 1, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 7, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 15, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 22, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 29, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Dec 6, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Dec 6, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Dec 19, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Dec 20, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Dec 26, 2020
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jan 4, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
omus pushed a commit to omus/gcc-darwin-arm64 that referenced this issue Jan 27, 2021
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue iains#11.
omus pushed a commit to omus/gcc-darwin-arm64 that referenced this issue Jan 27, 2021
Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue iains#11.
iains pushed a commit that referenced this issue Jun 18, 2021
The fixed error is:

==21166==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs operator delete) on 0x60300000d900
    #0 0x7367d7 in operator delete(void*, unsigned long) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/libsanitizer/asan/asan_new_delete.cpp:172
    #1 0x3b82e6e in pointer_equiv_analyzer::~pointer_equiv_analyzer() /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/gimple-ssa-evrp.c:161
    #2 0x3b83387 in hybrid_folder::~hybrid_folder() /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/gimple-ssa-evrp.c:517
    #3 0x3b83387 in execute_early_vrp /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/gimple-ssa-evrp.c:686
    #4 0x1790611 in execute_one_pass(opt_pass*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2567
    #5 0x1792003 in execute_pass_list_1 /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2656
    #6 0x1792029 in execute_pass_list_1 /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2657
    #7 0x179209f in execute_pass_list(function*, opt_pass*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2667
    #8 0x178a5f3 in do_per_function_toporder(void (*)(function*, void*), void*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:1773
    #9 0x1792fac in do_per_function_toporder(void (*)(function*, void*), void*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/plugin.h:191
    #10 0x1792fac in execute_ipa_pass_list(opt_pass*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:3001
    #11 0xc525fc in ipa_passes /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2154
    #12 0xc525fc in symbol_table::compile() /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2289
    #13 0xc5a096 in symbol_table::compile() /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2269
    #14 0xc5a096 in symbol_table::finalize_compilation_unit() /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2537
    #15 0x1a7a17c in compile_file /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:482
    #16 0x69c758 in do_compile /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:2210
    #17 0x69c758 in toplev::main(int, char**) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:2349
    #18 0x6a932a in main /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/main.c:39
    #19 0x7ffff7820b34 in __libc_start_main ../csu/libc-start.c:332
    #20 0x6aa5fd in _start (/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/gcc/cc1+0x6aa5fd)

0x60300000d900 is located 0 bytes inside of 32-byte region [0x60300000d900,0x60300000d920)
allocated by thread T0 here:
    #0 0x735ab7 in operator new[](unsigned long) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/libsanitizer/asan/asan_new_delete.cpp:102
    #1 0x3b82dac in pointer_equiv_analyzer::pointer_equiv_analyzer(gimple_ranger*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/gimple-ssa-evrp.c:156

gcc/ChangeLog:

	* gimple-ssa-evrp.c (pointer_equiv_analyzer::~pointer_equiv_analyzer): Use delete[].
iains added a commit that referenced this issue Jun 18, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jun 21, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jun 27, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jul 4, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jul 11, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Jul 19, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Aug 2, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Aug 14, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Aug 22, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Aug 30, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 6, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Sep 26, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
Alphadelta14 pushed a commit to Alphadelta14/gcc-darwin-arm64 that referenced this issue Oct 18, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue iains#11.
iains added a commit that referenced this issue Oct 28, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 6, 2021
For Arm64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11.
iains added a commit that referenced this issue Nov 7, 2021
For aarch64, the alignment of the LTRAMPn symbols matters.

Actually, the LTRAMPn  symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).

The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.

Fixes issue #11 on the development branch.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

gcc/ChangeLog:

	* config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Add LTRAMP
	to the list of symbol prefixes that must be made linker-
	visible.
iains pushed a commit that referenced this issue Jan 2, 2022
…imize or target pragmas [PR103012]

The following testcases ICE when an optimize or target pragma
is followed by a long line (4096+ chars).
This is because on such long lines we can't use columns anymore,
but the cpp_define calls performed by c_cpp_builtins_optimize_pragma
or from the backend hooks for target pragma are done on temporary
buffers and expect to get columns from whatever line they appear on
(which happens to be the long line after optimize/target pragma),
and we run into:
 #0  fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986
 #1  0x0000000002e7c335 in linemap_add (set=0x7ffff7fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502
 #2  0x0000000002e7cc24 in linemap_line_start (set=0x7ffff7fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827
 #3  0x0000000002e7ce2b in linemap_position_for_column (set=0x7ffff7fca000, to_column=1) at ../../libcpp/line-map.c:898
 #4  0x0000000002e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592
 #5  0x0000000002e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394
 #6  0x0000000002e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601
 #7  0x0000000002e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639
 #8  0x0000000002e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffffffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589
 #9  0x0000000002e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513
 #10 0x0000000002e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522
 #11 0x0000000000f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=<optimization_node 0x7fffea042000>, cur_tree=<optimization_node 0x7fffea042020>)
     at ../../gcc/c-family/c-cppbuiltin.c:600
assertion that LC_RENAME doesn't happen first.

I think the right fix is emit those predefined macros upon
optimize/target pragmas with BUILTINS_LOCATION, like we already do
for those macros at the start of the TU, they don't appear in columns
of the next line after it.  Another possibility would be to force them
at the location of the pragma.

2021-12-30  Jakub Jelinek  <jakub@redhat.com>

	PR c++/103012
gcc/
	* config/i386/i386-c.c (ix86_pragma_target_parse): Perform
	cpp_define/cpp_undef calls with forced token locations
	BUILTINS_LOCATION.
	* config/arm/arm-c.c (arm_pragma_target_parse): Likewise.
	* config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Likewise.
	* config/s390/s390-c.c (s390_pragma_target_parse): Likewise.
gcc/c-family/
	* c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Perform
	cpp_define_unused/cpp_undef calls with forced token locations
	BUILTINS_LOCATION.
gcc/testsuite/
	PR c++/103012
	* g++.dg/cpp/pr103012.C: New test.
	* g++.target/i386/pr103012.C: New test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants