[Bug target/109900] _mm256_abs_epi8 is not expanded on gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109900
--- Comment #1 from Hongtao.liu ---
Yes, let me do the folding.
FYI, for those floating point abs intrinsics, they're already implemented as
_mm512_abs_ps (__m512 __A)
{
return (__m512) _mm512_and_epi32 ((__m512i) __A,
_mm512_set1_epi32 (0x7fff));
}
And no need for folding.
[Bug c/109905] New: Missed misleading indentation with braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109905
Bug ID: 109905
Summary: Missed misleading indentation with braces
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
https://github.com/NetBSD/src/blob/93dc650849c98c54c31aa9cbbce9affaaf649563/bin/cat/cat.c#L185
has misleading indentation, as the 'else' branch does not start with a '{'.
I tried GCC 10 and GCC 12, which don't detect this. Maybe GCC 14 should.
[Bug driver/33980] Precompiled header file not removed on error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Component|pch |driver Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- I think I have a simple patch for this.
[Bug target/106545] peephole.md seems like it should not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545
--- Comment #3 from Andrew Pinski ---
Note I see XTheadMemPair code has been added to peephole.md which is good to
have it away.
But again the first peephole is also handled differently already via
zero_extendsidi2_shifted which was added in r11-745-gd5cdcd5cf2b292 but it was
not until r13-4907-g2e886eef7f2b5a when we started to optimizing the following
code:
unsigned long f(unsigned long a)
{
a <<= 32;
a >>= 32;
a <<= 10;
return a;
}
[Bug target/106545] peephole.md seems like it should not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vineetg at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-19 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- (In reply to Vineet Gupta from comment #1) > How do I assign this to myself, can this only be done by maintainers ? You use your @gcc.gnu.org email.
[Bug c++/105703] Add fix-it for missing nested-name-specifier on non-member function using 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105703 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/105702] Add fix-it for missing nested-name-specifier on out-of-class assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105702 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-05-19 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/107744] Error in constant evaluation of dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-19 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/107694] Bogus stringop-overflow warning in gcc 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107694
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=109571
--- Comment #1 from Andrew Pinski ---
PR 109571 is basically the same here just with a different warning (and
upcasting instead of downcasting).
In this case if we look at:
void nsJSPrincipals::Destroy(JSPrincipals* jsprin) {
nsJSPrincipals* nsjsprin = nsJSPrincipals::get(jsprin);
if jsprin is null, then nsjsprin needs to be null too. And since nsjsprin ==
jsprin-8(bytes) (if it was a valid pointer), the C++ front-end needs to add a
check for null. And then the optimizations come along and does jump threading.
so one way of removing this is adding an assumption which can be done via one
of the following:
if (!jsprin) __builtin_unreachable();
[[assume(jsprin)]];
The first one is valid for GCC all the way back in 4.7 (and before).
the second one is C++23 and was only added in GCC 13.
[Bug c++/107587] Explicit specializations of user-defined deduction guides in unnamed namespaces trigger -Wunused-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107587 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 106604. *** This bug has been marked as a duplicate of bug 106604 ***
[Bug c++/106604] Fully-specified deduction guide in anonymous namespace warns as-if a function? Unsuppressably?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106604 Andrew Pinski changed: What|Removed |Added CC||development at jordi dot vilar.cat --- Comment #2 from Andrew Pinski --- *** Bug 107587 has been marked as a duplicate of this bug. ***
[Bug target/107533] Inefficient code sequence for fp16 testcase on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107533
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-19
Ever confirmed|0 |1
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Take:
```
struct phalf {
__fp16 first;
__fp16 second;
};
void phalf_copy_(struct phalf *d, struct phalf src) {
*d = src;
}
struct phalf phalf_copy0( __fp16 f, __fp16 s) {
struct phalf t = {f, s};
return t;
}
struct phalf phalf_copy(struct phalf* src) {
return *src;
}
struct phalf phalf_copy1(__fp16 *f, __fp16 *s) {
struct phalf t = {*f, *s};
return t;
}
void phalf_copy2(struct phalf *d, __fp16 *f, __fp16 *s) {
struct phalf t = {*f, *s};
*d = t;
}
void phalf_copy3(struct phalf *d, struct phalf* src) {
*d = *src;
}
void phalf_copy4(struct phalf *d, __fp16 f, __fp16 s) {
struct phalf t = {f, s};
*d = t;
}
```
2,3,4 are all ok, while 0, none, _ and 1 are bad.
Which points to return values and argument passing being bad (which we already
knew had issues).
Confirmed.
[Bug c++/106810] Unexpected constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Even though this bug is older, PR 108393 has the full analysis of what is going on and even talks about a fix for the testcase and talking about CWG2369 too. *** This bug has been marked as a duplicate of bug 108393 ***
[Bug c++/108393] circular concept false-positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393 Andrew Pinski changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 106810 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/107476] Spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107476 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to fail||13.1.0 --- Comment #2 from Andrew Pinski --- So it looks like there was some jump threading that happened here: if (one.0_59 > 1) goto ; [50.00%] else goto ; [50.00%] [local count: 131211251]: ivtmp.16_58 = (unsigned long) [(void *)_ldsc + 520B]; [local count: 131211252]: # ivtmp.14_38 = PHI # ivtmp.16_18 = PHI _9 = (struct TMLN *) ivtmp.16_18; temp_10 = tmxr_getc_ln (_9); if (temp_10 != 0) goto ; [50.00%] else goto ; [50.00%] But for some reason the trunk does not do that any more. Would be interesting to see when the warning disappeared from the trunk.
[Bug tree-optimization/107462] Missed optimization of std::atomic::fetch_xxx "null operations" to std::atomic::load()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107462 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-05-19 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/107450] GCC accepts invalid program involving multiple template parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450
--- Comment #2 from Andrew Pinski ---
Reduced/simplified (using auto because I feel like it):
int i, j, k;
void f(auto){i++;}
void g(auto){j++;}
void h(auto){k++;}
void foo(auto&&...args1, auto&&... args2, auto&&... args3) {
(f(args1), ...);
(g(args2), ...);
(h(args3), ...);
}
int main(int argc, char** argv)
{
foo(1,2,3,4,5,6); //gcc and clang compiles this while msvc correctly
rejects this
__builtin_printf("args1: %d, args2: %d, args3: %d.\n", i, j, k);
}
[Bug target/106471] -march=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #10 from Hongtao.liu --- The tune is added in PR62011
[Bug target/106471] -march=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #9 from Hongtao.liu --- lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since icelake. At least for icelake and later intel Core processors, the errata tune is not needed.
[Bug jit/66594] jitted code should use -mtune=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594 Andrew Pinski changed: What|Removed |Added CC||helohe at bluewin dot ch --- Comment #9 from Andrew Pinski --- *** Bug 107230 has been marked as a duplicate of this bug. ***
[Bug jit/107230] libgccjit rejects -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107230 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 66594 really which will cause the -march= to be defaulting to native ... *** This bug has been marked as a duplicate of bug 66594 ***
[Bug middle-end/107190] [aarch64] regression with optimization -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107190 --- Comment #3 from Andrew Pinski --- Created attachment 55113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55113=edit testcase
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 --- Comment #19 from Adelson Oliveira --- Thank you all Em qui., 18 de mai. de 2023 às 14:01, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> escreveu: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > > Status|ASSIGNED|RESOLVED >Target Milestone|--- |13.2 > Resolution|--- |FIXED > > --- Comment #18 from anlauf at gcc dot gnu.org --- > Fixed on mainline for gcc-14, and backported to 13-branch. Closing. > > Thanks for the report! > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/106810] Unexpected constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810
--- Comment #1 from Andrew Pinski ---
Reduced down just this:
```
template
concept t = requires(a aa, b bb) { aa == bb; };
template
struct I {
using value_type = int;
using difference_type = int;
value_type& operator*() const;
I& operator++();
I operator++(int);
template S>
friend bool operator==(I, S);
};
static_assert(t>);
```
I think GCC is correct in saying this is recusive even.
[Bug target/106471] -mpcu=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW Summary|Strange code generation for |-mpcu=generic might want to |__builtin_ctzl()|remove ||X86_TUNE_AVOID_FALSE_DEP_FO ||R_BMI now Ever confirmed|0 |1 --- Comment #8 from Andrew Pinski --- Confirmed. I will let someone else make the decision on when this happens.
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 --- Comment #4 from seurer at gcc dot gnu.org --- *** Bug 107915 has been marked as a duplicate of this bug. ***
[Bug other/107915] new test case g++.dg/contracts/contracts-tmpl-spec2.C in r13-4160-g2efb237ffc68ec fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107915 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from seurer at gcc dot gnu.org --- A PR on this was opened twice. *** This bug has been marked as a duplicate of bug 108321 ***
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Last reconfirmed||2023-05-18 Ever confirmed|0 |1 --- Comment #3 from seurer at gcc dot gnu.org --- The problem with g++.dg/contracts/contracts-tmpl-spec2.C has never been fixed as far as I can tell. It definitely occurs with the current r13. I believe the "This is fixed after r13-4290-g138ee8f7453ffd" was referring to the other mentioned issue. g:f48c546902802cf640c4f2802543acfdc702404f, r13-7354-gf48c546902802c make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/contracts/contracts-tmpl-spec2.C" FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test # of expected passes2 # of unexpected failures1 FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test Output was: contract violation in function body at g++.dg/contracts/contracts-tmpl-spec2.C:9: a > 0 [continue:on] -2 contract violation in function body at g++.dg/contracts/contracts-tmpl-spec2.C:17: a > 1 [continue:on] -3 contract violation in function none at g++.dg/contracts/contracts-tmpl-spec2.C:25: a > 0 [continue:on] 1 contract violation in function none at g++.dg/contracts/contracts-tmpl-spec2.C:32: a > 1 [continue:on] -101 contract violation in function arg0 at g++.dg/contracts/contracts-tmpl-spec2.C:39: t > 0 [continue:on] -9 contract violation in function arg0 at g++.dg/contracts/contracts-tmpl-spec2.C:46: t > 1 [continue:on] 11 contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:53: a > 0 [continue:on] contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:54: t > 0 [continue:on] -3 contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:61: a > 1 [continue:on] contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:62: t > 1 [continue:on] 14 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:69: a > 0 [continue:on] 1 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1 [continue:on] 3 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1 [continue:on] 3.30 contract violation in function g1 at g++.dg/contracts/contracts-tmpl-spec2.C:83: t > 0 [continue:on] -1 -1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:97: t > 0 [continue:on] -1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:107: t < 0 [continue:on] 1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:114: t < 'c' [continue:on] 100 contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:124: t > 0 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:125: s > 0 [continue:on] G3 general T S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:140: s > 1 [continue:on] G3 partial int S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:147: t > 2 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:148: s > 2 [continue:on] G3 full int double G3 general T S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1 [continue:on] G3 partial int S G3 full int C G3 full int C contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:173: t > 0 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:174: s > 0 [continue:on] G4 general T S contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:175: x > 0 [continue:on] G4 full double double contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:206: a > 0 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:207: b > 'b' [continue:on] G4 full double char contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:208: x > 1 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:187: t > 'c' [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:188: s > 3 [continue:on] G4 partial char S contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:189: x2 > 3 [continue:on] contract violation in function G5::f at g++.dg/contracts/contracts-tmpl-spec2.C:220: t > 0 [continue:on] contract violation in function G5::f at g++.dg/contracts/contracts-tmpl-spec2.C:221: s > 0
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904
--- Comment #10 from Jakub Jelinek ---
Offloading doesn't work for 32-bit architectures, the offloading target needs
to have the same wordsize as the host and e.g. nvptx 32-bit support has been
deprecated and removed some years ago.
So, don't configure offloading for 32-bit architectures.
As for adding -ldl automatically for -static linking, I think we should do:
2023-05-18 Jakub Jelinek
PR libgomp/109904
* configure.ac (link_gomp): Include also $DL_LIBS.
* configure: Regenerated.
--- libgomp/configure.ac.jj 2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure.ac2023-05-18 20:41:58.512501769 +0200
@@ -398,9 +398,9 @@ fi
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
- link_gomp="-lgomp %{static: $LIBS}"
+ link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
else
- link_gomp="-lgomp $LIBS"
+ link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
fi
AC_SUBST(link_gomp)
--- libgomp/configure.jj2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure 2023-05-18 20:42:12.703299052 +0200
@@ -16788,9 +16788,9 @@ fi
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
- link_gomp="-lgomp %{static: $LIBS}"
+ link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
else
- link_gomp="-lgomp $LIBS"
+ link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
fi
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #9 from Andrew Pinski --- See https://gcc.gnu.org/install/binaries.html Specifically: "Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers."
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #8 from GARY.WHITE at ColoState dot edu --- So send me the link where I should get the binaries from. Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 2:59 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #7 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #6) > So using -ldl seems really quirky. Doesn't seem to work for > generating 32-bit executables. Plus, not working at all on my second > machine. Is there a better solution? Yes use a differently built gcc where libgomp does NOT depend on dl* functions. Again this is not the right place to report these issues, the correct place is where you got the binary GCC from. In your case that would be https://github.com/brechtsanders/winlibs_mingw/issues . -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #7 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #6) > So using -ldl seems really quirky. Doesn't seem to work for generating > 32-bit executables. Plus, not working at all on my second machine. Is > there a better solution? Yes use a differently built gcc where libgomp does NOT depend on dl* functions. Again this is not the right place to report these issues, the correct place is where you got the binary GCC from. In your case that would be https://github.com/brechtsanders/winlibs_mingw/issues .
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #6 from GARY.WHITE at ColoState dot edu --- So using -ldl seems really quirky. Doesn't seem to work for generating 32-bit executables. Plus, not working at all on my second machine. Is there a better solution? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
--- Comment #4 from Andrew Pinski ---
Here is what I have so far without the cost model:
/* Hand bool0 CMP bool1 because bitwise operators
are normally better than comparisons. */
if (INTEGRAL_TYPE_P (type)
&& ((tree_nonzero_bits (arg0) == 1 && tree_nonzero_bits (arg1) == 1)
|| (unsignedp && TYPE_PRECISION (type) == 1)))
{
tree b0 = arg0;
tree b1 = arg1;
bool not_p = false;
bool operand1_not_p = false;
tree_code code = ERROR_MARK;
switch (ops->code)
{
case EQ_EXPR:
not_p = true;
code = BIT_XOR_EXPR;
break;
case NE_EXPR:
code = BIT_XOR_EXPR;
break;
case GT_EXPR:
std::swap (b0, b1);
code = BIT_AND_EXPR;
operand1_not_p = true;
break;
case LT_EXPR:
code = BIT_AND_EXPR;
operand1_not_p = true;
break;
case GE_EXPR:
std::swap (b0, b1);
code = BIT_IOR_EXPR;
operand1_not_p = true;
break;
case LE_EXPR:
code = BIT_IOR_EXPR;
operand1_not_p = true;
break;
default:
code = ERROR_MARK;
break;
}
if (code != ERROR_MARK)
{
tree exp;
tree one = build_int_cst (type, 1);
if (operand1_not_p)
b0 = build2_loc (loc, BIT_XOR_EXPR, type, b0, one);
exp = build2_loc (loc, code, type, b0, b1);
if (not_p)
exp = build2_loc (loc, BIT_XOR_EXPR, type, exp, one);
return expand_expr (exp, target, VOIDmode, EXPAND_NORMAL);
}
}
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Actually I need to check the cost, e.g. on MIPS, there is an one instruction > which does the less than without doing anything. RISCV too ...
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
--- Comment #2 from Andrew Pinski ---
Actually I need to check the cost, e.g. on MIPS, there is an one instruction
which does the less than without doing anything.
That is for:
bool f0(bool a, bool b)
{
return a
[Bug fortran/78798] [cleanup] some int-valued functions should be bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798 --- Comment #12 from CVS Commits --- The master branch has been updated by Bernhard Reutner-Fischer : https://gcc.gnu.org/g:c072df1ab144506cd8bb0ac81fb8f1aad69f0bd2 commit r14-973-gc072df1ab144506cd8bb0ac81fb8f1aad69f0bd2 Author: Bernhard Reutner-Fischer Date: Sat Nov 6 06:48:00 2021 +0100 Fortran: Narrow return types [PR78798] gcc/fortran/ChangeLog: PR fortran/78798 * array.cc (compare_bounds): Use narrower return type. (gfc_compare_array_spec): Likewise. (is_constant_element): Likewise. (gfc_constant_ac): Likewise. * check.cc (dim_rank_check): Likewise. * cpp.cc (gfc_cpp_init_options): Likewise. (dump_macro): Likewise. * cpp.h (gfc_cpp_handle_option): Likewise. * dependency.cc (gfc_ref_needs_temporary_p): Likewise. (gfc_check_argument_dependency): Likewise. (gfc_check_fncall_dependency): Likewise. (ref_same_as_full_array): Likewise. * dependency.h (gfc_check_fncall_dependency): Likewise. (gfc_dep_resolver): Likewise. (gfc_are_equivalenced_arrays): Likewise. * expr.cc (gfc_copy_ref): Likewise. (gfc_kind_max): Likewise. (numeric_type): Likewise. * gfortran.h (gfc_at_end): Likewise. (gfc_at_eof): Likewise. (gfc_at_bol): Likewise. (gfc_at_eol): Likewise. (gfc_define_undef_line): Likewise. (gfc_wide_is_printable): Likewise. (gfc_wide_is_digit): Likewise. (gfc_wide_fits_in_byte): Likewise. (gfc_find_sym_tree): Likewise. (gfc_generic_intrinsic): Likewise. (gfc_specific_intrinsic): Likewise. (gfc_intrinsic_actual_ok): Likewise. (gfc_has_vector_index): Likewise. (gfc_numeric_ts): Likewise. (gfc_impure_variable): Likewise. (gfc_pure): Likewise. (gfc_implicit_pure): Likewise. (gfc_elemental): Likewise. (gfc_pure_function): Likewise. (gfc_implicit_pure_function): Likewise. (gfc_compare_array_spec): Likewise. (gfc_constant_ac): Likewise. (gfc_expanded_ac): Likewise. (gfc_check_digit): Likewise. * intrinsic.cc (gfc_find_subroutine): Likewise. (gfc_generic_intrinsic): Likewise. (gfc_specific_intrinsic): Likewise. * io.cc (compare_to_allowed_values): Likewise. And remove unneeded forward declaration. * parse.cc: Likewise. * parse.h (gfc_check_do_variable): Likewise. * primary.cc (gfc_check_digit): Likewise. * resolve.cc (resolve_structure_cons): Likewise. (pure_stmt_function): Likewise. (gfc_pure_function): Likewise. (impure_stmt_fcn): Likewise. (resolve_forall_iterators): Likewise. (resolve_data): Likewise. (gfc_impure_variable): Likewise. (gfc_pure): Likewise. (gfc_unset_implicit_pure): Likewise. * scanner.cc (wide_is_ascii): Likewise. (gfc_wide_toupper): Likewise. (gfc_open_included_file): Likewise. (gfc_at_end): Likewise. (gfc_at_eof): Likewise. (gfc_at_bol): Likewise. (skip_comment_line): Likewise. (gfc_gobble_whitespace): Likewise. * symbol.cc (gfc_find_symtree_in_proc): Likewise. * trans-array.cc: Likewise. * trans-decl.cc (gfc_set_decl_assembler_name): Likewise. * trans-types.cc (gfc_get_element_type): Likewise. (gfc_add_field_to_struct): Likewise. * trans-types.h (gfc_copy_dt_decls_ifequal): Likewise. (gfc_return_by_reference): Likewise. (gfc_is_nodesc_array): Likewise. * trans.h (gfc_can_put_var_on_stack): Likewise.
[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 --- Comment #3 from Sergei Trofimovich --- (In reply to Jonathan Wakely from comment #2) > (In reply to Sergei Trofimovich from comment #0) > > --- gcc-12.2.0/gcc/Makefile.in 2022-08-19 10:09:52.280658631 +0200 > > +++ gcc-12.2.0-new/gcc/Makefile.in 2023-05-04 14:35:44.401420184 +0200 > > @@ -3781,6 +3781,11 @@ > > fi; \ > > fi > > > > +# We don't care about the order in which the info files are built, but > > +# install-info doesn't support multiple parallel invocations writing to > > +# the same `dir-file`, so we have to disable parallelism for that reason: > > +.NOTPARALLEL: install-info > > Prerequisites of .NOTPARALLEL are ignored, so doesn't this un-parallelize > building the entire gcc sub-dir? When I tested on small example '.NOTPARALLEL: target' serialized exactly prerequisites of 'target' and nothing more. 'info make' seems to confirm the behaviour: """ '.NOTPARALLEL' If '.NOTPARALLEL' is mentioned as a target with no prerequisites, all targets in this invocation of 'make' will be run serially, even if the '-j' option is given. Any recursively invoked 'make' command will still run recipes in parallel (unless its makefile also contains this target). If '.NOTPARALLEL' has targets as prerequisites, then all the prerequisites of those targets will be run serially. This implicitly adds a '.WAIT' between each prerequisite of the listed targets. *Note Disabling Parallel Execution: Parallel Disable. """ Here is the test that confirms it: $ cat Makefile all: a b a: 1 2 echo a 1: sleep 1 2: sleep 1 b: 3 4 echo b 3: sleep 1 4: sleep 1 .NOTPARALLEL: a $ make -j | LANG=C ts May 18 20:34:23 sleep 1 May 18 20:34:23 sleep 1 May 18 20:34:23 sleep 1 May 18 20:34:24 sleep 1 May 18 20:34:24 echo b May 18 20:34:24 b May 18 20:34:25 echo a May 18 20:34:25 a Note how it takes 'b' 1 second to finish (due to parallelism) while 'a' takes 2 seconds (targets are sequential).
[Bug debug/109902] gcc/g++ emits wrong column number in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109902
--- Comment #1 from Simon Farre ---
This is slightly off-topic, but still relevant to this discussion. In the
attachment,
we can see this line
" const auto res3 = b.set_foo (next_v ()).set_bar (next_v ()).set_baz (next_v
()).finalize ([] (auto v) { return v * 3; });"
-- GCC --
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x004011ee 68 31 1 0 0 is_stmt
0x00401206 68 51 1 0 0 is_stmt
0x00401218 68 71 1 0 0 is_stmt
0x00401227 68 92 1 0 0 is_stmt
0x004012ee 68 93 1 0 0 is_stmt
0x004012f9 68118 1 0 0 is_stmt
0x00401302 68121 1 0 0 is_stmt
where as clang outputs:
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x004011fd 68 32 1 0 0 is_stmt
0x0040120b 68 23 1 0 0
0x00401217 68 52 1 0 0
0x00401225 68 43 1 0 0
0x00401231 68 72 1 0 0
0x0040123f 68 63 1 0 0
0x00401247 68 83 1 0 0
0x00401450 68 0 1 0 0 is_stmt
0x0040145b 68116 1 0 0 is_stmt prologue_end
0x0040145f 68107 1 0 0
0x00401461 68107 1 0 0 end_sequence
As we can see, clang outputs information to the actual column meta data for
calls at parameter sites whereas GCC does not. Providing these positions in
source code opens up for "ergonomics-features", particularly in GDB as GDB can
more easily determine sites of interest to step to, set breakpoints at, etc.
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Last reconfirmed||2023-05-18
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Andrew Pinski ---
I have a patch.
It even handles:
unsigned f(unsigned a, unsigned b)
{
if (a > 1) __builtin_unreachable();
if (b > 1) __builtin_unreachable();
return a
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #5 from GARY.WHITE at ColoState dot edu --- I'm getting gfortran downloads from here: https://github.com/brechtsanders/winlibs_mingw/releases Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #3 from GARY.WHITE at ColoState dot edu --- Linking with -ldl fixed the issue Where is there documentation of -ldl? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:11 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #1 from Andrew Pinski --- >--enable-offload-targets=nvptx-none I suspect this might be the issue. offloading only works with targets that have dlopen . Maybe you need to link with -ldl to get it working. -- You are receiving this mail because: You reported the bug.
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I guess if var_type is ARRAY_TYPE, then it shouldn't call build_special_member_call with complete_dtor_identifier, but should do something like build_vec_delete_1 does around it. Though, seems coroutines.cc calls build_special_member_call with complete_dtor_identifier in 12 different spots, which of those could be ARRAY_TYPEs is unclear to me.
[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 --- Comment #18 from Hans-Peter Nilsson --- (In reply to Jiu Fu Guo from comment #17) > > But "nobody" counts that close, so better say "no xtreme-header-* failures > > since r13-5702-g72058eea9d407e". > > :) Since these failures occur erratically, They did at the time for cris-elf (too), but I believe the cause of *those* failures has been fixed. > so maybe reopen this or open a > new one if the failures are reproduced. That's the idea. :) > As two xtreme-header-5_ failures (not ICE) occur in Results for 14.0.0 > 20230518: https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/784674.html. Good to know, but not for cris-elf.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- In fact I noticed this on the configure comand line: -I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32 Please report this issue to where you got the binary builds of GCC from and ask them about providing libdl-win32 to you too.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #1 from Andrew Pinski --- >--enable-offload-targets=nvptx-none I suspect this might be the issue. offloading only works with targets that have dlopen . Maybe you need to link with -ldl to get it working.
[Bug fortran/109904] New: linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 Bug ID: 109904 Summary: linking with -static flag generates undefined references Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- What follows are a portion of the undefined references when using -static with gfortran-13. I require the -static flag to be able to distribute executable to users not having gfortran on their machines. gfortran -m64 -fopenmp mark.o glabrd.o xmatrx.o tmread.o rlabrd.o blabrd.o dlabrd.o estmat.o varmat.o derivedest.o piread.o func.o saturd.o chprob.o chprob001.o chprob002.o chprob008.o chprob009.o chprob032.o chprob115.o chprob119.o chprob121.o chprob126.o chprob139.o chprob140.o chprob141.o chprob142.o chprob143.o chprob144.o chprob160.o chprob170.o chprob171.o chprob172.o chprob173.o chprob174.o chprob175.o chprob176.o chprob177.o chprob178.o chprob179.o chprob180.o chprob181.o chprob182.o chprob183.o chprob184.o rcread.o kfread.o nsread.o optmiz.o status_module.o prcisub.o prfunc.o mcmc.o hyperread.o gibbsitsub.o optimizers_module.o gaussquad.o hyper_dist_module.o profile_conf_interval_module.o data_module.o design_matrix_funcs_module.o random_values_module.o Linpack.a -o mark64.exe -static -static-libgfortran C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x94f): undefined reference to `dlopen' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x96a): undefined reference to `dlsym' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x99f): undefined reference to `dlclose' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(oacc-profiling.o):(.text+0x83d): undefined reference to `dlerror' Specifics of the installation of gfortran are: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=C:/tdm-gcc-64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/R/winlibs64ucrt_stage/inst_gcc-13.1.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --enable-libstdcxx-pch --with-mpc=/d/Prog/winlibs64ucrt_stage/custombuilt --with-mpfr=/d/Prog/winlibs64ucrt_stage/custombuilt --with-gmp=/d/Prog/winlibs64ucrt_stage/custombuilt --with-isl=/d/Prog/winlibs64ucrt_stage/custombuilt --enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64ucrt_stage/gcc-13.1.0/build_mingw/mingw-w64 CFLAGS='-I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32 -Wno-int-conversion' CXXFLAGS=-Wno-int-conversion LDFLAGS='-pthread -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders)
[Bug tree-optimization/106379] DCE depends on order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Depends on||106380 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Severity|normal |enhancement --- Comment #5 from Andrew Pinski --- _1 = ~c_5(D); _2 = _1 & s_4(D); Mine. That is `c < s`. So the same as PR 106380 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 [Bug 106380] DCE depends on datatype used (bool vs unsigned)
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- (In reply to Patrick Palka from comment #5) > Seems related to PR89144 too -- there we were mishandling defining a > non-dependent static std::initializer_list member variable, here we're > subsequently trying to use it. The issue there is that the initializer_list wasn't static, but here it is, so the array temporary should be as well. And presumably the problem is that we aren't representing that lifetime extension in a template. And checking the initializer gives up on trying to enforce that. But then when we try to evaluate the template argument we find that we don't have a constant value to work with, and complain. Instead, we should probably treat num as value-dependent even though it actually isn't. Or fix it to be properly evaluated by representing the lifetime extension somehow.
[Bug tree-optimization/106381] DCE depends on used programming language (C vs C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Actually it is worse in GCC 13. Both the C and C++ front-ends produced IR does not get optimized.
[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-18 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine. In this case if we fold: _1 = ~s_4(D); _2 = _1 & c_5(D); to s < c Then the rest will be optimized by normally.
[Bug tree-optimization/106185] Spurious Wstringop-overflow in std::vector::resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106185 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- This looks to be fixed in GCC 13. I think there was a missed optimization which is being caught now. It would be interesting to know which patch fixed the warning (and missed optimization).
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89144 CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Seems related to PR89144 too -- there we were mishandling defining a non-dependent static std::initializer_list member variable, here we're subsequently trying to use it.
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.2 Resolution|--- |FIXED --- Comment #18 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report!
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f48c546902802cf640c4f2802543acfdc702404f commit r13-7354-gf48c546902802cf640c4f2802543acfdc702404f Author: Harald Anlauf Date: Sun May 14 21:53:51 2023 +0200 Fortran: CLASS pointer function result in variable definition context [PR109846] gcc/fortran/ChangeLog: PR fortran/109846 * expr.cc (gfc_check_vardef_context): Check appropriate pointer attribute for CLASS vs. non-CLASS function result in variable definition context. gcc/testsuite/ChangeLog: PR fortran/109846 * gfortran.dg/ptr-func-5.f90: New test. (cherry picked from commit fa0569e90efe8a5cb895a3f50dd502f849940828)
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 --- Comment #17 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:611be07e48956c8b7371eb580eef124990114fd3 commit r13-7353-g611be07e48956c8b7371eb580eef124990114fd3 Author: Harald Anlauf Date: Fri May 5 21:22:12 2023 +0200 Fortran: overloading of intrinsic binary operators [PR109641] Fortran allows overloading of intrinsic operators also for operands of numeric intrinsic types. The intrinsic operator versions are used according to the rules of F2018 table 10.2 and imply type conversion as long as the operand ranks are conformable. Otherwise no type conversion shall be performed to allow the resolution of a matching user-defined operator. gcc/fortran/ChangeLog: PR fortran/109641 * arith.cc (eval_intrinsic): Check conformability of ranks of operands for intrinsic binary operators before performing type conversions. * gfortran.h (gfc_op_rank_conformable): Add prototype. * resolve.cc (resolve_operator): Check conformability of ranks of operands for intrinsic binary operators before performing type conversions. (gfc_op_rank_conformable): New helper function to compare ranks of operands of binary operator. gcc/testsuite/ChangeLog: PR fortran/109641 * gfortran.dg/overload_5.f90: New test. (cherry picked from commit 185da7c2014ba41f38dd62cc719873ebf020b076)
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #27 from rguenther at suse dot de --- > Am 18.05.2023 um 10:31 schrieb amonakov at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 > > --- Comment #25 from Alexander Monakov --- > (In reply to Richard Biener from comment #24) >> As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH >> though since at least when no extra negations are required the contraction >> should also be a win when optimizing for size? > > Makes sense, I'll change that (current target hooks always return true for > fma). > >> Also I wondered about the PROP_gimple_any check - do we get into the >> gimplification langhook after lowering? I see we are not resetting the >> langhook after lowering (only in free-lang-data, but that only runs with >> LTO). > > Yes, that surprised me. I caught it when analyzing ICE on slp-50.c testcase. > >> We probably at least should gate the langhook invocation in the gimplifier >> with what you added in the patch or specify whether the gimplifier is >> invoked from the middle-end via the gimplifier context. > > Perhaps. I'll add a comment that we want to handle -ffp-contract=on strictly > during initial gimplification, to hash this out further on gcc-patches, if > necessary. > >> If we go for c-family only the genericize entry could be another place to >> handle this. > > That seems less convenient to me. Is IFN_FMA representable as a tree? Yes, that’s possible. Let’s see if others have an opinion on the ml. >> Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the >> multiplication btw? > > No, I'm not familiar with those, so I didn't try to construct corresponding > testcases. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106143 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105826] failure to compile namespace-scope constexpr new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105826 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #6 from Dimitri Gorokhovik --- Thank you Andrew, I indeed see now the early-clobber effect of this code. It isn't that we don't read documentation (we do time to time), rather our real asm statement has more output ops and more elementary instructions in the template, so the early-clobber effect doesn't jump to the eye quite as easily. I guess we have to mask all output ops as early clobbers.
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #26 from Alexander Monakov --- > > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the > > multiplication btw? > > No, I'm not familiar with those, so I didn't try to construct corresponding > testcases. I had a look now. My understanding is they are eliminated in c_fully_fold, so c_gimplify_expr will not encounter those trees.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #8 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #7) > Oops, if I'd typed PEDASSERT not PEDANTIC, it would be a deliberate choice > ;-) > > Yes, I think PEDASSERT fits better, based on the documented meaning of it > (which even mentions the std::string((const char*)nullptr) case): > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html Ccan we add a "pednonnull" attribute or something to produce a -Wnonnull warning like the nonnull attribute but w/o affecting code generation as well? I remember we've discussed "adding nonnull attribute for basic_ostream::operator<<" and the idea was rejected because the nonnull attribute would throw away the null pointer check.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #5 from Andrew Pinski --- (In reply to Dimitri Gorokhovik from comment #4) > Hi Andrew, > > I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We > want to spare the same hassle to others. Why you didn't read the documentation which is documents inline-asm. And there is no way for GCC to know what you mean. > > This asm doesn't write to memory, it doesn't even read any -- 'a' is passed > over in the registers with aarch64 and x64_86. Oh I read the instruction wrong. > > It is also very hard to see the need for early clobber here ... how comes > the version with return value doesn't need it while the other does? The asm > performs regular register loads. Certainly we are not marking all register > loads with early clobbers are we? The easy and fast rule is simple. If you write to an output operand before read from an input operand, that output operand needs an early clobber. This is how I knew what the issue was right away without even looking further into what was going wrong. Even the documentation is clear here: "Means (in a particular alternative) that this operand is an earlyclobber operand, which is written before the instruction is finished using the input operands." The reason why sometimes it works sometimes it does not work is depedent on the register allocator. In the case of return and first argument registers, well usually those are the same register so the register allocator wants to minimalize the number of spills and/or register moves. > > WE ended up moving 'a' to output clause, it feels barely more contorted than > the early-clobber method. That is actually WRONG and will produce wrong code in some cases. The early clobber is the right appoarch here if you are writing to an operand before you use all of the input operands (again this is all DOCUMENTED and has been for the over 10 years now). > > > GCC does not look at the inline-asm template except while outputting the > > assembly. > Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 --- Comment #9 from Jan-Benedict Glaw --- All three target configurations reported a successful build. Thanks!
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 98821, which changed state. Bug 98821 Summary: modules : c++tools configures with CC but code fragments assume CXX. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- fixed on relevant branches.
[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:ae5112f230f05e8a693931a44bf2fd20bef58f85 commit r11-10792-gae5112f230f05e8a693931a44bf2fd20bef58f85 Author: Iain Sandoe Date: Tue Jul 20 14:00:38 2021 +0100 c++tools, configury: Configure with C++; test checking status [PR98821]. The c++tools configure fragments need to be built with a C++ compiler. In addition, the stand-alone server uses diagnostic mechanisms in common with GCC, but needs to define implementations for gcc_assert and supporting output functions. Signed-off-by: Iain Sandoe PR c++/98821 - modules : c++tools configures with CC but code fragments assume CXX. PR c++/98821 c++tools/ChangeLog: * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Configure using C++. Pull logic to detect enabled checking modes; default to release checking. * server.cc (AI_NUMERICSERV): Define a fallback value. (gcc_assert): New. (gcc_unreachable): New. (fancy_abort): Only build when checking is enabled. Co-authored-by: Jakub Jelinek (cherry picked from commit e4d306cf706eef83f99d510c308eda1539d05875)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #7 from Jonathan Wakely --- Oops, if I'd typed PEDASSERT not PEDANTIC, it would be a deliberate choice ;-) Yes, I think PEDASSERT fits better, based on the documented meaning of it (which even mentions the std::string((const char*)nullptr) case): https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #4 from Dimitri Gorokhovik --- Hi Andrew, I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We want to spare the same hassle to others. This asm doesn't write to memory, it doesn't even read any -- 'a' is passed over in the registers with aarch64 and x64_86. It is also very hard to see the need for early clobber here ... how comes the version with return value doesn't need it while the other does? The asm performs regular register loads. Certainly we are not marking all register loads with early clobbers are we? WE ended up moving 'a' to output clause, it feels barely more contorted than the early-clobber method. > GCC does not look at the inline-asm template except while outputting the > assembly. Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #6 from Michel Morin --- True. Detectable is not correct — that's "maybe-detectable" at most, and the bug is not silent. In a code that I checked, the buggy code (`std::cout << NullCharPtr;`) is the last printing call to std::cout, so I failed to see the side-effect. The patchlet using `_GLIBCXX_DEBUG_PEDASSERT` works fine. Actually I would like `_GLIBCXX_DEBUG_ASSERT` (because I've been using `_GLIBCXX_DEBUG` but never `_GLIBCXX_DEBUG_PEDANTIC`), but I guess using `_GLIBCXX_DEBUG_PEDASSERT` rather than `_GLIBCXX_DEBUG_ASSERT` in this case is a delibarate choice.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #3 from Andrew Pinski --- One more thing, GCC does not look at the inline-asm template except while outputting the assembly.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903
--- Comment #2 from Andrew Pinski ---
That is the inline-asm should be written as:
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=" (v)
: [_2] "r" (a)
: "memory");
Note since a is memory address you are writing to you should also add the
memory clobber to the inline-asm.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You need to use an early clobber on the output constraint as documented. https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Modifiers.html#index-earlyclobber-operand
[Bug target/109903] New: Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903
Bug ID: 109903
Summary: Register misallocation in hand-crafted asm insn, no
diagnostics produced
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
For the source code:
#if NO_BUG
unsigned long f (unsigned long a)
{
unsigned long v;
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=r" (v)
: [_2] "r" (a)
);
return v;
}
#else // BUG
extern void g(unsigned long);
void f (unsigned long a)
{
unsigned long v;
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=r" (v)
: [_2] "r" (a)
);
g(v);
}
#endif
The asm output produced is:
## BUG
#APP
# 23 "bug.c" 1
mrs %rdi, pmccntr_eli0
ldr x1, [%rdi]
# 0 "" 2
#NO_APP
## NO_BUG
#APP
# 6 "bug.c" 1
mrs %rax, pmccntr_eli0
ldr x1, [%rdi]
# 0 "" 2
#NO_APP
As one can see, in the "NO BUG" case, the registers allocated to reading "the
counter" and to reading "memory", are different, whereas they are one and the
same in the "BUG" case.
This was obtained with today's trunk built for native compilation: gcc (GCC)
14.0.0 20230518 (experimental).
The example was compiled as:
gcc -S -O3 -Wall -Wextra -o bug.S bug.c
no diagnostic messages are produced.
Same was also observed with gcc-aarch64-none-linux toolchain 13.2 (from Arm
download page), so "target-related issue" might not be an entirely correct
classification for this.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Fixed on trunk (and some other cases of == elsewhere). Thanks for the patch and report.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:120e444974e12eb727eea170a3bfd80783e3851f commit r14-970-g120e444974e12eb727eea170a3bfd80783e3851f Author: Jonathan Wakely Date: Thu May 18 10:18:19 2023 +0100 contrib: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. These contrib scripts all use a bash shebang so == does work, but there's no reason they can't just use the more portable form anyway. PR bootstrap/105831 contrib/ChangeLog: * bench-stringop: Use = operator instead of ==. * repro_fail: Likewise. contrib/reghunt/ChangeLog: * bin/reg-hunt: Use = operator instead of ==.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6e2fbe4f345f48ae3c8ba5bfbc1a7b783b398614 commit r14-969-g6e2fbe4f345f48ae3c8ba5bfbc1a7b783b398614 Author: Jonathan Wakely Date: Thu May 18 10:18:19 2023 +0100 gcc: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. The gen_directive_tests script uses a bash shebang so == does work, but there's no reason this script can't just use the more portable form anyway. PR bootstrap/105831 gcc/ChangeLog: * config.gcc: Use = operator instead of ==. gcc/testsuite/ChangeLog: * gcc.test-framework/gen_directive_tests: Use = operator instead of ==.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:95b93adcac69536bab617e045149719ec69099ae commit r14-968-g95b93adcac69536bab617e045149719ec69099ae Author: Michael Bäuerle Date: Thu May 18 10:15:49 2023 +0100 gcc: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. gcc/ChangeLog: PR bootstrap/105831 * config/nvptx/gen-opt.sh: Use = operator instead of ==. * configure.ac: Likewise. * configure: Regenerate.
[Bug tree-optimization/105776] Failure to recognize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 55112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55112=edit gcc14-pr105776.patch Untested fix.
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #7 from Thiago Macieira --- (In reply to Jonathan Wakely from comment #6) > With placement-new there's no allocation: > https://gcc.godbolt.org/z/68e4PaeYz Is the exception expected there, though?
[Bug target/109811] libjxl 0.7 is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 --- Comment #11 from Jan Hubicka --- I got -fprofile-use builds working and with profile we peel the innermost loop 8 times which actually gets it off the hottest spot. We get more slective on what to inline (do not inline cold calls) which may make the dependency on SRA even worse
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #5 from Marek Polacek --- (gdb) up #1 0x00e5de6f in check_noexcept_r (tp=0x7fffa0a8, walk_subtrees=0x7fff9f94) at /home/mpolacek/src/gcc/gcc/cp/except.cc:1065 1065 gcc_assert (INDIRECT_TYPE_P (type)); (gdb) p type $1 = (gdb) pge void class1:: (struct class1 *)
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Marek Polacek --- Seems to have started with r12-7069: commit 119cea98f664764cce04963243c39c8f6d797d33 Author: Jason Merrill Date: Wed Feb 2 18:36:41 2022 -0500 c++: assignment, aggregate, array [PR104300]
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #13 from Matt Godbolt --- Thanks Andrew!
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #10 from Jan Hubicka --- Thanks. I tested the patch on jpegxl and it does not help there (I guess becuase the redundancy there is partial). But it is cool we compile at least the simplified testcase well.
[Bug c/106465] ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465 --- Comment #5 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug c/108423] [12/13/14 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423 --- Comment #10 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #6 from Jonathan Wakely --- Submitted as https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618914.html
[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 --- Comment #10 from Martin Uecker --- PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug c/109450] VLA struct definition vs use in the function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450 --- Comment #3 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug sanitizer/109882] sanitizer/common_interface_defs.h bogusly defines __has_feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 --- Comment #8 from Jonathan Wakely --- Submitted upstream as https://reviews.llvm.org/D150866
[Bug debug/109902] New: gcc/g++ emits wrong column number in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109902
Bug ID: 109902
Summary: gcc/g++ emits wrong column number in DWARF
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.farre.cx at gmail dot com
Target Milestone: ---
Created attachment 55111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55111=edit
Contains GCC & clang dwarfdump output as well as simple source code.
The DWARF spec, states in paragraph 2.14 "Declaration Coordinates" (version 5,
https://dwarfstd.org/doc/DWARF5.pdf) that:
"The value of the DW_AT_decl_column attribute represents the source column
number at which the first character of the identifier of the declared object
appears. The value 0 indicates that no column has been specified."
Below is an example of contrived C++ code:
auto b = setfoo().setbar().setbaz();
gcc emits column meta data at these positions (represented by _):
auto b = setfoo_().setbar_().setbaz_();
Whereas for instance clang emits it properly, according to spec:
auto b = _setfoo()._setbar()._setbaz();
So for the following code:
" const auto res1 = b.set_foo (10).set_bar (20).set_baz (30).finalize ([]
(auto v) { return v * 2; });"
The following line number program is emitted (the line number is 66 and set_foo
begins on column position 23)
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x00401150 66 31 1 0 0 is_stmt
0x00401161 66 44 1 0 0 is_stmt
0x0040116e 66 57 1 0 0 is_stmt
0x0040117b 66 71 1 0 0 is_stmt
0x0040126c 66 72 1 0 0 is_stmt
0x00401277 66 97 1 0 0 is_stmt
0x0040127c 66100 1 0 0 is_stmt
Where as clang emits:
0x0040114b 66 23 1 0 0 is_stmt
0x0040115e 66 36 1 0 0
0x00401171 66 49 1 0 0
0x00401179 66 62 1 0 0
0x00401430 66 0 1 0 0 is_stmt
0x0040143b 66 93 1 0 0 is_stmt prologue_end
0x0040143e 66 95 1 0 0
0x00401441 66 86 1 0 0
It's also questionable if GCC emits the correct meta data with respect to
statements, but I guess that's a different issue.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #9 from Richard Biener --- Created attachment 55110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55110=edit patch for the missed hoisting For the testcase in comment#6 there is a missing code hoisting from PRE which is caused by do_hoist_insertion doing /* A hoistable value must be in ANTIC_IN(block) but not in AVAIL_OUT(BLOCK). */ bitmap_initialize (_set.values, _bitmap_obstack); bitmap_and_compl (_set.values, _IN (block)->values, _OUT (block)->values); but in reality we want to check ANTIC_OUT(block), not ANTIC_IN(block). cur.second is killed by the aggregate assignment to cur at the beginning of the block we should hoist to and that's reflected in ANTIC_IN. The attached patch properly re-computes ANTIC_OUT and uses that.
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 Stam Markianos-Wright changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Stam Markianos-Wright --- Fixed on GCC12 onwards.
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
On 18/05/23 12:01 +0100, Jonathan Wakely wrote: This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks. Note however, that GCC 9 is no longer supported by gcc.gnu.org, and the GCC project does not create CVEs. You should probably report this to vendors who are distributing gcc-arm-none-eabi-9 so they can fix it and get a CVE if needed.
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks.
Stack Canary Security Issue in gcc-arm-none-eabi-9
Hello,
I encountered a security issue affecting gcc-arm-none-eabi-9, causing it to
produce ineffective stack protection. The issue is public as it was
described in a blog on May 2021
https://blog.inhq.net/posts/faulty-stack-canary-arm-systems/ by Christian
Reitter. However it was never reported as a bug in an active platform*, so
no fix was issued and no CVE was assigned to it.
As this is a major security issue I think it would be good if a CVE was
issued to alert developers and vendors still using GCC 9.
Short issue description (see Reitter's blog for comprehensive details):
Older versions of gcc-arm-none-eabi, such as
gcc-arm-none-eabi-9-2019-q4-major, have a bug where the global address of
the stack guard is placed on the stack as a canary rather than the actual
value of the stack guard. This undermines the purpose of the protection as
it makes the canary value knowable. In addition, the embedded environments
that this toolchain targets often lack Address Space Layout Randomization,
meaning the global guard address is in itself constant, making the
protection entirely ineffective.
See the following code and results built with
gcc-arm-none-eabi-9-2019-q4-major and targeting arm cortex m-33.
*Code (also attached as check_stack_protection.c):*
extern uint32_t *__stack_chk_guard;
bool check_stack_bug(uint32_t const *data, int dump_len)
{
for (int i = 0; i < dump_len; i++)
{
console_printf("%p : %p\n", [i], data[i]);
if (data[i] == (const uint32_t)&__stack_chk_guard)
{
console_printf(
"canary is at offset %d from dummy and equals to the
address of __stack_chk_guard\n",
i);
return true;
}
}
return false;
}
static int app_stack_guard_cmd_handler()
{
// A dummy var to get the stack frame address
uint32_t dummy = 0x57AC57AC;
bool is_buggy = check_stack_bug((uint32_t const *), 5);
if (is_buggy)
console_printf("stack protection bug detected\n");
}
*output (also attached as output.c):*
Stack dump:
0x2013bdb8 : 0x57ac57ac
0x2013bdbc : 0x2012f83c
canary is at offset 1 from dummy and equals to the address of
__stack_chk_guard
stack protection bug detected
*binary (also attached as binary_prologue_epiloguge.txt):*
Canary setting:
8ad48: 1a 4a ldr r2, [pc, #104]
8ad4a: 83 b0 sub sp, #12
8ad4c: 12 68 ldr r2, [r2]
8ad4e: 01 92 str r2, [sp, #4]
canary check:
8ad8a: 0a 4b ldr r3, [pc, #40]
8ad8c: 1a 68 ldr r2, [r3]
8ad8e: 01 9b ldr r3, [sp, #4]
8ad90: 5a 40 eors r2, r3
Thank you,
Magal Baz
*It reported in an appeartnly inactive platform in 2020
https://answers.launchpad.net/gcc-arm-embedded/+question/689391 by Daniel
Worley.
8ad48: 1a 4a ldr r2, [pc, #104] @ 0x8adb4 <$d+0x4>
8ad4a: 83 b0 sub sp, #12
8ad4c: 12 68 ldr r2, [r2]
8ad4e: 01 92 str r2, [sp, #4]
canary check:
8ad8a: 0a 4b ldr r3, [pc, #40] @ 0x8adb4 <$d+0x4>
8ad8c: 1a 68 ldr r2, [r3]
8ad8e: 01 9b ldr r3, [sp, #4]
8ad90: 5a 40 eorsr2, r3
check_stack_protection.c
Description: Binary data
Stack dump:
0x2013bdb8 : 0x57ac57ac
0x2013bdbc : 0x2012f83c
canary is at offset 1 from dummy and equals to the address of __stack_chk_guard
stack protection bug detected
