https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114514 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Last reconfirmed| |2024-03-28 CC| |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Confirmed. Note non sign bit can be improved too: ``` #define vector __attribute__((vector_size(16))) typedef vector signed char v16qi; typedef vector unsigned char v16uqi; v16qi foo2 (v16qi a, v16qi b) { return a >> 6; } v16uqi foo1 (v16uqi a, v16uqi b) { return a >> 6; } ``` clang produces: ``` _Z4foo2Dv16_aS_: psrlw $6, %xmm0 pand .LCPI0_0(%rip), %xmm0 #{3,3,3,...} movdqa .LCPI0_1(%rip), %xmm1 #{2,2,2,...} pxor %xmm1, %xmm0 psubb %xmm1, %xmm0 retq _Z4foo1Dv16_hS_: psrlw $6, %xmm0 pand .LCPI1_0(%rip), %xmm0 #{3,3,3,...} retq ```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518 --- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> --- It fails with -m32 only for me?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 Kaz Kylheku <kkylheku at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkylheku at gmail dot com --- Comment #22 from Kaz Kylheku <kkylheku at gmail dot com> --- (In reply to Pavel M from comment #21) > FYI: Rationale for C, Revision 5.10, April-2003: > > Even with an explicit cast, it is invalid to convert a function pointer to an object pointer or a pointer to void, or vice versa. That means nothing; it's not even part of the standard document. In the document itself, there are texts which are part of it, yet not "normative", such as examples and footnotes. The standard itself mentions the conversion as a common extension (not in a normative way though, but at least in the document!) Now the absence of a documented extension, it certainly isn't correct; it's undefined behavior. But it's not incorrect in a way that requires a diagnostic (when the required cast is present). The only diagnostic ever required when a pointer conversion is requested is when the conversion isn't one of the ones allowed implicitly, and a correct cast is missing. The "absence of a documented extension" is irrelevant in the context of GCC, which has the extension. That extension is at the cornerstone of the tech stacks built on GCC, and required by POSIX. It is not useful for the -pedantic option to pretend that GCC is some other compiler which doesn't have any of its conforming extensions. Diagnostics like that could be useful to someone, but deserve their own category, like -Wutmost-portability or something. Someone who just wants the ISO-C-required situations diagnosed shouldn't have to have these other diagnostics foisted on them. You can always pick and choose diagnostics individually, but the categories are useful, which is why they are there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[11/12/13/14 Regression] |[11/12/13 Regression] |std::tuple<A&&> cannot be |std::tuple<A&&> cannot be |constructed from A&&, if A |constructed from A&&, if A |not defined (only forward |not defined (only forward |declared) |declared) --- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> --- Fixed on trunk now, thanks, Jason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 --- Comment #3 from Kaz Kylheku <kkylheku at gmail dot com> --- (In reply to Andrew Pinski from comment #2) > Actually it is a required diagnostic. See PR 11234 for explanation on how. > This was changed a little over 20 years ago explictly to reject this because > it is invalid C. > > *** This bug has been marked as a duplicate of bug 11234 *** This bug report is more than about the specific warning about conversion of function and object pointers. It's about all/any options that don't belong in -pedantic; and about false sentences in diagnostics and documentation. Now, a conversion between a function and object pointer requires no diagnostic if the required cast is present. Either way, it is undefined behavior. I'm referencing the N3220 draft. The 6.3 Conversions sections lists, in 6.3.2.3 Pointers, various possible conversions among pointers. Conversions between pointers to object types and to function types are not mentioned. It has always been like that going back to ISO C 90 and ANSI C. As an extension, not only is it not forbidden, but it is listed in an Appendix as a common extension. In the N3220 draft we have: J.5.8 Function pointer casts A pointer to an object or to void may be cast to a pointer to a function, allowing data to be invoked as a function (6.5.5). A diagnostic is required if a pointer to function is converted to an object pointer, without a cast. 6.5.5 Cast Operators Constraints ... Conversions that involve pointers, other than where permitted by the constraints of 6.5.17.2, shall be specified by means of an explicit cast. If a cast is present, the constraint is satisfied; the conversion is no longer implicit but explicit. No other constraints apply to the conversion. In fact no other requirements at all, since it is not defined. GCC provides the common extension described in J.5.8. It is conforming; nothing needs to be diagnosed about a program which uses it. It, and other extensions, must not be called "forbidden".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11234 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkylheku at gmail dot com --- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> --- *** Bug 114526 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Actually it is a required diagnostic. See PR 11234 for explanation on how. This was changed a little over 20 years ago explictly to reject this because it is invalid C. *** This bug has been marked as a duplicate of bug 11234 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- https://gcc.gnu.org/legacy-ml/gcc-patches/2004-01/msg00599.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114513 --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Looks like r9-332-g43d0a8ee88460a added the ? there and caused the regression I do think it should be ^ since the reload (spill) case should use w while normally it try both, w and r. But I could be wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829 --- Comment #9 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> --- Hello Vladimir, Sorry for the delay in getting back to this. (In reply to GCC Commits from comment #8) > The master branch has been updated by Vladimir Makarov > <vmakarov@gcc.gnu.org>: > > https://gcc.gnu.org/g:9c91f8a88b2db50c8faf70786d3cef27b39ac9fc > > commit r14-9557-g9c91f8a88b2db50c8faf70786d3cef27b39ac9fc > Author: Vladimir N. Makarov <vmakarov@redhat.com> > Date: Tue Mar 19 16:57:11 2024 -0400 > > [PR99829][LRA]: Fixing LRA ICE on arm I can confirm that the commit fixes this bug. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 Bug ID: 114526 Summary: ISO C does not prohibit extensions: fix misconception. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kkylheku at gmail dot com Target Milestone: --- There seems to be a historic misconception in the development of GCC that the C standard prohibits extensions. The -Wpedantic/-pedantic options are unfortunately organized around this false idea. Firstly, for a bit of background, in the GNU Coding Standards document we have this: > But we do not follow either of these specifications rigidly, > and there are specific points on which we decided not to > follow them, so as to make the GNU system better for users. > > For instance, Standard C says that nearly all extensions to C > are prohibited. How silly! GCC implements many extensions, > some of which were later adopted as part of the standard. > If you want these constructs to give an error message as > “required” by the standard, you must specify ‘--pedantic’, > which was implemented only so that we can say “GCC is a 100% > implementation of the standard”, not because there is any > reason to actually use it. [https://www.gnu.org/prep/standards/standards.html] I suspect this might have been written, at some point, by someone actually working on the design of GCC. Or at least believing the GCC documentation. The GCC man page contains text which propagates the same falsehood, claiming that the -Wpedantic/-pedantic options "[i]ssue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++." The same text appears in the main documentation. This is false; there are no forbidden extensions. There are conforming extensions and nonconforming extensions. Nonconforming extensions are those that require a diagnostic if interpreted as ISO C, due to using new syntax or anything else diagnosable. Probably, -pedantic mode should only stick to emitting required diagnostics. For instance if program uses a nonconforming extension then -pedantic should cause that to be diagnosed (while continuing to accept the GNU extension, if it's just a warning). The following diagnostics have a wording which perpetrates the falsehood that extensions are forbidden: > warning: ISO C forbids conversion of function pointer to object pointer type [-Wpedantic] > warning: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] ISO C forbids no not such thing, and requires no diagnostic. It is a conforming extension in GCC, allowed by the standard, and even required by POSIX (so that the result of dlsym can be usefully converted to a function pointer). Diagnostics which warn about conforming extensions (and reject programs when warnings are treated as errors) arguably have no place in -pedantic mode. (They can stand on their own, or be put into some other special category.) The incorrect claims in the documentation should be removed, and pedantic mode's focus should be diagnosing situations where ISO C requires a diagnostic but GCC doesn't emit one by default. Wording in diagnostics which claims that ISO C forbids something should likewise be revised; people read these statements and take them to be true!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114513 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Known to work| |8.5.0 Status|UNCONFIRMED |NEW Known to fail| |9.3.0 Target Milestone|--- |11.5 Ever confirmed|0 |1 Summary|[aarch64] floating-point |[11/12/13/14 Regression] |registers are used when |[aarch64] floating-point |GPRs are preferred |registers are used when | |GPRs are preferred Last reconfirmed| |2024-03-28 --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- So we have: ``` ;; Equal width integer to fp conversion. (define_insn "<optab><fcvt_target><GPF:mode>2" [(set (match_operand:GPF 0 "register_operand") (FLOATUORS:GPF (match_operand:<FCVT_TARGET> 1 "register_operand")))] "TARGET_FLOAT" {@ [ cons: =0 , 1 ; attrs: type , arch ] [ w , w ; neon_int_to_fp_<Vetype> , simd ] <su_optab>cvtf\t%<GPF:s>0, %<s>1 [ w , ?r ; f_cvti2f , fp ] <su_optab>cvtf\t%<GPF:s>0, %<w1>1 } ) ``` Notice the ? in there for r. Reading https://gcc.gnu.org/onlinedocs/gccint/Multi-Alternative.html maybe this should be ^ instead of ?. ^ is new as of GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519 Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2024-03-28 Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> --- The library doesn't require it, and can cope with -fno-char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 --- Comment #13 from Jose E. Marchesi <jemarch at gcc dot gnu.org> --- Thanks. The new title is way better. And thank you for the further analysis and the reproducer that also makes clang to generate the no-verifiable code! I wonder, is the issue also there when -mno-alu32 is used? In that case the generated code doesn't involve "subregs" (or 32-bit operations in assembly-like syntax): .file "foo.c" .text .align 3 .global foo .type foo, @function foo: call bar lddw %r1,baz mov %r0,%r0 and %r0,0xffffffff ldxw %r2,[%r1+0] add %r0,-1 neg %r2 xor %r0,%r2 rsh %r0,63 exit .size foo, .-foo .global baz .type baz, @object .lcomm baz,4,4 .ident "GCC: (GNU) 14.0.1 20240226 (experimental)" Cuper, is the verifier able to track proper values through the xor in this case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unknown |14.0 --- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Let me correct the title since phiopt has nothing to do with the issue at hand. It is the subreg with bitwise and that confuses the verifier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #19 from Michael Meissner <meissner at gcc dot gnu.org> --- When I wrote the VSX support many years ago, I intended that -mvsx enable all of ISA 2.06, which includes ISA 2.05, etc. My intentions were there 2 options for power7, one is the base ISA 2.07 support for everything except the VSX registers (i.e. -mpopcntd), and the other enables the floating point support. The reason is the kernel needs to be built without floating point support. If you say -mvsx, it should include the standard power7 integer instructions (-mpopcntd), power6 server instructions (i.e. -mhard-dfp, -mcmpb, -mrecip, -mpowerpc-gfxopt, and -mpowerpc-gpopt), etc. VSX support assumes it can use lfiwax and lfiwzx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #44 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > Thank you, Dmitry, but that particular solution may not be possible for me. > When I try compiling with -mstackrealign -mpreferred-stack-boundary=5 > -mincoming-stack-boundary=5 instead of forcing unaligned moves I get > "cc1.exe: error: '-mpreferred-stack-boundary=5' is not between 3 and 4". Is > that this bug in a different form, something that should be filed > separately, or known and intended behavior? No, it's the same issue: 32-byte stack alignment is not supported with SEH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114525 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Known to fail| |4.4.7 Target Milestone|--- |11.5 Summary|Incorrect code generated |[11/12/13/14 Regression] |when setting a value |Incorrect code generated |through a pointer-to-member |when setting a value |on a ternary returning an |through a pointer-to-member |object reference |on a ternary returning an | |object reference Known to work| |4.1.2 --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- It actually worked in GCC 4.1.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114525 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed| |2024-03-28 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Confirmed. (void) (*((int *) &(cond ? *get ((struct Foo &) &v) : *get ((struct Foo &) &v)) + (sizetype) 0) = 2) >>>>>; Notice the * there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114525 Bug ID: 114525 Summary: Incorrect code generated when setting a value through a pointer-to-member on a ternary returning an object reference Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dragonroot at gmail dot com Target Milestone: --- The following program incorrectly outputs 1 on every GCC I've tried (via godbolt.org), while every clang version there correctly outputs 2. ============== #include <stdio.h> struct Foo { int x; }; Foo & get( Foo & v ) { return v; } int main() { Foo v; v.x = 1; bool cond = true; ( cond ? get( v ) : get( v ) ).*( &Foo::x ) = 2; // Should output 2, but outputs 1 printf( "%d\n", v.x ); } ==============
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 --- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> --- The bpf verifier is just plain broken when it comes to subreg usage. So after every 32bit usage you need to output a zero extend. To fix that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 --- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> --- The only way to fix this is to add extra zero extends all the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Bug 114431 depends on bug 114523, which changed state. Bug 114523 Summary: bpf: ssa-phiopt optimization generates unverifiable code. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |NEW Resolution|INVALID |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 Jose E. Marchesi <jemarch at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|RESOLVED |NEW Resolution|INVALID |--- CC| |jemarch at gcc dot gnu.org Last reconfirmed| |2024-03-28 --- Comment #9 from Jose E. Marchesi <jemarch at gcc dot gnu.org> --- Please do not close this bug. We are well aware this is a limitation in the kernel verifier, but we need to keep track of this. In general, like in this case, many of the problems related to unverifiable generated code can be reduced to "this is a kernel verifier bug, make it smarter", but that doesn't mean we can't put workarounds in the back-end so we can actually compile actually-existing BPF programs (such as that systemd utility) in actually-existing current kernels. That includes disabling certain optimizations. I don't like it any more than you do, trust me on that. Note that the development of the BPF backends, in both clang and GCC, are by necessity very much in lock-step with the kernel BPF support. So this is not something we will forget to "undo" as soon as the verifier can handle these instructions. Very likely we will be doing the kernel patch as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289 --- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by John David Anglin <danglin@gcc.gnu.org>: https://gcc.gnu.org/g:86b0b1bec6790f84b7a56fcef2a0a6c8cd91ffef commit r14-9714-g86b0b1bec6790f84b7a56fcef2a0a6c8cd91ffef Author: John David Anglin <danglin@gcc.gnu.org> Date: Thu Mar 28 18:32:12 2024 +0000 Fix failure of c-c++-common/analyzer/stdarg-pr111289-int.c on hpux 2024-03-28 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: PR analyzer/111289 * c-c++-common/analyzer/stdarg-pr111289-int.c: Don't include <limits.h>.