[Bug tree-optimization/113078] [14 regression] reduction of cond_sub is not vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113078 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- We special case MINUS_EXPR but likely fail to do the same to COND_SUB in reduction discovery (vect_is_simple_reduction) and/or vectorizable_reduction. I will have a look (possibly only next year).
[Bug target/113076] [14] RISC-V: gfortran.dg/dec_io_1.f90 runtime error after r14-4971-g0beb1611754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113076 Richard Biener changed: What|Removed |Added Target||riscv --- Comment #1 from Richard Biener --- The bisection is highly suspicious since that's a x86 specific change that doesn't affect riscv.
[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113073 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-12-19 --- Comment #1 from Richard Biener --- Hmm, OK. This is because of else if (alignment_support_scheme == dr_aligned) /* Aligned access to excess elements is OK if at least one element is accessed in the scalar loop. */ ; it seems we're using dr_aligned when the target is happy with element alignment, not only when the full vector is aligned according to its size. I have a patch that instead produces fn1: .LFB0: lui a5,%hi(.LANCHOR0) addia5,a5,%lo(.LANCHOR0) vsetivlizero,4,e32,m1,ta,ma lw a3,8(a0) vlse32.vv1,0(a0),zero lw a4,4(a0) lui a6,%hi(a) li a7,-1 addia1,a5,40 addia2,a5,20 vmv.v.x v2,a3 vse32.v v1,0(a5) sw a7,%lo(a)(a6) vmv.v.x v1,a4 vse32.v v2,0(a1) vse32.v v1,0(a2) ret
[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/113082] builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
--- Comment #3 from rguenther at suse dot de ---
On Tue, 19 Dec 2023, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
>
> --- Comment #2 from Florian Weimer ---
> (In reply to Richard Biener from comment #1)
> > Joseph - I wonder if the standard folks can be convinced to amend most
> > library function documentation as to not altering 'errno' (like memcpy,
> > strlen, etc.)?
> >
> > Should we simply document our constraints on supported library
> > implementations?
>
> We can add attributes to the glibc headers, similar to the throw and leaf
> annotation we have today. It would act as a reminder that if we clobber errno
> in these functions due to some implementation detail, we need to save/restore
> errno.
I guess a new 'noerrno' attribute would make sense. What I've always
wanted is also a reliable way to distinguish accesses to 'errno'
from other accesses (unfortunately 'errno' is an lvalue so it's
address can be taken). glibc uses __errno_location (), so an
additional attribute indicating the function returns the address
of 'errno' would be nice to have as well ('errno', just like we
have 'malloc' for malloc results?). At the moment we can just
use TBAA ('errno' is an lvalue of type 'int') for disambiguation
but 'int' is a bit generic for that to be of much help.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #15 from David Binderman --- (In reply to Jonathan Wakely from comment #12) > Because otherwise I'm going to get blamed for every bug older than > 2022-11-01! > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1 My apologies for this. AFAIK sheer fluke git produced your name twice. I have extended my local history out to 20210101, nearly three years. That should reduce the size of the problem and I now know where to get full history.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #51 from David Brown --- (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library or > any future library that the resulting binary may be dynamically linked > against.) > > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. There are several real-world benefits from transforming back and forth between library calls for this kind of small standard library function. One is that turning explicit code into library calls can give smaller code - often of importance in small embedded targets. Sometimes it can also result in run-time improvements, especially for larger data sizes - user-written code might just copy byte by byte, while the library implementation uses more efficient larger blocks. Another is that turning library calls into inlined code can speed up code by using additional knowledge of sizes, alignment, etc., to get faster results. This is most obvious for calls to memcpy() or memmove(), which can sometimes be required to get the semantics correct for type manipulation, but may generate no actual code at all. A "C implementation" consists of a compiler and a standard library in tandem. The C library can make use of its knowledge of the C compiler, and any special features, in its implementation. (This is, in fact, required - some things in the standard library cannot be implemented in "pure" C.) The C compiler can make use of its knowledge of the library implementation in its code generation or analysis. For the most part, compilers only make use of their knowledge of the specifications of standard library functions, but they might also use implementation details. This means it is quite legitimate for the GCC team to say that gcc requires a C library that does not set errno except for functions that explicitly say so in their specifications. Users don't get to mix and match random compilers and random standard libraries and assume they form a conforming C implementation - the pair must always be checked for compatibility. The question then is if this would be an onerous requirement for standard library implementations - do common existing libraries set errno in functions that don't require it? I cannot say, but I would be very surprised if they did. Modern thought, AFAIUI, considers errno to be a bad idea which should be avoided whenever possible - it is a hinder to optimisation, analysis, and parallelisation of code, as well as severely limiting C++ constexpr and other compile-time calculations. My thoughts here are that GCC should make this library requirement explicit and public, after first confirming with some "big name" libraries like glibc, newlib and muslc. They could also add a flag "-funknown-stdlib" to disable any transforms back or forth between standard library calls, and assume nothing about the calls (not even what is given in the standards specifications). (As a note - the paragraph 7.5p3 allowing standard library functions to set errno is still in the current draft of C23.)
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #14 from David Binderman --- (In reply to Andrew Pinski from comment #9) > Does it work correctly without valgrind? Yes. No one has yet attempted to reproduce my results. vld1q_u8 is a 128 bit ARM hardware instruction. I assume that the requirements for this instruction are not being met in some way by some data. Maybe a short string ?
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 Francois-Xavier Coudert changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-19 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Decembe ||r/640943.html Ever confirmed|0 |1 --- Comment #4 from Francois-Xavier Coudert --- I introduced the original behaviour and I'm not sure I remember why. I've propose to remove the duplication, because I cannot see a single case where it could be useful. Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640943.html
[Bug middle-end/113082] builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 --- Comment #2 from Florian Weimer --- (In reply to Richard Biener from comment #1) > Joseph - I wonder if the standard folks can be convinced to amend most > library function documentation as to not altering 'errno' (like memcpy, > strlen, etc.)? > > Should we simply document our constraints on supported library > implementations? We can add attributes to the glibc headers, similar to the throw and leaf annotation we have today. It would act as a reminder that if we clobber errno in these functions due to some implementation detail, we need to save/restore errno.
[Bug middle-end/113082] builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-12-19 Status|UNCONFIRMED |NEW CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Joseph - I wonder if the standard folks can be convinced to amend most library function documentation as to not altering 'errno' (like memcpy, strlen, etc.)? Should we simply document our constraints on supported library implementations?
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113082 --- Comment #50 from Richard Biener --- Split out to PR113082.
[Bug middle-end/113082] New: builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 Bug ID: 113082 Summary: builtin transforms do not honor errno Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- This was split out from PR56888. gcc is changing a program that can rely on errno not being changed to one where the C library can change it. (The current C library or any future library that the resulting binary may be dynamically linked against.) The library is allowed to alter errno when not documented otherwise by 7.5p3 Quoting from the PRs last comment: (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library or > any future library that the resulting binary may be dynamically linked > against.) Ick. Standards continue to surprise me ;) > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. People are good in writing inefficient code and replacing say, an open coded strlen by an actual call to strlen enables followup transforms that rely on strlen appearing as strlen and not an open-coded variant (I realize that technically one might find a way to implement that without actually emitting a call in the end). And yes, optimizing (repeated) calls of strlen or replacing open-coded large memcpy by a library call to optimized functions can make a noticable difference even for non-benchmarks. We're currently generating calls to memcpy, memmove, memset and strlen. We are also replacing memmove with memcpy, printf with puts or putc, all of those transforms are then invalid because of (1) as well. We are treating -fno-math-errno as applying to non-math functions and we don't have any -fno-errno or way of analyzing/annotating whether a program is interested in the state of errno (not only but mainly because identifying accesses to errno is non-trivial).
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #49 from Richard Biener --- (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library or > any future library that the resulting binary may be dynamically linked > against.) Ick. Standards continue to surprise me ;) > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. People are good in writing inefficient code and replacing say, an open coded strlen by an actual call to strlen enables followup transforms that rely on strlen appearing as strlen and not an open-coded variant (I realize that technically one might find a way to implement that without actually emitting a call in the end). And yes, optimizing (repeated) calls of strlen or replacing open-coded large memcpy by a library call to optimized functions can make a noticable difference even for non-benchmarks. We're currently generating calls to memcpy, memmove, memset and strlen. We are also replacing memmove with memcpy, printf with puts or putc, all of those transforms are then invalid because of (1) as well. We are treating -fno-math-errno as applying to non-math functions and we don't have any -fno-errno or way of analyzing/annotating whether a program is interested in the state of errno (not only but mainly because identifying accesses to errno is non-trivial). Note this issue (invalid because of (1)) should probably be split out to a separate bug.
