[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #8 from Jeffrey A. Law --- I'm pretty sure this is a case where -O1 throttles jump threading. Jump threading is critical to avoiding the false positive warning in this testcase. At -O2 the first full jump threading pass cleanings things up enough that the false positive will ultimately be avoided. In general, you'll find that -O2 will be much more precise for these kinds of warnings. So, yes, this is a bug. But it's not likely to get fixed anytime soon.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 101770, which changed state. Bug 101770 Summary: -Wmaybe-uninitialized false alarm with only locals in GNU diffutils https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Seems to be fixed on the trunk.
[Bug tree-optimization/96629] spurious maybe uninitialized variable warning with difficult control-flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #4 from Jeffrey A. Law --- It's worth noting that at -O2, -O3 and -Ofast the warning does not trigger. I haven't dug deeply as this is fairly common. At higher optimization levels the various optimizers try harder to find and eliminate redundancies.
[Bug tree-optimization/91470] [10/11/12 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470 Jeffrey A. Law changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] bogus |bogus uninitialized warning |uninitialized warning in |in trans-intrinsic.c|trans-intrinsic.c --- Comment #9 from Jeffrey A. Law --- Seems to be fixed on the trunk so removing 13 regression marker. Leaving others, though I doubt backporting the changes to fix this is likely to happen.
[Bug tree-optimization/88897] [10/11/12 Regression] Bogus maybe-uninitialized warning on class field (missed CSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Bogus |Bogus maybe-uninitialized |maybe-uninitialized warning |warning on class field |on class field (missed CSE) |(missed CSE)| --- Comment #12 from Jeffrey A. Law --- We're catching the previously missed CSE opportunity in fre1 now, and (of course) we no longer get the bogus warning. Removing the 13 regression marker. Finding and backporting the specific change seems like it's not worth it, but leaving open with the other regression markers for now.
[Bug middle-end/85563] [10/11/12/13 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #22 from Jeffrey A. Law --- Interestingly enough the original testcase seems OK now, but Jakub's reduced testcase in c#6 still fails. So keeping this open.
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- This has been fixed on the trunk.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 85301, which changed state. Bug 85301 Summary: bitfield check causes maybe-uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 84078, which changed state. Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/84078] false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Seems to have been fixed on the trunk. Not sure if it was the Aldy's threader work or Richi's predicate analysis work. Either is plausible. Just happy it's fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 84078, which changed state. Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/80635] [10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #70 from Jeffrey A. Law --- Please do not attach new testcases to this BZ. They should be created at distinct bugs. While they may generate the same warning, the underlying details are usually different.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 80548, which changed state. Bug 80548 Summary: -Wmaybe-uninitialized false positive when an assignment is added https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- It looks like this got fixed on the trunk. Not sure if it's from Aldy or Richi's work. Just happy it's fixed :-)
[Bug middle-end/78993] [10/11 Regression] False positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #12 from Jeffrey A. Law --- Simplified testcase no longer warns, but the original still does.
[Bug target/107713] Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713 --- Comment #10 from chenglulu --- (In reply to Xi Ruoyao from comment #9) > Fixed for gcc-12 too. Thanks! ^v^
[Bug tree-optimization/67196] [10/11/12 Regression] loop-induced false positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |loop-induced false positive |loop-induced false positive |from -Wmaybe-uninitialized |from -Wmaybe-uninitialized --- Comment #9 from Jeffrey A. Law --- Working with the trunk, so removing 13 regression marker.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 57832, which changed state. Bug 57832 Summary: compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Known to work||13.0 Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #8 from Jeffrey A. Law --- Seems to have been fixed on the trunk, most likely Richi's work from earlier this year.
[Bug tree-optimization/40635] [12/13 Regression] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #25 from Jeffrey A. Law --- So current status is if you add -fno-inline, you can see the proper uninitialized warning in get_tcp_socket, but we only get the declaration site of s42, not the use site. So still broken, just in a different way then the original report.
[Bug target/81495] Building Ada on Linux m68k natively fails with obscure linker errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81495 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Based on comments in bz98341, Ada is bootstrapping as of gcc-12 on m68k again.
[Bug testsuite/83454] FAIL: gcc.dg/tree-ssa/cswtch-4.c and cswtch-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83454 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk by making tests require nonpic effective target.
[Bug target/87010] FAIL: gcc.dg/torture/20180712-1.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87010 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED CC||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jeffrey A. Law --- Resolved by skipping the test on hppa targets.
[Bug tree-optimization/91625] FAIL: gcc.dg/strlenopt-68.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91625 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Fixed by skipping this test on hpux.
[Bug other/104044] Useless empty statements (across projects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104044 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug other/104044] Useless empty statements (across projects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104044 --- Comment #1 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:6d82e0fea5f988e829912aaa70a9964a81ad4e5e commit r13-4173-g6d82e0fea5f988e829912aaa70a9964a81ad4e5e Author: Jeff Law Date: Sat Nov 19 19:21:37 2022 -0700 [PR other/104044] Remove extraneous semicolons gcc/ PR other/104044 * config/mn10300/mn10300.cc (mn10300_print_operand): Remove extraneous semicolon. * config/nvptx/nvptx.cc (nvptx_goacc_reduction_fini): Likewise. gcc/jit/ PR other/104044 * jit-playback.cc (playback::lvale::mark_addressable): Remove extraeous semicolon
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #14 from Andrew Pinski --- (In reply to Jeffrey A. Law from comment #13) > More importantly, we should _not_ be adding the runtime exception to files > in GCC proper. That exception is for the runtime. The fact that files in > libgcc are #including tm.h and thus backend files from gcc proper is not a > good reason to be changing those copyrights. I really should finish up the removal of the tm.h includes from libobjc too. I had a patch set years ago but I dropped it, i cant remember if it was pre-svn or post svb. Maybe it is still in git somewhere.
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||law at gcc dot gnu.org --- Comment #13 from Jeffrey A. Law --- More importantly, we should _not_ be adding the runtime exception to files in GCC proper. That exception is for the runtime. The fact that files in libgcc are #including tm.h and thus backend files from gcc proper is not a good reason to be changing those copyrights.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 --- Comment #12 from Steve Kargl --- On Sat, Nov 19, 2022 at 08:14:01PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 > > --- Comment #11 from anlauf at gcc dot gnu.org --- > (In reply to Weslley da Silva Pereira from comment #7) > > More data for the discussion: > > 1. In a Ubuntu 18.04.5 LTS, using GNU Fortran 7.5.0, I tested optimization > > flags `-O` but still reproduce the wrong result for complex divisions with > > huge numbers. See > > It is possible that gfortran's dependence on optimization level depends > on the version. If one wants to test run-time behavior and avoid > compile-time simplification, it may be helpful to add: > > volatile :: x, y, z > > I then get consistent results for -O0 / -O1. > The optimization level is irrelevant. gfortran unilaterally uses -fcx-fortran-rules, and there is no way to disable this option to user the slower, but stricter, evaluation. One will always get complex division computed by a+ib a + b(d/c) b - a(d/c) = -- + i |c| > |d| c+id c + d(d/c) c + d(d/c) and similar for |d| > |c|. There are a few problems with this. d/c can trigger an invalid underflow exception. If d == c, you then have numerators of a + b and b - a, you can get a invalid overflow for a = huge() and b > 1e291_8.
[Bug driver/90443] when collect2/lto-wrapper/gcc-nm/gcc-ld fails to find a program, it does not say which program is being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90443 Andrew Pinski changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Andrew Pinski --- No longer working on this one.
[Bug driver/91244] gcc-ar prepends --plugin option thus triggers binutils getopt_long bug 13256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91244 Andrew Pinski changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #5 from Andrew Pinski --- No longer working on this one.
[Bug driver/90902] collect2 does not propagate gcc -wrapper far enough to wrap ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90902 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Not working on this one.
[Bug tree-optimization/80588] GCC can't simplify static inline function with xor/xnor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80588
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=106379
Target Milestone|--- |13.0
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (simplify
> (eq truth_value@0 truth_value@1)
> (bit_xor @0 @1))
> (simplify
> (ne truth_value@0 truth_value@1)
> (bit_xor (bit_xor @0 @1)) { build_one_cst (type); })
Also I had this wrong.
~(a ^ b) is the same as a == b.
This was fixed by r13-1779-g375668e0508fbe173a (aka PR 106379).
[Bug driver/77576] gcc-ar doesn't work if all options are read from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576 Andrew Pinski changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #5 from Andrew Pinski --- No longer working on this one.
[Bug tree-optimization/107765] New: missing (int)-(unsigned)int_val to just -int_val if int_val is known not to contain INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107765
Bug ID: 107765
Summary: missing (int)-(unsigned)int_val to just -int_val if
int_val is known not to contain INT_MIN
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
#include
int a(int input)
{
if (input == INT_MIN) __builtin_unreachable();
unsigned t = input;
int tt = -t;
return tt == -input;
}
```
We should be able to optimize this at the tree level because we know we don't
invoke undefined behavior.
[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 --- Comment #8 from Andrew Pinski --- Note the loop one looks like: if (input_4(D) != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 105119324]: _1 = (unsigned int) input_4(D); _3 = -_1; value_2 = (int) _3; [local count: 118111600]: # value_10 = PHI CUT Which avoids undefined overflow for INT_MIN.
[Bug tree-optimization/38209] branch optimisation generates worse code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38209 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Known to work||12.1.0 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed for GCC 12 by r12-5699-gde3e5aae6c4b540e8 Specifically this part: X != C1 ? ~X : C2 simplifies to ~X when ~C1 == C2. which is the BIT_NOT_EXPR analog of the NEGATE_EXPR case.
[Bug fortran/107659] C procedure with no global scope is seen as global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659 --- Comment #2 from anlauf at gcc dot gnu.org --- I was trying a fix that regressed on binding_label_tests_34.f90, but looking into that it appears that this test is not correct, as well as the comment at the top of it. The fix for pr94737 was likely incomplete. F2018, 18.9.2, paragraph 2 actually says: ! (2) If a variable or common block has the BIND attribute with the NAME= ! specifier and the value of its expression, after discarding leading and ! trailing blanks, has nonzero length, the variable or common block has ! this as its binding label. The case of letters in the binding label is ! significant. ... Since NAG and Intel accepts the testcase, it will need updating...
[Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false positive with while loop in pthread_cleanup_push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107582 --- Comment #10 from dimitri at ouroboros dot rocks --- thanks for the analysis and the fix!
[Bug c/106560] [12/13 Regression] ICE after conflicting types of redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Summary|ICE after conflicting types |[12/13 Regression] ICE |of redeclaration|after conflicting types of ||redeclaration Severity|normal |trivial --- Comment #8 from Andrew Pinski --- I am 99% sure this started after r12-3278-g823685221de986af. I am testing the fix right now (the one to use error_operand_p) and will be posting it soon.
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #16 from Jakub Jelinek --- It is a pedwarn (pedantic warning, with -pedantic-errors a hard error).
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #12 from Sergei Trofimovich ---
Testing the following:
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -5869,37 +5869,37 @@ cgraph_edge_brings_all_scalars_for_node (struct
cgraph_edge *cs,
/* Determine whether CS also brings all aggregate values that NODE is
specialized for. */
static bool
cgraph_edge_brings_all_agg_vals_for_node (struct cgraph_edge *cs,
struct cgraph_node *node)
{
ipcp_transformation *ts = ipcp_get_transformation_summary (node);
if (!ts || vec_safe_is_empty (ts->m_agg_values))
return true;
const ipa_argagg_value_list existing (ts->m_agg_values);
auto_vec edge_values;
ipa_node_params *dest_info = ipa_node_params_sum->get (node);
gcc_checking_assert (dest_info->ipcp_orig_node);
dest_info = ipa_node_params_sum->get (dest_info->ipcp_orig_node);
push_agg_values_from_edge (cs, dest_info, _values, );
const ipa_argagg_value_list avl (_values);
- return avl.superset_of_p (existing);
+ return existing.superset_of_p (avl);
}
[Bug c++/107764] -Wreturn-type and -Wuninitialized documentation could link to a FAQ about enum and switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107764 --- Comment #1 from Andrew Pinski --- It also does not help that clang and GCC disagree on how the C++ enums work either.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Weslley da Silva Pereira from comment #7) > More data for the discussion: > 1. In a Ubuntu 18.04.5 LTS, using GNU Fortran 7.5.0, I tested optimization > flags `-O` but still reproduce the wrong result for complex divisions with > huge numbers. See It is possible that gfortran's dependence on optimization level depends on the version. If one wants to test run-time behavior and avoid compile-time simplification, it may be helpful to add: volatile :: x, y, z I then get consistent results for -O0 / -O1. > 4. My Ubuntu 20.04.5 LTS with compiler ifort 2021.7.1 computes the complex > division `x/x` accurately even for the case of huge numbers. Scenarios > tested: >- I tested the program in > https://github.com/Reference-LAPACK/lapack/blob/master/INSTALL/ > test_zcomplexdiv.f and the one in https://godbolt.org/z/b3WKWodvn. >- I tested ifort with flags -fp-model precise and -fp-model fast. The > latter enables more aggressive optimizations on floating-point data. >- I tested compilation with optimization flags -O0, -O, -O1, -O2, -O3. Intel might be fine, but at least some current llvm-based compilers (Nvidia, AMD flang) show more or less similar behavior to gfortran. E.g. nvfortran 22.11: (1.7976931348623157E+308,1.7976931348623157E+308) (8.9884656743115795E+307,8.9884656743115795E+307) (4.4942328371557898E+307,4.4942328371557898E+307) (NaN,0.000) (NaN,0.000) (1.000,0.000) As a sidenote: we are really discussing borderline cases here, valid but only rarely occuring in normal code execution. If I replace x = cmplx( huge(0.0d0), huge(0.0d0), dp ) y = cmplx( b**(E-1), b**(E-1), dp ) by x = cmplx( nearest(huge(0.0d0),-1.d0), nearest(huge(0.0d0),-1.d0), dp ) y = cmplx( nearest(b**(E-1), -1.d0), nearest(b**(E-1), -1.d0), dp ) then I get (1.,0.) (1.,0.) instead of NaN.
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 --- Comment #11 from Sergei Trofimovich --- I think I found the bug: r13-3358-ge0403e95689af7 cgraph_edge_brings_all_agg_vals_for_node() accidentally changed behaviour of the predicate: - before the change: ipa-cp triggers when constrop contains all possible edges aggregates (ok). - after the change: ipa-cp triggers when constrop contains a subset(!) of possible edges aggregates (bad, redirects invalid values sometimes). Thus substitution of do3()->do3.constprop() redirects to the wrong target. Sounds plausible?
[Bug c++/107763] -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763 --- Comment #5 from Roman Lebedev --- Thank you. Forwarded to https://github.com/llvm/llvm-project/issues/59085
[Bug c++/107763] -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763 --- Comment #4 from Andrew Pinski --- (In reply to Roman Lebedev from comment #2)> > Is this situation different in C++? looks like i set the component wrong. > Is this implementation-defined behavior, > or are you saying that clang is wrong here? Yes I think clang is wrong. The spec says: "The value is unchanged if the original value is within the range of the enumeration values"
[Bug c++/91950] -Wreturn-type false positive due to CWG 1766
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91950 --- Comment #5 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #4) > (In reply to Eric Gallager from comment #2) > > I think this is actually a dup of another bug that asked the same thing, but > > I forget its number... > > There are dozens of them, because nobody understands how enums work in C++. > > I keep meaning to write a FAQ entry. I filed PR 107764 at least to add the FAQ to GCC's documentation.
[Bug c++/107764] New: -Wreturn-type and -Wuninitialized documentation could link to a FAQ about enum and switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107764 Bug ID: 107764 Summary: -Wreturn-type and -Wuninitialized documentation could link to a FAQ about enum and switches Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I have noticed GCC gets bug reports about false positive with -Wreturn-type or -Wuninitialized and enums in a switch statement. WE should have a FAQ about enums dealing with how they work; especially with switch statements and link to that part of the document from those two warnings. And also the FAQ should talk about the interaction with -fstrict-enum option for C++. https://gcc.gnu.org/legacy-ml/gcc/2007-01/msg01179.html There are definitely some more bug reports that I didn't link in the see also.
[Bug c++/107763] -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763 --- Comment #3 from Andrew Pinski --- No, it is not different in C++. See PR 91950 for that.
[Bug c++/107763] -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763 Roman Lebedev changed: What|Removed |Added Component|c |c++ --- Comment #2 from Roman Lebedev --- (In reply to Andrew Pinski from comment #1) > >The `a` can only have value `a::b`, > > NO, it has a full range of the underlying type. For GCC, see > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Structures-unions-enumerations- > and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit- > fields-implementation > > "Normally, the type is unsigned int if there are no negative values in the > enumeration, otherwise int. If -fshort-enums is specified, then if there are > negative values it is the first of signed char, short and int that can > represent all the values, otherwise it is the first of unsigned char, > unsigned short and unsigned int that can represent all the values. > > On some targets, -fshort-enums is the default; this is determined by the ABI. > > " Is this situation different in C++? looks like i set the component wrong. Is this implementation-defined behavior, or are you saying that clang is wrong here? At run time, `a` can not have any other value other than `a::b`: https://godbolt.org/z/hnc665755 so this really does seem like a bug.
[Bug c/107763] -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- >The `a` can only have value `a::b`, NO, it has a full range of the underlying type. For GCC, see https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation "Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int. If -fshort-enums is specified, then if there are negative values it is the first of signed char, short and int that can represent all the values, otherwise it is the first of unsigned char, unsigned short and unsigned int that can represent all the values. On some targets, -fshort-enums is the default; this is determined by the ABI. "
[Bug c/107763] New: -Wreturn-type false-positive with fully-covered switch over enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763
Bug ID: 107763
Summary: -Wreturn-type false-positive with fully-covered switch
over enum
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
enum a { b };
int foo(a a) {
switch(a) {
case b: return 42;
}
}
The `a` can only have value `a::b`,
so the function always returns 42, yet gcc complains:
> warning: control reaches end of non-void function [-Wreturn-type]
https://godbolt.org/z/j8ezrr5h3
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Steve Kargl from comment #9) > On Fri, Nov 18, 2022 at 11:24:29PM +, sgk at troutmask dot > apl.washington.edu wrote: > > > > Does anyone know what is meant by "Fortran rules"? F66 does not > > have any particular algorithm specified. I'll look at F77 shortly. > > > > Well, I hunted down the origins of -fcx-fortran-rules. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549 > > So, it appears to be an optimization, where Smith's algorithm > will fail for extreme values of the real and imaginary parts > of the complex number. So, I wrong a dirty little program to time complex division. program foo use timerm, only : rdtsc implicit none integer, parameter :: n = 1024*1024, dp = kind(1.d0) real(dp) re(n), im(n) complex(dp) x(n) integer i integer(8) t0, t t = 0 do i = 1, 10 call random_number(re) call random_number(im) x = cmplx(4 * re, 10 * im,8) t0 = rdtsc() x = x / x t = t + (rdtsc() - t0) end do print '(G0,1X,G0)', x(1) print *, real(t,10) / 10 / n end program foo Compiled with gfortran with its current method of doing division (i.e., -fcx-fortran-rules), I see roughly 44.5 clock ticks per division. If run with a patched gfortran that uses the method that the C compiler uses, I get about 62 ticks per division. So, using the stricter method impacts performance. I'll note that gfortran unilaterally enforces -fcx-fortran-rules, i.e., -fno-cx-fortran-rules has no effect. Perhaps, gfortran could be given a new -fcx-division=XXX option, where XXX is one of naive --> what -ffast-math does (flags_complex_method = 0) smith --> what -fcx-fortran-rules (flags_complex_method = 1) strict -> default C behavior (flags_complex_method = 2)
[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-19 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- > Is causing at least two regressions on s390-linux-gnu: > Tests that now fail, but worked before (19 tests): > [ ... ] > gcc.target/s390/arch12/mul-1.c scan-assembler-times \tmsgrkc\t 1 > gcc.target/s390/arch13/sel-1.c scan-assembler-times \tselgr(?:h|le)\t 1 > [ ... ] > > Those are the only two that I have positively confirmed are due to the > emit_group_store change. > > I looked briefly at the resulting assembly code for the mul-1 test and it > looks worse to me after that change. But I'm far from an s390 expert. Thanks for the heads up, I'll have a quick look.
[Bug middle-end/107743] expmed: extract_bit_field_1: maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107743 --- Comment #2 from Bernhard Reutner-Fischer --- --disable-werror --enable-checking=yes --enable-debug --enable-multilib --disable-libstdcxx-pch --enable-bootstrap
[Bug rtl-optimization/107762] New: [13 Regression] Recent change causing regressions on s390-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762 Bug ID: 107762 Summary: [13 Regression] Recent change causing regressions on s390-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: s390-linux-gnu This change: commit 3e2bdf2460a34a2389dee813a2ba8ecf976f2ec9 Author: Eric Botcazou Date: Fri Nov 4 11:15:57 2022 +0100 Do not use subword paradoxical subregs in emit_group_store The goal of the trick is to make life easier for the combiner, but subword paradoxical subregs make it harder for the register allocator instead. gcc/ * expr.cc (emit_group_store): Do not use subword paradoxical subregs Is causing at least two regressions on s390-linux-gnu: Tests that now fail, but worked before (19 tests): [ ... ] gcc.target/s390/arch12/mul-1.c scan-assembler-times \tmsgrkc\t 1 gcc.target/s390/arch13/sel-1.c scan-assembler-times \tselgr(?:h|le)\t 1 [ ... ] Those are the only two that I have positively confirmed are due to the emit_group_store change. I looked briefly at the resulting assembly code for the mul-1 test and it looks worse to me after that change. But I'm far from an s390 expert. You can see this with a cross compiler, you don't need a full toolchain to test.
[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Andrew Pinski --- Fixed finally.
[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840 --- Comment #16 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5c021f17e7d09a0eae2d6fb875c9a5484bd4e043 commit r13-4170-g5c021f17e7d09a0eae2d6fb875c9a5484bd4e043 Author: Andrew Pinski Date: Fri Nov 18 05:05:03 2022 + constexprify some tree variables Since we use C++11 by default now, we can use constexpr for some const decls in tree-core.h. This patch does that and it allows for better optimizations of GCC code with checking enabled and without LTO. For an example generic-match.cc compiling is speed up due to the less number of basic blocks and less debugging info produced. I did not check the speed of compiling the same source but rather the speed of compiling the old vs new sources here (but with the same compiler base). The small slow down in the parsing of the arrays in each TU is migrated by a speed up in how much code/debugging info is produced in the end. Note I looked at generic-match.cc since it is one of the compiling sources which causes parallel building to stall and I wanted to speed it up. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR middle-end/14840 * tree-core.h (tree_code_type): Constexprify by including all-tree.def. (tree_code_length): Likewise. * tree.cc (tree_code_type): Remove. (tree_code_length): Remove.
[Bug libstdc++/107649] New std::complex specializations are never used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:945e86ddaa6cc7251d7bb57be8bb65f182cd3a0c commit r13-4167-g945e86ddaa6cc7251d7bb57be8bb65f182cd3a0c Author: Jonathan Wakely Date: Fri Nov 18 21:17:51 2022 + libstdc++: Fix one more malformed requires-clause [PR107649] libstdc++-v3/ChangeLog: PR libstdc++/107649 * include/std/complex (__complex_proj): Fix requires-clause.
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #15 from Maciej W. Rozycki --- If in older C standard versions such enums are invalid, then I think this should be a hard error rather than a silent ABI change for the code produced. Not all code out there will have sanity checks such as the Linux kernel does and things will break for people in a tough way (think a public header file defining an enumeration and objects linked that define data of such an enumeration type and have been built with different compiler versions).
[Bug target/107713] Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |12.3 Version|13.0|10.4.1
[Bug target/107713] Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Xi Ruoyao --- Fixed for gcc-12 too.
[Bug target/107713] Wrong implementation atomic_exchange on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:2adcbcc69a1d5d9554042f09ec35e72bf39fb56f
commit r12-8918-g2adcbcc69a1d5d9554042f09ec35e72bf39fb56f
Author: Jinyang He
Date: Thu Nov 17 14:38:52 2022 +0800
LoongArch: Fix atomic_exchange expanding [PR107713]
We used to expand atomic_exchange_n(ptr, new, mem_order) for subword types
into something like:
{
__typeof__(*ptr) t = atomic_load_n(ptr, mem_order);
atomic_compare_exchange_n(ptr, , new, true, mem_order, mem_order);
return t;
}
It's incorrect because another thread may store a different value into *ptr
after atomic_load_n. Then atomic_compare_exchange_n will not store into
*ptr, but atomic_exchange_n should always perform the store.
gcc/ChangeLog:
PR target/107713
* config/loongarch/sync.md
(atomic_cas_value_exchange_7_): New define_insn.
(atomic_exchange): Use atomic_cas_value_exchange_7_si instead of
atomic_cas_value_cmp_and_7_si.
gcc/testsuite/ChangeLog:
PR target/107713
* gcc.target/loongarch/pr107713-1.c: New test.
* gcc.target/loongarch/pr107713-2.c: New test.
(cherry picked from commit f0024bfb228f94e60e06dc32a4983e40a9b90be5)
[Bug c++/98859] pedantic error on use of __VA_OPT__ before C++20 is unnecessary and counterproductive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98859 Will Wray changed: What|Removed |Added CC||wjwray at gmail dot com --- Comment #3 from Will Wray --- Linking the related MSVC issue /Zc:preprocessor __VA_OPT__ is not enabled with /std:c++17 https://developercommunity.visualstudio.com/t/Zc:preprocessor-__VA_OPT__-is-not-enabl
[Bug libstdc++/107761] New: Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 Bug ID: 107761 Summary: Implement C++23 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P0009R18 https://wg21.link/P2599R2 https://wg21.link/P2604R0 https://wg21.link/P2613R1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug libstdc++/107760] New: Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107760 Bug ID: 107760 Summary: Implement C++23 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P2093R14 https://wg21.link/P2539R3 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug libstdc++/107759] New: Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107759 Bug ID: 107759 Summary: Implement C++23 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P0429R9 I already have a sketch of a partial implementation which I'll attach here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug libstdc++/107758] New: Implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107758 Bug ID: 107758 Summary: Implement Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P1222R4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug preprocessor/107691] [10/11/12/13 Regression] libcpp configure fails on empty expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 --- Comment #5 from CVS Commits --- The master branch has been updated by Bernhard Reutner-Fischer : https://gcc.gnu.org/g:5a6c698ea31f587151a2fa4a982c8cc43bd9cc45 commit r13-4165-g5a6c698ea31f587151a2fa4a982c8cc43bd9cc45 Author: Bernhard Reutner-Fischer Date: Thu Nov 17 21:40:53 2022 +0100 libcpp: Add missing config for --enable-valgrind-annotations [PR107691] r7-912 copied (parts of) the valgrind annotation checks from gcc to libcpp. The above copies the missing pieces to libcpp to diagnose when libcpp is configured with --enable-valgrind-annotations but valgrind is not installed. libcpp/ChangeLog: PR preprocessor/107691 * configure.ac: Add valgrind header checks. * configure: Regenerate.
[Bug target/106462] LRA on mips64el: unable to reload (subreg:SI (reg:DI)) constrained by "f"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462 --- Comment #4 from Yang Yujie --- (In reply to Yang Yujie from comment #3) > (In reply to Vladimir Makarov from comment #2) > > I built mips64el-linux-gnuabi64 but using -mabi=64 -msingle-float for it > > gives > > > > cc1: error: unsupported combination: -mgp64 -mno-odd-spreg > > > > Did I miss something? > > Hi Vladimir, thanks for your reply! > > It seems that you need to specify -march=mips64r2 (or configure gcc with > --with-arch=mips64r2). This turns on -mno-spreg by default. * Should be -modd-spreg, sorry for the typo.
[Bug target/106462] LRA on mips64el: unable to reload (subreg:SI (reg:DI)) constrained by "f"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462 --- Comment #3 from Yang Yujie --- (In reply to Vladimir Makarov from comment #2) > I built mips64el-linux-gnuabi64 but using -mabi=64 -msingle-float for it > gives > > cc1: error: unsupported combination: -mgp64 -mno-odd-spreg > > Did I miss something? Hi Vladimir, thanks for your reply! It seems that you need to specify -march=mips64r2 (or configure gcc with --with-arch=mips64r2). This turns on -mno-spreg by default.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 107684, which changed state. Bug 107684 Summary: [C++23] P2589 - static operator[] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107684 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107684] [C++23] P2589 - static operator[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107684 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- https://gcc.gnu.org/g:6492cec069bccf817ac5e984fb3eca407056a566 commit r13-4046-g6492cec069bccf817ac5e984fb3eca407056a566 Author: Jakub Jelinek Date: Tue Nov 15 08:00:21 2022 +0100 c++: Implement C++23 P2589R1 - - static operator[] Here is a patch that implements the static operator[] paper. One thing that doesn't work properly is the same problem as I've filed yesterday for static operator() - PR107624 - that side-effects of the postfix-expression on which the call or subscript operator are applied are thrown away, I assume we have to add them into COMPOUND_EXPR somewhere after we find out that the we've chosen a static member function operator. 2022-11-15 Jakub Jelinek gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Bump C++23 __cpp_multidimensional_subscript macro value to 202211L. gcc/cp/ * decl.cc (grok_op_properties): Implement C++23 P2589R1 - static operator[]. Handle operator[] similarly to operator() - allow static member functions, but pedwarn on it for C++20 and older. Unlike operator(), perform rest of checks on it though for C++20. * call.cc (add_operator_candidates): For operator[] with class typed first parameter, pass that parameter as first_arg and an adjusted arglist without that parameter. gcc/testsuite/ * g++.dg/cpp23/subscript9.C: New test. * g++.dg/cpp23/feat-cxx2b.C: Expect a newer __cpp_multidimensional_subscript value. * g++.old-deja/g++.bugs/900210_10.C: Don't expect an error for C++23 or later.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Implemented for GCC 13.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 106654, which changed state. Bug 106654 Summary: [C++23] P1774 - Portable assumptions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 106652, which changed state. Bug 106652 Summary: [C++23] P1467 - Extended floating-point types and standard names https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Jakub Jelinek --- This is now implemented.
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 106652, which changed state. Bug 106652 Summary: [C++23] P1467 - Extended floating-point types and standard names https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/107685] [C++23] P2647 - Permitting static constexpr variables in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107685 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jakub Jelinek --- https://gcc.gnu.org/g:32d16fe9d7e347bc58e7fad316ed7923e1d0f65c commit r13-4161-g32d16fe9d7e347bc58e7fad316ed7923e1d0f65c Author: Jakub Jelinek Date: Sat Nov 19 09:26:44 2022 +0100 c++: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions The following patch implements this paper. Per further discussions it is implemented for C++23 only, so isn't treated as a DR, e.g. because the part of the standard the paper is changing didn't even exist in C++20. And we gave up on trying to implement it as a pedwarn rather than error for C++20 and older, because of implicit constexpr lambdas or -fimplicit-constexpr reasons. For C++20 and older, the only change is that passing through definitions of static or thread_local vars usable in constant expressions is now accepted in statement expressions if they aren't inside of constexpr or consteval functions. 2022-11-19 Jakub Jelinek gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr value from 202207L to 202211L. gcc/cp/ * constexpr.cc (cxx_eval_constant_expression): Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions. Allow DECL_EXPRs of decl_constant_var_p static or thread_local vars. (potential_constant_expression_1): Similarly, except use decl_maybe_constant_var_p instead of decl_constant_var_p if processing_template_decl. gcc/testsuite/ * g++.dg/cpp23/constexpr-nonlit17.C: New test. * g++.dg/cpp23/constexpr-nonlit18.C: New test. * g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr value. * g++.dg/ext/stmtexpr19.C: Don't expect an error. * g++.dg/ext/stmtexpr25.C: New test.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 107685, which changed state. Bug 107685 Summary: [C++23] P2647 - Permitting static constexpr variables in constexpr functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107685 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/107628] ICE: SIGSEGV in commutative_operand_precedence (rtlanal.cc:3770) with -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107628 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/107628] ICE: SIGSEGV in commutative_operand_precedence (rtlanal.cc:3770) with -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107628
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b1115dbfea4d6df51d608cece7416d658d2e2822
commit r13-4162-gb1115dbfea4d6df51d608cece7416d658d2e2822
Author: Jakub Jelinek
Date: Sat Nov 19 10:17:01 2022 +0100
i386: Outline fast BF -> SF conversion and fix up sNaN handling in it
[PR107628]
On Fri, Oct 21, 2022 at 10:23:14AM +0200, Uros Bizjak wrote:
> OK, but now we have two more copies of a function that effectively
> extends BF to SF. Can you please split this utility function out and
> use it here and in cbranchbf4/cstorebf4? I'm talking about this part:
>
> + op = gen_lowpart (HImode, op1);
> + if (CONST_INT_P (op))
> + op = simplify_const_unary_operation (FLOAT_EXTEND, SFmode,
> +op1, BFmode);
> + else
> + {
> + rtx t1 = gen_reg_rtx (SImode);
> + emit_insn (gen_zero_extendhisi2 (t1, op));
> + emit_insn (gen_ashlsi3 (t1, t1, GEN_INT (16)));
> + op = gen_lowpart (SFmode, t1);
> + }
>
> Taking this a bit further, it looks like a generic function to extend
> BF to SF, when extendbfsf2 named function is not defined.
>
> The above could be a follow-up patch, the proposed patch is OK.
Sorry for the delay, only got to this now.
And I'm fixing the sNaN handling in it too. If the argument is a BFmode
sNaN
constant, we want in this case just a SFmode sNaN constant, but
simplify_const_unary_operation (FLOAT_EXTEND, ...)
in that case returns NULL (as normally conversions of a sNaN to some
other float type should raise an exception). In this case we want
to bypass that, as we know the sNaN will be used immediately in the SFmode
comparison a few instructions later. The patch fixes it by just
simplifying the lowpart to HImode and its zero extension to SImode, then
force into a pseudo and do the left shift and subreg to SFmode on the
pseudo. CSE or combine can handle it later.
2022-11-19 Jakub Jelinek
PR target/107628
* config/i386/i386-protos.h (ix86_expand_fast_convert_bf_to_sf):
Declare.
* config/i386/i386-expand.cc (ix86_expand_fast_convert_bf_to_sf):
New
function.
* config/i386/i386.md (cbranchbf4, cstorebf4): Use it.
* gcc.target/i386/pr107628.c: New test.
[Bug c/107756] Change in sizeof(enum) with -std=gnu11 breaks Linux kernel code compilation (PR c/36113 change regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107756 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- In older C standard versions such enums are invalid. *** This bug has been marked as a duplicate of bug 107405 ***
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 Jakub Jelinek changed: What|Removed |Added CC||macro at orcam dot me.uk --- Comment #14 from Jakub Jelinek --- *** Bug 107756 has been marked as a duplicate of this bug. ***
