-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
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.
should be fixed by |
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
Taken from
gcc.c-torture/execute/20000822-1.c
:Can be further reduced to:
The text was updated successfully, but these errors were encountered: