[Bug c++/112899] odr-using constexpr static data member of class exported from module results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 CC||nshead at gcc dot gnu.org Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #4 from Nathaniel Shead --- Fixed for GCC 14. (Specifics may need to be revisited depending on https://github.com/itanium-cxx-abi/cxx-abi/issues/170.)
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112899, which changed state. Bug 112899 Summary: odr-using constexpr static data member of class exported from module results in linker error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113405, which changed state. Bug 113405 Summary: Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/109679] export using for functions does not work as specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |14.0 CC||nshead at gcc dot gnu.org --- Comment #5 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 109679, which changed state. Bug 109679 Summary: export using for functions does not work as specified https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/110808] [modules] Internal Compiler Error in check_mergeable_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110808 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Keywords|ice-on-valid-code |ice-on-invalid-code Resolution|--- |FIXED --- Comment #3 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 110808, which changed state. Bug 110808 Summary: [modules] Internal Compiler Error in check_mergeable_decl https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110808 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/112820] vtable not emitted correctly from module when compiling with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112820 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #4 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112820, which changed state. Bug 112820 Summary: vtable not emitted correctly from module when compiling with -g https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112820 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 102607, which changed state. Bug 102607 Summary: [modules] option -g results in undefined reference to `typeinfo for type` https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102607 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/102607] [modules] option -g results in undefined reference to `typeinfo for type`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102607 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED CC||nshead at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #3 from Nathaniel Shead --- Fixed for GCC 14.
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 --- Comment #5 from Zdenek Sojka --- (In reply to Jakub Jelinek from comment #4) > Created attachment 57221 [details] > gcc14-pr113604.patch > > Untested fix. I've tried to explain what's going on in the large comment. I can confirm this fixes the testcase and other 3 testcases I have locally.
[Bug c++/113129] "using declaration" not detected as "exported" in exported namespace (C++ modules)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 Nathaniel Shead changed: What|Removed |Added Status|WAITING |RESOLVED CC||nshead at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Nathaniel Shead --- *** This bug has been marked as a duplicate of bug 109679 ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113129, which changed state. Bug 113129 Summary: "using declaration" not detected as "exported" in exported namespace (C++ modules) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/109679] export using for functions does not work as specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 --- Comment #6 from Nathaniel Shead --- *** Bug 113129 has been marked as a duplicate of this bug. ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112588, which changed state. Bug 112588 Summary: [modules] ICE in make_decl_rtl when returning str literal when string header imported in module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/112588] [modules] ICE in make_decl_rtl when returning str literal when string header imported in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||ice-on-valid-code Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/113292] [modules] internal error when compiling header to module containing static thread_local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113292 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||ice-on-valid-code Blocks||103524 Resolution|--- |FIXED CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #2 from Nathaniel Shead --- Fixed for GCC 14. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113292, which changed state. Bug 113292 Summary: [modules] internal error when compiling header to module containing static thread_local variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113292 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 --- Comment #6 from Jakub Jelinek --- (In reply to Zdenek Sojka from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Created attachment 57221 [details] > > gcc14-pr113604.patch > > > > Untested fix. I've tried to explain what's going on in the large comment. > > I can confirm this fixes the testcase and other 3 testcases I have locally. If you could upload those 3 (even when not reduced), I'd appreciate it, so that we get better divmod coverage; I could turn it just into a single test checking all 3 or how many divisions (or modulo operations).
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #14 from Roger Sayle ---
My apologies for not keeping folks updated on my thinking. Following Oleg's
feedback, I've decided to slim down my proposed fix to the bare minimum, and
postpone the other rtx_costs improvements until GCC 15 (or later), when I'll
have more time to use to CSiBE to demonstrate the benefits/tradeoffs for -Os
and -Oz. For example, with fwprop about to transition to insn_cost, it would
be good for the SH backend to provide a sh_insn_cost target hook.
The current minimal patch to fix this specific regression is:
diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 2c411c3..fba6c0fd465 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -3313,7 +3313,8 @@ sh_rtx_costs (rtx x, machine_mode mode ATTRIBUTE_UNUSED,
i
nt outer_code,
{
*total = sh_address_cost (XEXP (XEXP (x, 0), 0),
GET_MODE (XEXP (x, 0)),
- MEM_ADDR_SPACE (XEXP (x, 0)), true);
+ MEM_ADDR_SPACE (XEXP (x, 0)), true)
+ + COSTS_N_INSNS (1);
return true;
}
return false;
The minor complication is that as explained above this results in:
PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times addc 6
PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times cmp/pz 25
PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times shll 3
PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times subc 14
which were failures that were fixed (or silenced) by my solution to PR111267.
I will note that although the scan-assembler-times complain, that this
tweak to sh_rtx_costs reduces the total number of instructions in pr59533-1.c
which (normally) indicates that its an improvement.
*** old.s Thu Jan 25 22:54:11 2024
--- new.s Thu Jan 25 22:54:23 2024
***
*** 15,23
.global test_01
.type test_01, @function
test_01:
- mov.b @r4,r0
- extu.b r0,r0
mov.b @r4,r1
cmp/pz r1
mov #0,r1
rts
--- 15,22
.global test_01
.type test_01, @function
test_01:
mov.b @r4,r1
+ extu.b r1,r0
cmp/pz r1
mov #0,r1
rts
...
Hence I'm looking into PR59533, which has separate tests for sh2a and !sh2a,
and my latest discoveries are the -m2a isn't supported if I build gcc using
--target=sh3-linux-gnu, and that --target=sh2a-linux-gnu doesn't automatically
default to --target=sh2aeb-linux-gnu and instead gives a fatal error about
"SH2A does not support little-endian" during the build. All part (joy?) of the
learning curve.
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2023-11-13 00:00:00 |2024-1-27 --- Comment #5 from Iain Sandoe --- however, as of r14-8436-gf03b8f595b6350 on a case sensitive source partition the clock-related tests still fail. === gm2 tests === Running target unix FAIL: gm2/iso/run/pass/m2date.mod execution, -g FAIL: gm2/iso/run/pass/m2date.mod execution, -O FAIL: gm2/iso/run/pass/m2date.mod execution, -O -g FAIL: gm2/iso/run/pass/m2date.mod execution, -Os FAIL: gm2/iso/run/pass/m2date.mod execution, -O3 -fomit-frame-pointer FAIL: gm2/iso/run/pass/m2date.mod execution, -O3 -fomit-frame-pointer -finline-functions FAIL: gm2/iso/run/pass/testclock.mod execution, -g FAIL: gm2/iso/run/pass/testclock.mod execution, -O FAIL: gm2/iso/run/pass/testclock.mod execution, -O -g FAIL: gm2/iso/run/pass/testclock.mod execution, -Os FAIL: gm2/iso/run/pass/testclock.mod execution, -O3 -fomit-frame-pointer FAIL: gm2/iso/run/pass/testclock.mod execution, -O3 -fomit-frame-pointer -finline-functions === gm2 Summary === # of expected passes13016 # of unexpected failures12
[Bug tree-optimization/113568] ICE: definition in block 13 does not dominate use in block 15 with _BitInt() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113568 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3f5ac4696351c352980f8cd1b063df89894549c2 commit r14-8467-g3f5ac4696351c352980f8cd1b063df89894549c2 Author: Jakub Jelinek Date: Sat Jan 27 13:06:17 2024 +0100 lower-bitint: Fix up VIEW_CONVERT_EXPR handling in lower_mergeable_stmt [PR113568] We generally allow merging mergeable stmts with some final cast (but not further casts or mergeable operations after the cast). As some casts are handled conditionally, if (idx < cst) handle_operand (idx); else if idx == cst) handle_operand (cst); else ..., we must sure that e.g. the mergeable PLUS_EXPR/MINUS_EXPR/NEGATE_EXPR never appear in handle_operand called from such casts, because it ICEs on invalid SSA_NAME form (that part could be fixable by adding further PHIs) but also because we'd need to correctly propagate the overflow flags from the if to else if. So, instead lower_mergeable_stmt handles an outermost widening cast (or widening cast feeding outermost store) specially. The problem was similar to PR113408, that VIEW_CONVERT_EXPR tree is present in the gimple_assign_rhs1 while it is not for NOP_EXPR/CONVERT_EXPR, so the checks whether the outermost cast should be handled didn't handle the VCE case and so handle_plus_minus was called from the conditional handle_cast. 2024-01-27 Jakub Jelinek PR tree-optimization/113568 * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt): For VIEW_CONVERT_EXPR use first operand of rhs1 instead of rhs1 in the widening extension checks. * gcc.dg/bitint-78.c: New test.
[Bug tree-optimization/113614] wrong code with _BitInt() division at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113614 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a12b0e9360e88fceb0414bfb34c8c1ad87c5ac90 commit r14-8468-ga12b0e9360e88fceb0414bfb34c8c1ad87c5ac90 Author: Jakub Jelinek Date: Sat Jan 27 13:06:55 2024 +0100 lower-bitint: Avoid sign-extending cast to unsigned types feeding div/mod/float [PR113614] The following testcase is miscompiled, because some narrower value is sign-extended to wider unsigned _BitInt used as division operand. handle_operand_addr for that case returns the narrower value and precision -prec_of_narrower_value. That works fine for multiplication (at least, normal multiplication, but we don't merge casts with .MUL_OVERFLOW or the ubsan multiplication right now), because the result is the same whether we treat the arguments as signed or unsigned. But is completely wrong for division/modulo or conversions to floating-point, if we pass negative prec for an input operand of a libgcc handler, those treat it like a negative number, not an unsigned one sign-extended from something smaller (and it doesn't know to what precision it has been extended). So, the following patch fixes it by making sure we don't merge such sign-extensions to unsigned _BitInt type with division, modulo or conversions to floating point. 2024-01-27 Jakub Jelinek PR tree-optimization/113614 * gimple-lower-bitint.cc (gimple_lower_bitint): Don't merge widening casts from signed to unsigned types with TRUNC_DIV_EXPR, TRUNC_MOD_EXPR or FLOAT_EXPR uses. * gcc.dg/torture/bitint-54.c: New test.
[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622 --- Comment #8 from Jakub Jelinek --- Guess for an rvalue (if even that crashes) we want to expand it to some permutation or whole vector shift which moves the indexed elements first and then extract it, for lvalue we need to insert it similarly.
[Bug tree-optimization/113568] ICE: definition in block 13 does not dominate use in block 15 with _BitInt() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113568 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/113614] wrong code with _BitInt() division at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113614 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/103503] RFE: no save registers attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503 --- Comment #6 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a96549dce7636edfc693bf758ef27fcd8adc6161 commit r14-8469-ga96549dce7636edfc693bf758ef27fcd8adc6161 Author: H.J. Lu Date: Tue Jan 23 06:59:50 2024 -0800 x86: Add no_callee_saved_registers function attribute When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C function. 3. Restore all registers. 4. Return from interrupt. it is completely unnecessary to save and restore any registers in the C function called by the assembly stub, even if they would normally be callee-saved. Add no_callee_saved_registers function attribute, which is complementary to no_caller_saved_registers function attribute, to mark a function which doesn't have any callee-saved registers. Such a function won't save and restore any registers. Classify function call-saved register handling type with: 1. Default call-saved registers. 2. No caller-saved registers with no_caller_saved_registers attribute. 3. No callee-saved registers with no_callee_saved_registers attribute. Disallow sibcall if callee is a no_callee_saved_registers function and caller isn't a no_callee_saved_registers function. Otherwise, callee-saved registers won't be preserved. After a no_callee_saved_registers function is called, all registers may be clobbered. If the calling function isn't a no_callee_saved_registers function, we need to preserve all registers which aren't used by function calls. gcc/ PR target/103503 PR target/113312 * config/i386/i386-expand.cc (ix86_expand_call): Replace no_caller_saved_registers check with call_saved_registers check. Clobber all registers that are not used by the callee with no_callee_saved_registers attribute. * config/i386/i386-options.cc (ix86_set_func_type): Set call_saved_registers to TYPE_NO_CALLEE_SAVED_REGISTERS for noreturn function. Disallow no_callee_saved_registers with interrupt or no_caller_saved_registers attributes together. (ix86_set_current_function): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_handle_no_caller_saved_registers_attribute): Renamed to ... (ix86_handle_call_saved_registers_attribute): This. (ix86_gnu_attributes): Add ix86_handle_call_saved_registers_attribute. * config/i386/i386.cc (ix86_conditional_register_usage): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_function_ok_for_sibcall): Don't allow callee with no_callee_saved_registers attribute when the calling function has callee-saved registers. (ix86_comp_type_attributes): Also check no_callee_saved_registers. (ix86_epilogue_uses): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_hard_regno_scratch_ok): Likewise. (ix86_save_reg): Replace no_caller_saved_registers check with call_saved_registers check. Don't save any registers for TYPE_NO_CALLEE_SAVED_REGISTERS. Save all registers with TYPE_DEFAULT_CALL_SAVED_REGISTERS if function with no_callee_saved_registers attribute is called. (find_drap_reg): Replace no_caller_saved_registers check with call_saved_registers check. * config/i386/i386.h (call_saved_registers_type): New enum. (machine_function): Replace no_caller_saved_registers with call_saved_registers. * doc/extend.texi: Document no_callee_saved_registers attribute. gcc/testsuite/ PR target/103503 PR target/113312 * gcc.dg/torture/no-callee-saved-run-1a.c: New file. * gcc.dg/torture/no-callee-saved-run-1b.c: Likewise. * gcc.target/i386/no-callee-saved-1.c: Likewise. * gcc.target/i386/no-callee-saved-2.c: Likewise. * gcc.target/i386/no-callee-saved-3.c: Likewise. * gcc.target/i386/no-callee-saved-4.c: Likewise. * gcc.target/i386/no-callee-saved-5.c: Likewise. * gcc.target/i386/no-callee-saved-6.c: Likewise. * gcc.target/i386/no-callee-saved-7.c: Likewise. * gcc.target/i386/no-callee-saved-8.c: Likewise. * gcc.target/i386/no-callee-saved-9.c: Likewise. * gcc.target/i386/no-callee-saved-10.c: Likewise. * gcc.target/i386/no-callee-saved-11.c: Likewise. * gcc.target/i386/no-callee-saved-12.c: Likewise. * gcc.target/i386/no-callee-saved-13.c: Likewise. * gcc.target/i386/n
[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #27 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a96549dce7636edfc693bf758ef27fcd8adc6161 commit r14-8469-ga96549dce7636edfc693bf758ef27fcd8adc6161 Author: H.J. Lu Date: Tue Jan 23 06:59:50 2024 -0800 x86: Add no_callee_saved_registers function attribute When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C function. 3. Restore all registers. 4. Return from interrupt. it is completely unnecessary to save and restore any registers in the C function called by the assembly stub, even if they would normally be callee-saved. Add no_callee_saved_registers function attribute, which is complementary to no_caller_saved_registers function attribute, to mark a function which doesn't have any callee-saved registers. Such a function won't save and restore any registers. Classify function call-saved register handling type with: 1. Default call-saved registers. 2. No caller-saved registers with no_caller_saved_registers attribute. 3. No callee-saved registers with no_callee_saved_registers attribute. Disallow sibcall if callee is a no_callee_saved_registers function and caller isn't a no_callee_saved_registers function. Otherwise, callee-saved registers won't be preserved. After a no_callee_saved_registers function is called, all registers may be clobbered. If the calling function isn't a no_callee_saved_registers function, we need to preserve all registers which aren't used by function calls. gcc/ PR target/103503 PR target/113312 * config/i386/i386-expand.cc (ix86_expand_call): Replace no_caller_saved_registers check with call_saved_registers check. Clobber all registers that are not used by the callee with no_callee_saved_registers attribute. * config/i386/i386-options.cc (ix86_set_func_type): Set call_saved_registers to TYPE_NO_CALLEE_SAVED_REGISTERS for noreturn function. Disallow no_callee_saved_registers with interrupt or no_caller_saved_registers attributes together. (ix86_set_current_function): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_handle_no_caller_saved_registers_attribute): Renamed to ... (ix86_handle_call_saved_registers_attribute): This. (ix86_gnu_attributes): Add ix86_handle_call_saved_registers_attribute. * config/i386/i386.cc (ix86_conditional_register_usage): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_function_ok_for_sibcall): Don't allow callee with no_callee_saved_registers attribute when the calling function has callee-saved registers. (ix86_comp_type_attributes): Also check no_callee_saved_registers. (ix86_epilogue_uses): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_hard_regno_scratch_ok): Likewise. (ix86_save_reg): Replace no_caller_saved_registers check with call_saved_registers check. Don't save any registers for TYPE_NO_CALLEE_SAVED_REGISTERS. Save all registers with TYPE_DEFAULT_CALL_SAVED_REGISTERS if function with no_callee_saved_registers attribute is called. (find_drap_reg): Replace no_caller_saved_registers check with call_saved_registers check. * config/i386/i386.h (call_saved_registers_type): New enum. (machine_function): Replace no_caller_saved_registers with call_saved_registers. * doc/extend.texi: Document no_callee_saved_registers attribute. gcc/testsuite/ PR target/103503 PR target/113312 * gcc.dg/torture/no-callee-saved-run-1a.c: New file. * gcc.dg/torture/no-callee-saved-run-1b.c: Likewise. * gcc.target/i386/no-callee-saved-1.c: Likewise. * gcc.target/i386/no-callee-saved-2.c: Likewise. * gcc.target/i386/no-callee-saved-3.c: Likewise. * gcc.target/i386/no-callee-saved-4.c: Likewise. * gcc.target/i386/no-callee-saved-5.c: Likewise. * gcc.target/i386/no-callee-saved-6.c: Likewise. * gcc.target/i386/no-callee-saved-7.c: Likewise. * gcc.target/i386/no-callee-saved-8.c: Likewise. * gcc.target/i386/no-callee-saved-9.c: Likewise. * gcc.target/i386/no-callee-saved-10.c: Likewise. * gcc.target/i386/no-callee-saved-11.c: Likewise. * gcc.target/i386/no-callee-saved-12.c: Likewise. * gcc.target/i386/no-callee-saved-13.c: Likewise. * gcc.target/i386/
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #15 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d commit r14-8470-g7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d Author: H.J. Lu Date: Tue Jan 23 06:59:51 2024 -0800 x86: Don't save callee-saved registers in noreturn functions There is no need to save callee-saved registers in noreturn functions if they don't throw nor support exceptions. We can treat them the same as functions with no_callee_saved_registers attribute. Adjust stack-check-17.c for noreturn function which no longer saves any registers. With this change, __libc_start_main in glibc 2.39, which is a noreturn function, is changed from __libc_start_main: endbr64 push %r15 push %r14 mov%rcx,%r14 push %r13 push %r12 push %rbp mov%esi,%ebp push %rbx mov%rdx,%rbx sub$0x28,%rsp mov%rdi,(%rsp) mov%fs:0x28,%rax mov%rax,0x18(%rsp) xor%eax,%eax test %r9,%r9 to __libc_start_main: endbr64 sub$0x28,%rsp mov%esi,%ebp mov%rdx,%rbx mov%rcx,%r14 mov%rdi,(%rsp) mov%fs:0x28,%rax mov%rax,0x18(%rsp) xor%eax,%eax test %r9,%r9 In Linux kernel 6.7.0 on x86-64, do_exit is changed from do_exit: endbr64 call push %r15 push %r14 push %r13 push %r12 mov%rdi,%r12 push %rbp push %rbx mov%gs:0x0,%rbx sub$0x28,%rsp mov%gs:0x28,%rax mov%rax,0x20(%rsp) xor%eax,%eax call *0x0(%rip)# test $0x2,%ah je to do_exit: endbr64 call sub$0x28,%rsp mov%rdi,%r12 mov%gs:0x28,%rax mov%rax,0x20(%rsp) xor%eax,%eax mov%gs:0x0,%rbx call *0x0(%rip)# test $0x2,%ah je I compared GCC master branch bootstrap and test times on a slow machine with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13 with the backported patch. The performance data isn't precise since the measurements were done on different days with different GCC sources under different 6.6 kernel versions. GCC master branch build time in seconds: beforeafter improvement 30043.75user 30013.16user 0% 1274.85system 1243.72system 2.4% GCC master branch test time in seconds (new tests added): beforeafter improvement 216035.90user 216547.51user 0 27365.51system26658.54system 2.6% gcc/ PR target/38534 * config/i386/i386-options.cc (ix86_set_func_type): Don't save and restore callee saved registers for a noreturn function with nothrow or compiled with -fno-exceptions. gcc/testsuite/ PR target/38534 * gcc.target/i386/pr38534-1.c: New file. * gcc.target/i386/pr38534-2.c: Likewise. * gcc.target/i386/pr38534-3.c: Likewise. * gcc.target/i386/pr38534-4.c: Likewise. * gcc.target/i386/stack-check-17.c: Updated.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 57238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57238&action=edit gcc14-pr110603.patch Untested fix.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Won't this screw up backtrace calls in such functions, or __builtin_frame_address calls, or backtraces in debugger and other tools?
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:7a525d23aad8bf2f4db37f384c331af1abf7f103 commit r11-11213-g7a525d23aad8bf2f4db37f384c331af1abf7f103 Author: Lewis Hyatt Date: Tue Dec 5 11:33:39 2023 -0500 c-family: Fix ICE with large column number after restoring a PCH [PR105608] Users are allowed to define macros prior to restoring a precompiled header file, as long as those macros are not defined (or are defined identically) in the PCH. However, the PCH restoration process destroys all the macro definitions, so libcpp has to record them before restoring the PCH and then redefine them afterward. This process does not currently assign great locations to the macros after redefining them. Some work is needed to also remember the original locations and get the line_maps instance in the right state (since, like all other data structures, the line_maps instance is also reset after restoring a PCH). This patch addresses a more pressing issue, which is that we ICE in some cases since GCC 11, hitting an assert in line-maps.cc. It happens if the first line encountered after the PCH restore requires an LC_RENAME map, such as will happen if the line is sufficiently long. This is much easier to fix, since we just need to call linemap_line_start before asking libcpp to redefine the stored macros, instead of afterward, to avoid the unexpected need for an LC_RENAME before an LC_ENTER has been seen. gcc/c-family/ChangeLog: PR preprocessor/105608 * c-pch.c (c_common_read_pch): Start a new line map before asking libcpp to restore macros defined prior to reading the PCH, instead of afterward. gcc/testsuite/ChangeLog: PR preprocessor/105608 * g++.dg/pch/line-map-1.C: New test. * g++.dg/pch/line-map-1.Hs: New test. * g++.dg/pch/line-map-2.C: New test. * g++.dg/pch/line-map-2.Hs: New test.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #17 from Jakub Jelinek --- E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we somehow indicate in DWARF unwind info that the callee saved registers weren't saved and were clobbered? Even if backtrace itself still works make it clear that if debugger unwinds to caller frame that certain registers have unknown values rather than the restored ones.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #18 from H.J. Lu --- (In reply to Jakub Jelinek from comment #17) > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we We can disable this for -O0 and -Og. > somehow indicate in DWARF unwind info that the callee saved registers > weren't saved and were clobbered? Even if backtrace itself still works make Is there such a DWARF bit? > it clear that if debugger unwinds to caller frame that certain registers > have unknown values rather than the restored ones.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #19 from Jakub Jelinek --- (In reply to H.J. Lu from comment #18) > (In reply to Jakub Jelinek from comment #17) > > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we > > We can disable this for -O0 and -Og. I think we should go for that. > > somehow indicate in DWARF unwind info that the callee saved registers > > weren't saved and were clobbered? Even if backtrace itself still works make > > Is there such a DWARF bit? There is the undefined state (DW_CFA_undefined, .cfi_undefined directive in gas). But DWARF says undefined is the default state unless an ABI specifies something else for certain registers (or unless overridden in CIE or FDE), so I must say I don't remember what is done usually and whether the default state isn't what is enough. But it would really surprise me if the call saved registers weren't treated as same_value at the start of the function and I believe nothing emits DW_CFA_same_value in the CIEs.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 Jakub Jelinek changed: What|Removed |Added CC||aburgess at redhat dot com, ||blarsen at redhat dot com, ||kevinb at redhat dot com, ||tromey at gcc dot gnu.org --- Comment #20 from Jakub Jelinek --- Guess we should CC some GDB people on this.
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 --- Comment #7 from Zdenek Sojka --- Created attachment 57239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57239&action=edit testcase2 (not beautified)
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 --- Comment #8 from Zdenek Sojka --- Created attachment 57240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57240&action=edit testcase3 (not beautified)
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 --- Comment #9 from Zdenek Sojka --- Created attachment 57241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57241&action=edit testcase4 (not beautified)
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604 Zdenek Sojka changed: What|Removed |Added Attachment #57239|0 |1 is obsolete|| --- Comment #10 from Zdenek Sojka --- Created attachment 57242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57242&action=edit testcase5 (not beautified)
[Bug sanitizer/113628] New: -fsanitize=undefined failed to check a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113628
Bug ID: 113628
Summary: -fsanitize=undefined failed to check a signed integer
overflow
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jiajing_zheng at 163 dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
The following two files are equivalent(I took a motion of the loop invariant
expression of source.c and got mutation.c).
I checked both files using -fsanitize=undefined and the results showed that
'signed integer overflow' was given for mutation.c, but this message was
missing for source.c. This is the case in both release version 12.2.0 and
version 13.2.0.
jing@jing-ubuntu:~$ cat source.c
static int g_3 = 0b110001111011101101110111;
static char g_51 = 2L;
static unsigned char g_106 = 252UL;
inline static void func_1(void) {
int i;
for (i = 0; i < 1; i++) {
// source statement:
g_3 *= (g_106 / (g_51 ? g_51 : 16653417461)) | (g_51 & g_3) + g_3;
}
for (g_3 = (-6); (g_3 != 29); ++g_3) {
}
}
int main(void) {
func_1();
return 0;
}
jing@jing-ubuntu:~/Desktop/issue$ cat mutation.c
static int g_3 = 0b110001111011101101110111;
static char g_51 = 2L;
static unsigned char g_106 = 252UL;
inline static void func_1(void) {
int i;
// loop invariant motion:
int TVH = (g_106 / (g_51 ? g_51 : 16653417461));
for (i = 0; i < 1; i++) {
// mutation statement:
g_3 *= TVH | (g_51 & g_3) + g_3;
}
for (g_3 = (-6); (g_3 != 29); ++g_3) {
}
}
int main(void) {
func_1();
return 0;
}
results both in gcc version 12.2.0 and 13.2.0:
jing@jing-ubuntu:~$ gcc source.c -fsanitize=undefined -O0 && ./a.out
jing@jing-ubuntu:~$ gcc mutation.c -fsanitize=undefined -O0 && ./a.out
mutation.c:11:9: runtime error: signed integer overflow: -955533441 *
-955533501 cannot be represented in type 'int'
jing@jing-ubuntu:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jing/gcc-12.2.0/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
jing@jing-ubuntu:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jing/gcc-13.2.0-install/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/jing/gcc-13.2.0-install
--enable-threads=posix -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #21 from Andrew Burgess --- Setting to DW_CFA_undefined is the right thing to do. DWARF says: The DW_CFA_undefined instruction takes a single unsigned LEB128 operand that represents a register number. The required action is to set the rule for the specified register to “undefined.” which is exactly what you'd want here. GDB has a distinction between "unspecified" (not really a DWARF thing) and "undefined" (the DWARF thing). Registers that aren't given an initial state in the CIE start as "unspecified", the idea being (I believe) that we then apply some kind of ABI based rules on top. So an "unspecified" call-clobbered register would be treated as "undefined", while a callee-saved register would be treated as "same-value" to begin with. Setting a register to "undefined" in the DWARF should, I think, do what you want. At least, if it doesn't, I think that would be on GDB to fix. This is just my personal thoughts, others might disagree.
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617 --- Comment #13 from H.J. Lu --- A patch is posted at https://patchwork.sourceware.org/project/gcc/list/?series=30277
[Bug c++/113443] GCC rejects valid program involving parameter packs with in between class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443 --- Comment #4 from Jason Liam --- Clang has now fixed the issue https://github.com/llvm/llvm-project/issues/78449 So now only gcc rejects the valid program.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #22 from H.J. Lu --- Created attachment 57243 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57243&action=edit A patch to generate .cfi_undefined for unsaved callee-saved registers
[Bug sanitizer/113628] -fsanitize=undefined failed to check a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113628 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #1 from Harald van Dijk --- These two files are not equivalent. The equivalent would be long TVH = (g_106 / (g_51 ? g_51 : 16653417461)); because that is the type that subexpression has. The constant of type long causes everything to be promoted to long, and then finally truncated to int. That is well-defined. By making TVH an int, all the other operations are performed in type int as well.
[Bug c++/103994] Module ICE in write_var_def with global variable in global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994 --- Comment #3 from Patrick Palka --- We accept the comment #1 testcase after r14-6979, but still ICE on the original testcase: cfg.cc:5:9: internal compiler error: in insert, at cp/module.cc:4924 0x77357d trees_out::insert(tree_node*, walk_kind) /home/patrick/gcc/gcc/cp/module.cc:4924 0xb55c50 trees_out::decl_value(tree_node*, depset*) /home/patrick/gcc/gcc/cp/module.cc:7725 0xb5631a trees_out::decl_node(tree_node*, walk_kind) /home/patrick/gcc/gcc/cp/module.cc:8764 0xb57522 trees_out::tree_node(tree_node*) /home/patrick/gcc/gcc/cp/module.cc:9326 0xb5c9b5 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) /home/patrick/gcc/gcc/cp/module.cc:14898 0xb5e82e module_state::write_begin(elf_out*, cpp_reader*, module_state_config&, unsigned int&) /home/patrick/gcc/gcc/cp/module.cc:18084 0xb5f544 finish_module_processing(cpp_reader*) /home/patrick/gcc/gcc/cp/module.cc:20294 0xaeaea1 c_parse_final_cleanups() /home/patrick/gcc/gcc/cp/decl2.cc:5313 0xd31290 c_common_parse_file() /home/patrick/gcc/gcc/c-family/c-opts.cc:1319 \
[Bug c++/103994] Module ICE in write_var_def with global variable in global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-01-27
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Patrick Palka ---
Reduced testcase exhibiting the latest ICE:
$ cat 103994.H
template struct TransparentSupport {
template using key_arg = int;
};
template struct Map {
template
using key_arg = typename TransparentSupport::template
key_arg;
};
struct MapKey {
Map map_;
};
$ g++ -fmodule-header 103994.H
103994.H: internal compiler error: in insert, at cp/module.cc:4924
[Bug sanitizer/113628] -fsanitize=undefined failed to check a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113628 --- Comment #2 from Jiajing_Zheng --- (In reply to Harald van Dijk from comment #1) > These two files are not equivalent. The equivalent would be > long TVH = (g_106 / (g_51 ? g_51 : 16653417461)); > because that is the type that subexpression has. The constant of type long > causes everything to be promoted to long, and then finally truncated to int. > That is well-defined. By making TVH an int, all the other operations are > performed in type int as well. I'm sorry, I did overlook the type promotion. Thanks for your reply.
[Bug sanitizer/113628] -fsanitize=undefined failed to check a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113628 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- .
[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908 --- Comment #9 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ce61de1b8a1bb3a22118e900376f380768f2ba59 commit r14-8471-gce61de1b8a1bb3a22118e900376f380768f2ba59 Author: Harald Anlauf Date: Sat Jan 27 17:41:43 2024 +0100 Fortran: fix bounds-checking errors for CLASS array dummies [PR104908] Commit r11-1235 addressed issues with bounds of unlimited polymorphic array dummies. However, using the descriptor from sym->backend_decl does break the case of CLASS array dummies. The obvious solution is to restrict the fix to the unlimited polymorphic case, thus keeping the original descriptor in the ordinary case. gcc/fortran/ChangeLog: PR fortran/104908 * trans-array.cc (gfc_conv_array_ref): Restrict use of transformed descriptor (sym->backend_decl) to the unlimited polymorphic case. gcc/testsuite/ChangeLog: PR fortran/104908 * gfortran.dg/pr104908.f90: New test.
[Bug c++/113629] New: 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
Bug ID: 113629
Summary: 'deducing this' does not work with conversion
operators
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It seems that GCC's deducing this implementation has some issues with derived
classes that inherit from a base class that has conversion operators:
struct Base {
operator int(this auto&&) {
return 42;
}
};
struct Derived : Base {};
int main() {
Derived derived;
return static_cast(derived);
}
GCC rejects the above code with:
:11:10: error: invalid 'static_cast' from type 'Derived' to type 'int'
11 | return static_cast(derived);
| ^
which seems wrong.
[Bug c++/113629] 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629 --- Comment #1 from 康桓瑋 --- test: https://godbolt.org/z/jdz3ejohv
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:e8e584a81817713f98f16b2c81426905748237e3 commit r12-10118-ge8e584a81817713f98f16b2c81426905748237e3 Author: Lewis Hyatt Date: Tue Dec 5 11:33:39 2023 -0500 c-family: Fix ICE with large column number after restoring a PCH [PR105608] Users are allowed to define macros prior to restoring a precompiled header file, as long as those macros are not defined (or are defined identically) in the PCH. However, the PCH restoration process destroys all the macro definitions, so libcpp has to record them before restoring the PCH and then redefine them afterward. This process does not currently assign great locations to the macros after redefining them. Some work is needed to also remember the original locations and get the line_maps instance in the right state (since, like all other data structures, the line_maps instance is also reset after restoring a PCH). This patch addresses a more pressing issue, which is that we ICE in some cases since GCC 11, hitting an assert in line-maps.cc. It happens if the first line encountered after the PCH restore requires an LC_RENAME map, such as will happen if the line is sufficiently long. This is much easier to fix, since we just need to call linemap_line_start before asking libcpp to redefine the stored macros, instead of afterward, to avoid the unexpected need for an LC_RENAME before an LC_ENTER has been seen. gcc/c-family/ChangeLog: PR preprocessor/105608 * c-pch.cc (c_common_read_pch): Start a new line map before asking libcpp to restore macros defined prior to reading the PCH, instead of afterward. gcc/testsuite/ChangeLog: PR preprocessor/105608 * g++.dg/pch/line-map-1.C: New test. * g++.dg/pch/line-map-1.Hs: New test. * g++.dg/pch/line-map-2.C: New test. * g++.dg/pch/line-map-2.Hs: New test.
[Bug libgcc/113604] runtime SIGFPE with _BitInt() division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604
--- Comment #11 from Jakub Jelinek ---
Thanks, I'll add
--- gcc/testsuite/gcc.dg/torture/bitint-55.c.jj 2024-01-27 18:08:50.291929969
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-55.c2024-01-27 18:07:59.266636007
+0100
@@ -0,0 +1,50 @@
+/* PR libgcc/113604 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-std=c23 -pedantic-errors" } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
+
+#if __BITINT_MAXWIDTH__ >= 513
+signed _BitInt(513)
+foo (signed _BitInt(513) x, signed _BitInt(513) y)
+{
+ return x % y;
+}
+#endif
+
+#if __BITINT_MAXWIDTH__ >= 512
+unsigned _BitInt(512)
+bar (unsigned _BitInt(512) x, unsigned _BitInt(512) y)
+{
+ return x % y;
+}
+#endif
+
+#if __BITINT_MAXWIDTH__ >= 256
+unsigned _BitInt(256)
+baz (unsigned _BitInt(256) x, unsigned _BitInt(256) y)
+{
+ return x % y;
+}
+#endif
+
+int
+main ()
+{
+#if __BITINT_MAXWIDTH__ >= 513
+ if (foo
(11155754932722990178552651944728825929130437979239421228991532051555943675wb,
+ 32783817256434357484609367438786815wb) != 0wb)
+__builtin_abort ();
+#endif
+#if __BITINT_MAXWIDTH__ >= 512
+ if (bar
(6703903964971298549787012499102923063739682910296196688861780721860882015036773488400937149083451713845015929093243025426876941405973284973216824503042048uwb,
+ 170141183460469231731687303715884105735uwb) != 19208uwb)
+__builtin_abort ();
+#endif
+#if __BITINT_MAXWIDTH__ >= 256
+ if (baz
(115792089237316195423570985008687907853269984665640564039457584007913129639926uwb,
+ 68056473384187692692674921486353642292uwb) != 6uwb)
+__builtin_abort ();
+#endif
+ return 0;
+}
to the patch then.
[Bug c++/113629] 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
--- Comment #2 from 康桓瑋 ---
more reduced:
struct Base {
operator int(this auto&&) {
return 42;
}
};
int main() {
Base b;
// return static_cast(Base{}); // ok
return static_cast(b); // error
}
https://godbolt.org/z/qGrbf4rj7
[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #3 from Mikael Pettersson --- git bisect identified the following as the start of this error: # new: [04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a] Implement new RTL optimizations pass: fold-mem-offsets Note the error still reproduced as of 2024-01-07 so wasn't fixed by PR111601. (Technically my bisect has one more commit to test, the one immediately before the above, but that one only updates gcc/d/ so cannot have any impact to my bootstraps.)
[Bug tree-optimization/113630] New: -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
Bug ID: 113630
Summary: -fno-strict-aliasing introduces out-of-bounds memory
access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The test gcc.dg/torture/pr110799.c crashes because of an out of bounds memory
access when compiled with "-O2 -fno-strict-aliasing".
What is happening is that the pre pass has changed
struct S {
int a;
};
struct M {
int a, b;
};
__attribute__((noipa, noinline, noclone, no_icf))
int f (struct S * p, int c, int d)
{
int r;
:
if (c_2(D) != 0)
goto ;
else
goto ;
:
if (d_6(D) != 0)
goto ;
else
goto ;
r_8 = p_4(D)->a;
goto ;
r_7 = MEM[(struct M *)p_4(D)].a;
goto ;
r_5 = MEM[(struct M *)p_4(D)].b;
# r_1 = PHI
return r_1;
}
by combining bb 4 and bb 5 and doing all accesses as struct M:
__attribute__((noipa, noinline, noclone, no_icf))
int f (struct S * p, int c, int d)
{
int r;
int pretmp_9;
:
if (c_2(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
:
pretmp_9 = MEM[(struct M *)p_4(D)].a;
goto ;
:
r_5 = MEM[(struct M *)p_4(D)].b;
:
# r_1 = PHI
return r_1;
}
This in turn allows later passes to hoist the two loads
__attribute__((noipa, noinline, noclone, no_icf))
int f (struct S * p, int c, int d)
{
int r;
int pretmp_9;
:
pretmp_9 = MEM[(struct M *)p_4(D)].a;
r_5 = MEM[(struct M *)p_4(D)].b;
if (c_2(D) != 0)
goto ;
else
goto ;
:
:
# r_1 = PHI
return r_1;
}
which now reads out of bounds when we pass a struct S as f(&s, 1, 1).
[Bug tree-optimization/113630] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630 --- Comment #1 from Andrew Pinski --- I suspect pre us doing the right thing. It is phi-opt code that hoists is doing the wrong thing for non strict aliasing.
[Bug c/113631] New: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113631
Bug ID: 113631
Summary: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic, testsuite-fail
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
The original PR7356 highlighted a problem where a diagnostic for a problem in a
source file would point to something in an included file. This was fixed for
the case in the PR for a subset of systems with certain standard header files.
The original testcase was:
a
#include
#include
#include
int main(int argc, char** argv)
{
return 0;
}
The expectation is that GCC warns on the 'a', not somewhere inside stdlib.h.
This now works as indicated in that PR:
:1:2: error: expected ';' before 'typedef'
1 | a
| ^
| ;
Notably, it works differently with C++:
:1:1: error: 'a' does not name a type
1 | a
| ^
...but at least it marks 'a' as the issue (should that be a separate PR?)
However, on mingw, we have certain constructs in our headers that still confuse
the parser, resulting in this:
In file included from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/_mingw.h:282,^M
from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/corecrt.h:10,^M
from /tmp/rt/mingw14/x86_64-w64-mingw32/include/stdlib.h:9,^M
from /tmp/gcc/testsuite/gcc.dg/pr7356.c:4:^M
/tmp/rt/mingw14/x86_64-w64-mingw32/include/vadefs.h:14:9: error: expected '=',
',', ';', 'asm' or '__attribute__' before '#pragma'^M
#pragma pack(push,_CRT_PACKING)^M
^~~~^M
It turns out that the problem is target-agnostic and is really just due to
pragmas, so I've reduced it and reproduced the problem on GNU/Linux (the pragma
is meant to be a no-op, that was a close approximation. GCC diagnostic push
also works):
a.c:
a
#include "a.h"
int main() {}
a.h:
#pragma message "foo"
$ gcc -c a.c
a.h:1:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'#pragma'
1 | #pragma message "foo"
| ^~~
a.h:1:9: note: '#pragma message: foo'
[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #14 from H.J. Lu --- (In reply to Zeb Figura from comment #13) > (In reply to Sam James from comment #11) > > (In reply to Jens-Hanno Schwalm from comment #10) > > > Hi, i think we found a very-similar issue in darktable code, you might > > > look > > > at > > > > > > https://github.com/darktable-org/darktable/pull/15742 > > > > > > > If you're hitting this on another target than i686-w64-mingw32, please file > > a new bug. We can always mark it as a dupe if it turns out to be, although I > > suspect it isn't here. > > FWIW, I think the relevant part of i686-w64-ming32 is actually just > STACK_REALIGN_DEFAULT. I can reproduce the same lack of alignment with > "-mstackrealign -mavx512 -O2" with i386-linux-gnu, whereas "-mstackrealign > -mavx2 -O2" does align the stack. [-O2 is necessary here otherwise gcc will > just use vmovdqu and not bother aligning the stack. No idea what the more > targeted optimization is.] > For the attached testcase here, GCC 13.2 generates: [hjl@gnu-cfl-3 tmp]$ gcc -S -mstackrealign -mavx512f -O2 -m32 x.c [hjl@gnu-cfl-3 tmp]$ head -20 x.s .file "x.c" .text .p2align 4 .globl ddraw7_GetCaps .type ddraw7_GetCaps, @function ddraw7_GetCaps: .LFB0: .cfi_startproc leal4(%esp), %ecx .cfi_def_cfa 1, 0 andl$-16, %esp < Stack realignment. vpxor %xmm0, %xmm0, %xmm0 xorl%eax, %eax pushl -4(%ecx) pushl %ebp movl%esp, %ebp .cfi_escape 0x10,0x5,0x2,0x75,0 pushl %edi pushl %ecx .cfi_escape 0xf,0x3,0x75,0x78,0x6 [hjl@gnu-cfl-3 tmp]$ It works for me. Please file a separate bug if-mstackrealign -mavx512f -O2 doesn't work for you on Linux.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #23 from H.J. Lu --- (In reply to Andrew Burgess from comment #21) > Setting to DW_CFA_undefined is the right thing to do. DWARF says: > > The DW_CFA_undefined instruction takes a single unsigned LEB128 operand > that represents a register number. The required action is to set the rule > for the > specified register to “undefined.” > > which is exactly what you'd want here. > > GDB has a distinction between "unspecified" (not really a DWARF thing) and > "undefined" (the DWARF thing). Registers that aren't given an initial state > in the CIE start as "unspecified", the idea being (I believe) that we then > apply some kind of ABI based rules on top. So an "unspecified" > call-clobbered register would be treated as "undefined", while a > callee-saved register would be treated as "same-value" to begin with. > > Setting a register to "undefined" in the DWARF should, I think, do what you > want. A patch is posted at https://patchwork.sourceware.org/project/gcc/list/?series=30283
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:52029ef151cc9b1c90fa620079fc17f3960c467c commit r13-8257-g52029ef151cc9b1c90fa620079fc17f3960c467c Author: Lewis Hyatt Date: Tue Dec 5 11:33:39 2023 -0500 c-family: Fix ICE with large column number after restoring a PCH [PR105608] Users are allowed to define macros prior to restoring a precompiled header file, as long as those macros are not defined (or are defined identically) in the PCH. However, the PCH restoration process destroys all the macro definitions, so libcpp has to record them before restoring the PCH and then redefine them afterward. This process does not currently assign great locations to the macros after redefining them. Some work is needed to also remember the original locations and get the line_maps instance in the right state (since, like all other data structures, the line_maps instance is also reset after restoring a PCH). The new testcase line-map-3.C contains XFAILed examples where the locations are wrong. This patch addresses a more pressing issue, which is that we ICE in some cases since GCC 11, hitting an assert in line-maps.cc. It happens if the first line encountered after the PCH restore requires an LC_RENAME map, such as will happen if the line is sufficiently long. This is much easier to fix, since we just need to call linemap_line_start before asking libcpp to redefine the stored macros, instead of afterward, to avoid the unexpected need for an LC_RENAME before an LC_ENTER has been seen. gcc/c-family/ChangeLog: PR preprocessor/105608 * c-pch.cc (c_common_read_pch): Start a new line map before asking libcpp to restore macros defined prior to reading the PCH, instead of afterward. gcc/testsuite/ChangeLog: PR preprocessor/105608 * g++.dg/pch/line-map-1.C: New test. * g++.dg/pch/line-map-1.Hs: New test. * g++.dg/pch/line-map-2.C: New test. * g++.dg/pch/line-map-2.Hs: New test. * g++.dg/pch/line-map-3.C: New test. * g++.dg/pch/line-map-3.Hs: New test.
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 Lewis Hyatt changed: What|Removed |Added URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2023-Decembe | |r/639467.html | Keywords|ice-on-valid-code, patch| --- Comment #9 from Lewis Hyatt --- The ICE regression is fixed for GCC 11,12,13,14. Leaving it open to track the wrong location issue.
[Bug tree-optimization/113630] [11/12/13/14 Regression] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110799 Known to fail||10.1.0, 14.0, 7.1.0 Known to work||5.1.0, 6.1.0, 6.4.0 Keywords||needs-bisection, wrong-code Summary|-fno-strict-aliasing|[11/12/13/14 Regression] |introduces out-of-bounds|-fno-strict-aliasing |memory access |introduces out-of-bounds ||memory access
[Bug tree-optimization/113630] [11/12/13/14 Regression] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-01-27
Ever confirmed|0 |1
Known to work|5.1.0, 6.1.0, 6.4.0 |
--- Comment #2 from Andrew Pinski ---
Confirmed.
I really think what PRE does is correct here since we have an aliasing set of 0
for both. Now what is incorrect is hoist_adjacent_loads which cannot do either
of any of the aliasing sets are 0 ...
I think even the function below is valid for non-strict aliasing:
```
int __attribute__((noipa,noinline))
f(struct S *p, int c, int d)
{
int r;
if (c)
{
r = ((struct M*)p)->a;
}
else
r = ((struct M*)p)->b;
return r;
}
```
That is hoist_adjacent_loads is broken for non-strict-aliasing in general and
has been since 4.8.0 when it was added (r0-117275-g372a6eb8d991eb).
[Bug tree-optimization/113630] [11/12/13/14 Regression] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630 --- Comment #3 from Andrew Pinski --- Note LLVM produces decent code here by only using one load: ``` xor eax, eax testesi, esi seteal mov eax, dword ptr [rdi + 4*rax] ``` Maybe GCC could do the same ...
_BitInt() as underlying enum type
Hi all,
Earlier today I decided to clone the GCC repo and build the latest code
just to play around with some new C23 features. One thing I attempted
was the following:
typedef _BitInt(128) underlying;
enum my_enum : underlying {
FOO = (underlying)1 << 100;
BAR = (underlying)1 << 101;
};
I expected this to work — it builds on Clang too — but it failed to
compile with the error ‘invalid underlying type’ (or something like that;
I’m going off of memory).
I took a look into the C23 working draft and I see no reference to
bit-precise integers being disallowed as an underlying type to an
enumeration. As a result I assume this is a bug in GCC so I’m reporting
it here just in case. If it’s not a bug, do let me know why that is the
case.
--
— Thomas
Re: _BitInt() as underlying enum type
On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs
wrote:
>
> Hi all,
>
> Earlier today I decided to clone the GCC repo and build the latest code
> just to play around with some new C23 features. One thing I attempted
> was the following:
>
> typedef _BitInt(128) underlying;
> enum my_enum : underlying {
> FOO = (underlying)1 << 100;
> BAR = (underlying)1 << 101;
> };
>
> I expected this to work — it builds on Clang too — but it failed to
> compile with the error ‘invalid underlying type’ (or something like that;
> I’m going off of memory).
The trunk of clang rejects it:
```
:4:20: error: 'underlying' (aka '_BitInt(128)') is an invalid
underlying type
4 | enum my_enum : underlying {
|^
```
While clang 17.0 accepts it. So it looks like clang fixed their bug.
Thanks,
Andrew
>
> I took a look into the C23 working draft and I see no reference to
> bit-precise integers being disallowed as an underlying type to an
> enumeration. As a result I assume this is a bug in GCC so I’m reporting
> it here just in case. If it’s not a bug, do let me know why that is the
> case.
>
> --
> — Thomas
Re: _BitInt() as underlying enum type
On Sat, Jan 27, 2024 at 6:24 PM Andrew Pinski wrote:
>
> On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs
> wrote:
> >
> > Hi all,
> >
> > Earlier today I decided to clone the GCC repo and build the latest code
> > just to play around with some new C23 features. One thing I attempted
> > was the following:
> >
> > typedef _BitInt(128) underlying;
> > enum my_enum : underlying {
> > FOO = (underlying)1 << 100;
> > BAR = (underlying)1 << 101;
> > };
> >
> > I expected this to work — it builds on Clang too — but it failed to
> > compile with the error ‘invalid underlying type’ (or something like that;
> > I’m going off of memory).
>
> The trunk of clang rejects it:
> ```
> :4:20: error: 'underlying' (aka '_BitInt(128)') is an invalid
> underlying type
> 4 | enum my_enum : underlying {
> |^
> ```
> While clang 17.0 accepts it. So it looks like clang fixed their bug.
Just an FYI, the clang issue was
https://github.com/llvm/llvm-project/issues/69619 .
With the following commit to the LLVM git repo as the fix:
https://github.com/llvm/llvm-project/commit/5175cd777c57190ab9860c304796d386e4df9b8f
>
> Thanks,
> Andrew
>
> >
> > I took a look into the C23 working draft and I see no reference to
> > bit-precise integers being disallowed as an underlying type to an
> > enumeration. As a result I assume this is a bug in GCC so I’m reporting
> > it here just in case. If it’s not a bug, do let me know why that is the
> > case.
> >
> > --
> > — Thomas
[Bug target/113526] [14 Regression] gcc.target/arm/asm-flag-1.c fails since gcc-14-7248-g76bc70387d9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113526 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607 --- Comment #14 from Andrew Pinski --- [apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -static t.c -O3 -fno-vect-cost-model -march=armv9-a+sve [apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out ;echo $? 0 This is with r14-8455-gc34ab549d88da1 .
[Bug tree-optimization/113632] New: Range info for a^CST could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113632
Bug ID: 113632
Summary: Range info for a^CST could be improved
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void dummy();
_Bool f(unsigned long a)
{
_Bool cmp = a > 8192;
if (cmp) goto then; else goto e;
then:
unsigned long t = __builtin_clzl(a); // [0,50]
t^=63; // [13,63]
return t >= 13;
e:
dummy();
return 0;
}
```
Currently after the t^=63; we get:
```
# RANGE [irange] int [1, 63] MASK 0x3f VALUE 0x0
_7 = _1 ^ 63;
```
But this could/should be improved to [13,63].
If we change to using minus instead:
```
t = 63 - t;
```
We get the better range and the comparison (t >= 13) is optimized away.
```
Folding statement: t_10 = 63 - t_9;
Global Exported: t_10 = [irange] long unsigned int [13, 63] MASK 0x3f VALUE 0x0
Not folded
```
Yes this should up in real code, see the LLVM issue for more information on
that.
[Bug tree-optimization/113632] Range info for a^CSTP2-1 could be improved in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113632 Andrew Pinski changed: What|Removed |Added Summary|Range info for a^CST could |Range info for a^CSTP2-1 |be improved |could be improved in some ||cases Severity|normal |enhancement
[Bug target/113633] New: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size for ms_struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113633
Bug ID: 113633
Summary: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size
for ms_struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ABI, testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
CC: ktietz at gcc dot gnu.org
Target Milestone: ---
Target: *-*-mingw* *-*-cygwin*
>From gcc.dg/bf-ms-attrib.c:
struct one_ms {
int d;
unsigned char a;
unsigned short b:7;
char c;
} __attribute__((__ms_struct__));
And later:
if (sizeof(struct one_ms) != 8)
abort();
Here, we abort, because the size is 12 using the MS ABI.
Curiously, the testcase as initially committed used 12, and it was changed to 8
in r0-115284-g4d33b77106cf7f with the description being:
gcc.dg/bf-ms-attrib.c: Adjust expected size for ms_struct layout.
However, MSVC (and gcc/cygwin FWIW) creates a 12-byte struct, so I am curious
which is correct. Should that portion of that commit be reverted, or should
the struct be packed into 8 bytes? If you happen to still be reading this,
Kai, would you mind weighing in?
Perhaps we were incorrectly making 8-byte structs, then changed the testcase to
match 8, and later fixed something to generate 12-byte structs?
[Bug testsuite/113634] New: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113634 Bug ID: 113634 Summary: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc() Product: gcc Version: unknown Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- This test uses an incorrect declaration for calloc(): void *calloc(long, long); whereas the standard requires that it be: void *calloc(size_t, size_t); This can be replaced with: void *calloc(__SIZE_TYPE__, __SIZE_TYPE__); But I'd question why the test doesn't just include stdlib.h. Or, if the intent is to avoid including headers as much as possible, use __builtin_calloc(), which does the right thing. All three of these solutions work (header, builtin, correct declaration).
[Bug testsuite/113634] FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113634 --- Comment #1 from Andrew Pinski --- realloc is wrong too ..
