[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Eric Gallager changed: What|Removed |Added Known to work||10.0 Known to fail||9.3.0 Target Milestone|9.4 |10.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #24 from Eric Gallager --- (In reply to Martin Sebor from comment #23) > I think that's a question for the release managers. I thought they like to > keep regressions open until all the affected branches have closed, but I > could be wrong. One way to find out is to close it and let them reopen it :) ok, I'll do that
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 84919, which changed state. Bug 84919 Summary: [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #33 from Rich Felker --- > An asm clobber just means "may be an output", and no operand will be assigned > a register mentioned in a clobber. There is no magic. This, plus the compiler cannot assume the value in any of the clobbered registers is preserved across the asm statement. > This is inlined just fine? It produces *wrong code* so it doesn't matter if it inlines fine. $10 is modified by the kernel in the event the syscall is restarted, so the wrong value will be loaded on restart.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #32 from Segher Boessenkool ---
===
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long f)
{
register long r4 __asm__("$4") = a;
register long r5 __asm__("$5") = b;
register long r6 __asm__("$6") = c;
register long r7 __asm__("$7") = d;
register long r8 __asm__("$8") = e;
register long r9 __asm__("$9") = f;
register long r10 __asm__("$10") = n;
register long r2 __asm__("$2");
__asm__ __volatile__ (
"subu $sp,$sp,32 ; sw $8,16($sp) ; sw $9,20($sp) ; "
"addu $2,$0,%4 ; syscall ;"
"addu $sp,$sp,32 # %0 %1 %2 %3 %4 %5 %6 %7"
: "="(r2), "+r"(r7), "+r"(r8), "+r"(r9)
: "ir"(r10), "r"(r4), "r"(r5), "r"(r6)
: SYSCALL_CLOBBERLIST);
return r7 && r2>0 ? -r2 : r2;
}
long syscall69(long a, long b, long c, long d, long e, long f) { return
syscall6(9, a, b, c, d, e, f); }
===
This is inlined just fine?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #31 from Segher Boessenkool --- An asm clobber just means "may be an output", and no operand will be assigned a register mentioned in a clobber. There is no magic.
[Bug middle-end/93566] [8/9/10 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9c3cdb43c2bdaf8a8d2e62db010b04f6086d76b7
commit r10-7179-g9c3cdb43c2bdaf8a8d2e62db010b04f6086d76b7
Author: Jakub Jelinek
Date: Sun Mar 15 01:27:40 2020 +0100
tree-nested: Fix handling of *reduction clauses with C array sections
[PR93566]
tree-nested.c didn't handle C array sections in {,task_,in_}reduction
clauses.
2020-03-14 Jakub Jelinek
PR middle-end/93566
* tree-nested.c (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Handle {,in_,task_}reduction clauses
with C/C++ array sections.
* testsuite/libgomp.c/pr93566.c: New test.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #30 from Rich Felker --- > You need to make $r10 not a clobber but an inout, of course. And not That's not a correct constraint, because it's clobbered by the kernel between the first syscall instruction's execution and the second execution of the addu instruction after the kernel returns to restart it. $10 absolutely needs to be a clobber because the kernel clobbers it. The asm block can't use any registers the kernel clobbers. > allowing the "i" just costs one more register move, not so bad imo. > So you do have a workaround now. Of course we should see if this can > actually be fixed instead ;-) I don't follow. As long as the "i" gets chosen, the asm inlines nicely. If not, it forces a gratuitous stack frame to spill a non-clobberlisted register to use as the input. The code has been working for the past 8 years with the "0"(r2) input constraint added, and would clearly be valid if r2 were pre-initialized with something.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #29 from Segher Boessenkool --- (In reply to Rich Felker from comment #27) > Also just realized: > > > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a > > reasonable > solution for you? > > It doesn't even work, because the syscall clobbers basically all > call-clobbered registers. Current kernels are preserving at least $25 (t9) > and $28 (gp) and the syscall argument registers, so $25 may be usable, but > it was deemed not clear in 2012. I'm looking back through musl git history, > and this is actually why the "i" alternative was wanted -- in basically all > uses, "i" is satisfiable, and avoids needing to setup a stack frame and > spill a call-saved register to the stack in order to use it to hold the > syscall number to reload on restart. You need to make $r10 not a clobber but an inout, of course. And not allowing the "i" just costs one more register move, not so bad imo. So you do have a workaround now. Of course we should see if this can actually be fixed instead ;-)
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #28 from Rich Felker --- And it looks like I actually hit this exact bug back in 2012 but misattributed it: https://git.musl-libc.org/cgit/musl/commit/?id=4221f154ff29ab0d6be1e7beaa5ea2d1731bc58e I assumed things went haywire from using two separate "r" constraints, rather than "r" and "0", to bind the same register, but it seems the real problem was that the "="(r2) was not binding at all, and the "0"(r2) served to fix that.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #27 from Rich Felker --- Also just realized: > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable solution for you? It doesn't even work, because the syscall clobbers basically all call-clobbered registers. Current kernels are preserving at least $25 (t9) and $28 (gp) and the syscall argument registers, so $25 may be usable, but it was deemed not clear in 2012. I'm looking back through musl git history, and this is actually why the "i" alternative was wanted -- in basically all uses, "i" is satisfiable, and avoids needing to setup a stack frame and spill a call-saved register to the stack in order to use it to hold the syscall number to reload on restart.
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #32 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:824722e45f80b22e2f035a61300f494b2a10d6f4 commit r10-7177-g824722e45f80b22e2f035a61300f494b2a10d6f4 Author: H.J. Lu Date: Sat Mar 14 16:06:55 2020 -0700 i386: Use ix86_output_ssemov for DImode TYPE_SSEMOV There is no need to set mode attribute to XImode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.md (*movdi_internal): Call ix86_output_ssemov for TYPE_SSEMOV. Remove ext_sse_reg_operand and TARGET_AVX512VL check. gcc/testsuite/ PR target/89229 * gcc.target/i386/pr89229-5a.c: New test. * gcc.target/i386/pr89229-5b.c: Likewise. * gcc.target/i386/pr89229-5c.c: Likewise.
[Bug target/94177] New: TLS global-dynamic model clobbers function parameter on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94177
Bug ID: 94177
Summary: TLS global-dynamic model clobbers function parameter
on AIX
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
In global-dynamic model, if a TLS variable first is referenced in the argument
list to a function call, GCC can load the parameters to the call before
invoking the function to legitimize the TLS variable, and the legitimize
function clobbers some of the same function argument registers.
extern int foo (char *, int *, int);
int main()
{
static __thread int result;
foo ("%p %u\n", , 169);
return 0;
}
$ gcc -fPIC -S bug_tls.c
li 5,169
lwz 10,LCM..1(2)
lwz 9,LC..1(2)
mr 3,10
mr 4,9
bla __tls_get_addr <*** clobbers r4, r5 already loaded with arguments
to foo
mr 9,3
mr 4,9
lwz 3,LC..2(2)
bl .foo
The pattern that generates __tls_get_addr shows that it clobbers r4 and r5
(define_insn "tls_get_addr_internal"
[(set (reg:P 3)
(unspec:P [(reg:P 3) (reg:P 4)] UNSPEC_TLSTLS))
(clobber (reg:P 0))
(clobber (reg:P 4))
(clobber (reg:P 5))
(clobber (reg:P 11))
(clobber (reg:CC CR0_REGNO))
(clobber (reg:P LR_REGNO))]
"TARGET_XCOFF && HAVE_AS_TLS"
"bla __tls_get_addr")
but GCC overwrites the parameters in calls.c during initial RTL generation.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #26 from Rich Felker --- Indeed, I just confirmed that binding the n input to a particular register prevents the "i" part of the "ir" alternative from working.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
--- Comment #2 from Cameron ---
(In reply to Jakub Jelinek from comment #1)
> It isn't clear to me what exactly disallows it, perhaps
> http://eel.is/c++draft/class.spaceship#2.2
> ?
> For auto return type
> http://eel.is/c++draft/class.spaceship#4
> defines what return type it should have.
> If the explicit return type isn't auto, but is one of the
> std::{strong,weak,partial}_ordering, we don't ICE and accept it, should we
> and what behavior should it have?
> #include
> struct S {
> float a;
> std::strong_ordering operator<=>(const S&) const = default;
> };
> bool b = S{} < S{};
> struct T {
> std::partial_ordering operator<=>(const T&) const = default;
> };
> bool c = T{} < T{};
> For S, the auto return type would be std::partial_ordering and in the
> generated body we just assume the floats will not be unordered.
> So, for bool, shall it be accepted and handled some way, or shall it be
> deleted, or result in immediate error (ill-formed)?
> What about even weirder types (say float or int * or some arbitrary class)?
As you point out, the standard isn't clear about what to do in the case where
the comparison function does not return 'auto' or any of the comparison type
forms.
Our compiler (MSVC) now opts to issue a diag at the point of definition when a
nonsense return type is specified. There is, unfortunately, room for
implementation divergence here.
Not ICEing--as we once did--is a good start though :).
[Bug c++/92068] [8/9/10 Regression] ICE on invalid in process_partial_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3a285529ee338ef2867ae7add26b6493f004bf0d commit r10-7176-g3a285529ee338ef2867ae7add26b6493f004bf0d Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix ICE-after-error on partial spec [92068] Here the template arguments for the partial specialization are valid arguments for the template, but not for a partial specialization, because 'd' can never be deduced to anything other than an empty pack. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92068 * pt.c (process_partial_specialization): Error rather than crash on extra pack expansion.
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c393c99d3dc8329dc1a36011e70faa9700185051 commit r10-7174-gc393c99d3dc8329dc1a36011e70faa9700185051 Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix CTAD with multiple-arg ctor template [93248]. When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a PARM_DECL that isn't already in local_specializations, we're in a decltype in a trailing return type or some such, and so we only want a substitution for a single PARM_DECL. In this case, we want the whole chain, so make sure cp_unevaluated_operand is cleared. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/93248 * pt.c (build_deduction_guide): Clear cp_unevaluated_operand for substituting DECL_ARGUMENTS.
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b3b0c671cc341fd04afc045a8d42d7a845d7f73c commit r10-7175-gb3b0c671cc341fd04afc045a8d42d7a845d7f73c Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Find parameter pack in typedef in lambda [92909]. find_parameter_packs_r doesn't look through typedefs, which is normally correct, but that means we need to handle their declarations specially. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92909 * pt.c (find_parameter_packs_r): [DECL_EXPR]: Walk DECL_ORIGINAL_TYPE of a typedef.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #25 from Peter Bergner --- (In reply to Segher Boessenkool from comment #23) > Before RA we have asm inputs > [ > (reg/v:SI 196 [ n ]) > (reg/v:SI 4 $4 [ r4 ]) > (reg/v:SI 5 $5 [ r5 ]) > (reg/v:SI 6 $6 [ r6 ]) > (reg/v:SI 7 $7 [ r7 ]) > (reg/v:SI 8 $8 [ r8 ]) > (reg/v:SI 9 $9 [ r9 ]) > ] > (and $2 an earlyclobber). But then IRA decides > > Disposition: > 0:r195 l0 21:r196 l0 2 Vlad can verify, but I don't think IRA takes early clobber constraints into consideration when computing conflicts, so I'm not surprised pseudo 196 (ie, n) is assigned hard register $2. In that case, LRA will notice the illegal constraint usage and will insert reloads. > Peter, do you know which patch fixed this (is that the one you quoted > above?), > and if it could feasibly be backported separately? Yes, I think the patch I mentioned above should stop LRA from spilling the hard register assigned by the user in %0 and should instead spill pseudo 196 by reassigning it to another hard register. Whether it's feasible to backport, maybe? :-) The lra-constraints.c hunk applies to gcc-8 (with fuzz), so maybe that's enough to fix this? Can someone try applying that hunk and does it fix this?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #24 from Rich Felker --- The reasons I was hesitant to force n to a particular register through an extra register __asm__ temp var was that I was unsure how it would interact with the "i" constraint (maybe prevent it from being used?) and that this is code that needs to be inlined all over the place, and adding more specific-register constraints usually hurts register allocation in all functions where it's used. If the "0"(r2) input constraint seems unsafe to rely on with r2 being uninitialized (is this a real concern I should have?) just writing 0 or n to r2 before the asm would only waste one instruction and shouldn't really hurt.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #23 from Segher Boessenkool --- It is harder for us to track it in an older bug with many older patches for it, including stuff that needed fixups later. And, the "correct" older bug for it would not be this one, anyway! Before RA we have asm inputs [ (reg/v:SI 196 [ n ]) (reg/v:SI 4 $4 [ r4 ]) (reg/v:SI 5 $5 [ r5 ]) (reg/v:SI 6 $6 [ r6 ]) (reg/v:SI 7 $7 [ r7 ]) (reg/v:SI 8 $8 [ r8 ]) (reg/v:SI 9 $9 [ r9 ]) ] (and $2 an earlyclobber). But then IRA decides Disposition: 0:r195 l0 21:r196 l0 2 Peter, do you know which patch fixed this (is that the one you quoted above?), and if it could feasibly be backported separately? Only GCC 8 and later branches are still open, fwiw (but some distros still have older maintained versions). Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable solution for you?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #22 from Rich Felker --- What should I call the new bug? The description sounds the same as this one, and it's fixed in gcc 9.x, just not earlier versions, so it seems to be the same bug.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #21 from Alexander Monakov --- > I could guess the compiler might ignore your inputs/outputs that you specify > if you don't have any % usages for them. Are you seriously suggesting that examples in the GCC manual are invalid and every such usage out there should go and add mentions of referenced registers in the comment in the inline asm template? https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #20 from Segher Boessenkool --- Confirmed with various 7 and 8 (I don't have a mips 6 around). Don't reopen this bug, it is not necessarily related. Instead, please open a new PR. Thanks!
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #19 from Rich Felker --- > This looks like bad inline asm. You seem to be using $2, $8, $9 and $sp > explicitly and not letting the compiler know you are using them. $2, $8, and $9 are all explicitly outputs. All changes to $sp are reversed before the asm ends and there are no memory operands which could be sp-based and thereby invalidated by temp changes to it. > I think you want to change those to %0, %2 and %3 and adding one for $sp? All that does it make the code harder to read and more fragile against changes to the order the constraints are written in. > ...and "n" is an argument register, so why use "ir" for n's constraint? > Shouldn't that just be "r"? Maybe that is confusing IRA/LRA/reload? The code has been reduced as a standalone example that still reproduced the bug, from a static inline function that was inlined into a function with exactly the same signature. The static inline has a constant n after constant propagation for almost all places it gets inlined, so it "ir" constraint makes sense there. However, removing the "i" does not make the problem go away anyway.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #18 from Peter Bergner --- (In reply to Rich Felker from comment #16) > long syscall6(long n, long a, long b, long c, long d, long e, long f) [snip] > : "ir"(n), "r"(r4), "r"(r5), "r"(r6) ...and "n" is an argument register, so why use "ir" for n's constraint? Shouldn't that just be "r"? Maybe that is confusing IRA/LRA/reload?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #17 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
> {
> register long r4 __asm__("$4") = a;
> register long r5 __asm__("$5") = b;
> register long r6 __asm__("$6") = c;
> register long r7 __asm__("$7") = d;
> register long r8 __asm__("$8") = e;
> register long r9 __asm__("$9") = f;
> register long r2 __asm__("$2");
> __asm__ __volatile__ (
> "subu $sp,$sp,32 ; sw $8,16($sp) ; sw $9,20($sp) ; "
> "addu $2,$0,%4 ; syscall ;"
> "addu $sp,$sp,32"
> : "="(r2), "+r"(r7), "+r"(r8), "+r"(r9)
> : "ir"(n), "r"(r4), "r"(r5), "r"(r6)
> : SYSCALL_CLOBBERLIST, "$10");
> return r7 && r2>0 ? -r2 : r2;
> }
This looks like bad inline asm. You seem to be using $2, $8, $9 and $sp
explicitly and not letting the compiler know you are using them. I think you
want to change those to %0, %2 and %3 and adding one for $sp? I could guess
the compiler might ignore your inputs/outputs that you specify if you don't
have any % usages for them.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #16 from Rich Felker ---
> I didn't say this very well... The only issue is using the same hard
> register for two different operands. You don't need to do this for
> syscalls (and you do not *need* that *ever*, of course).
I hit the bug without using the same hard register for two operands. At least
I'm pretty sure it's the same bug because the behavior matches and it's present
in 6.3.0 but not 9.2.0.
> Can you post some code that fails? If you think this is a GCC bug (in
> some older branch?) that we should fix, please open a new PR for it.
Here's the relevant code extracted out of musl:
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long f)
{
register long r4 __asm__("$4") = a;
register long r5 __asm__("$5") = b;
register long r6 __asm__("$6") = c;
register long r7 __asm__("$7") = d;
register long r8 __asm__("$8") = e;
register long r9 __asm__("$9") = f;
register long r2 __asm__("$2");
__asm__ __volatile__ (
"subu $sp,$sp,32 ; sw $8,16($sp) ; sw $9,20($sp) ; "
"addu $2,$0,%4 ; syscall ;"
"addu $sp,$sp,32"
: "="(r2), "+r"(r7), "+r"(r8), "+r"(r9)
: "ir"(n), "r"(r4), "r"(r5), "r"(r6)
: SYSCALL_CLOBBERLIST, "$10");
return r7 && r2>0 ? -r2 : r2;
}
Built with gcc 6.3.0, %4 ends up expanding to $2, violating the earlyclobber,
and %0 gets bound to $16 rather than $2 (which is why the violation is allowed,
it seems).
With "0"(r2) added to input constraints, the bug goes away.
I don't particularly think this bug is something that needs to be fixed in
older branches, especially if doing so is hard, but I do think it's something
we need a solid reliable workaround for.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #15 from Segher Boessenkool --- (In reply to Rich Felker from comment #12) > > You can work around it on older GCC by simply not using a register var > > for more than one asm operand, I think? > > Nope. Making a syscall inherently requires binding specific registers for > all of the inputs/outputs, unless you want to spill everything to an > explicit structure in memory and load them all explicitly in the asm block. > So it really is a big deal. I didn't say this very well... The only issue is using the same hard register for two different operands. You don't need to do this for syscalls (and you do not *need* that *ever*, of course). Can you post some code that fails? If you think this is a GCC bug (in some older branch?) that we should fix, please open a new PR for it.
[Bug target/94176] rs6000/test: Fix selector in fold-vec-mule-misc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- Fixed (and the integration looks to be fixed too, woohoo).
[Bug target/94176] rs6000/test: Fix selector in fold-vec-mule-misc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176 --- Comment #1 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:9a6408bd18fe893a59297d80010fbd3660300347 commit r10-7172-g9a6408bd18fe893a59297d80010fbd3660300347 Author: Segher Boessenkool Date: Mon Feb 17 12:13:21 2020 + rs6000/test: Fix selector in fold-vec-mule-misc.c Run tests should use vmx_hw, not just powerpc_altivec_ok. gcc/testsuite/ PR target/94176 * gcc.target/powerpc/fold-vec-mule-misc.c: Use vmx_hw selector.
[Bug target/94176] New: rs6000/test: Fix selector in fold-vec-mule-misc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176 Bug ID: 94176 Summary: rs6000/test: Fix selector in fold-vec-mule-misc.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- (This PR is just to test BZ commit integration).
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #36 from CVS Commits --- PR c/93218 - Testing
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
--- Comment #9 from Jim Wilson ---
(In reply to Jakub Jelinek from comment #8)
> So perhaps to ease reproduction, tweak the hash function in this case to
> always return 0?
Yes, that works. I just didn't have a chance to look at the hash function last
night. With the hash function hacked I can reproduce for any target and any
-std=c++X value.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 789ccdb..4337928 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1733,7 +1733,8 @@ hash_tmpl_and_args (tree tmpl, tree args)
hashval_t
spec_hasher::hash (spec_entry *e)
{
- return hash_tmpl_and_args (e->tmpl, e->args);
+ return 0;
+ // return hash_tmpl_and_args (e->tmpl, e->args);
}
/* Recursively calculate a hash value for a template argument ARG, for use
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #14 from Alexander Monakov --- Just to clarify, the two testcases added in the quoted commit don't try to catch the issue discussed here: that the operand is passed in a wrong register.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #13 from Peter Bergner --- (In reply to Rich Felker from comment #12) > > You can work around it on older GCC by simply not using a register var > > for more than one asm operand, I think? > > Nope. Making a syscall inherently requires binding specific registers for > all of the inputs/outputs, unless you want to spill everything to an > explicit structure in memory and load them all explicitly in the asm block. > So it really is a big deal. As Segher said, there were a lot of dependent patches that fixed latent bugs that the previous patches had exposed. My best guess of the patch that fixed this specific problem (ie, LRA breaking the contract of using the user defined/assigned register in inline asm) would be: commit 2f0b80c7a4ab4254f57ba63de26ebb7896e3742d Author: Peter Bergner AuthorDate: Thu Nov 8 22:39:45 2018 + Commit: Peter Bergner CommitDate: Thu Nov 8 16:39:45 2018 -0600 re PR rtl-optimization/87600 (Fix for PRs 86939 and 87479 causes build issues for several targets) gcc/ PR rtl-optimization/87600 * cfgexpand.c (expand_asm_stmt): Catch illegal asm constraint usage. * lra-constraints.c (process_alt_operands): Skip illegal hard register usage. Prefer reloading non hard register operands. gcc/testsuite/ PR rtl-optimization/87600 * gcc.dg/pr87600.h: New file. * gcc.dg/pr87600-1.c: New test. * gcc.dg/pr87600-2.c: Likewise. From-SVN: r265942 Specifically, the "Prefer reloading non hard register operands." part of the patch. Previous versions of GCC would sometimes silently spill user defined/assigned hard registers used in inline asm, which is a no-no.
[Bug c++/77595] concepts: constrained member functions illegally instantiated during explicit class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595 --- Comment #3 from Andrzej Krzemienski --- The part of the Standard that requires this: http://eel.is/c++draft/temp.explicit#11
[Bug c++/77595] concepts: constrained member functions illegally instantiated during explicit class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595 Andrzej Krzemienski changed: What|Removed |Added Version|6.1.0 |10.0 Keywords||rejects-valid --- Comment #2 from Andrzej Krzemienski --- This bug is still present in GCC 10. It is present also in the clang trunk. But works fine in the previous experimental implementation of concepts in clang: https://godbolt.org/z/K4SaCm
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #12 from Rich Felker --- > You can work around it on older GCC by simply not using a register var > for more than one asm operand, I think? Nope. Making a syscall inherently requires binding specific registers for all of the inputs/outputs, unless you want to spill everything to an explicit structure in memory and load them all explicitly in the asm block. So it really is a big deal. In particular, all mips variants need an earlyclobber constraint for the output register $2 because the old Linux kernel syscall contract was that, when restartable syscalls were interrupted, the syscall number passed in through $2 was lost, and the kernel returned to $pc-8 and expected a userspace instruction to reload $2 with the syscall number from an immediate or another register. If the input to load into $2 were itself passed in $2 (possible without earlyclobber), the reloading would be ineffective and restarting syscalls would execute the wrong syscall. The original mips port of musl had undocumented and seemingly useless "0"(r2) input constraints that were suppressing this bug, using the input to bind the register where the earlyclobber output failed to do so. After some recent changes broke compatibility with older kernels requiring the above contract, I manually reverted them (due to intervening conflicting diffs) and omitted the seemingly useless constraint, and it broke horribly. Eventually I found this bug searching the tracker. My plan for now is just to add back the "0"(r2) constraint, but since r2 is uninitialized, it's not clear that having it as an input constraint is even well-defined. Is this the best thing to do?
[Bug c++/94175] [10 Regression] Passing constexpr empty class variable to function since r10-599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |10.0 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org Last reconfirmed||2020-03-14
[Bug c++/94175] New: [10 Regression] Passing constexpr empty class variable to function since r10-599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Bug ID: 94175
Summary: [10 Regression] Passing constexpr empty class variable
to function since r10-599
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-599-gc652ff83124334837dc16626f9e1040e4fe41fc9 following testcase with
-O2 -m32 (or -O0 -m32 or any arch other than x86_64 64-bit):
struct Foo
{
struct NoStartBar {};
static constexpr NoStartBar noStartBar = NoStartBar();
[[gnu::noinline, gnu::noclone]] Foo(int x, NoStartBar) : f (x) { f++; }
Foo(double x) : Foo(0, noStartBar) {}
int f;
};
Foo a = 6.0;
needs the Foo::noStartBar definition, while before it didn't and just passed
NoStartBar {}.
Is passing the static data member an ODR use of it or not?
In any case, looks like a missed optimization, there shouldn't be reason to
copy the empty class from a variable rather than just passing uninitialized
bytes.
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #8 from Jakub Jelinek --- So perhaps to ease reproduction, tweak the hash function in this case to always return 0?
[Bug target/94174] Missed ccmp optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
--- Comment #2 from Richard Henderson ---
Case 3:
void test3(__int128 a, unsigned long l)
{
if ((__int128_t)a - l <= 1)
doit();
}
currently generates as
subsx0, x0, x2
sbc x1, x1, xzr
cmp x1, 0
ble .L11
.L7:
ret
.L11:
bne .L10
cmp x0, 1
bhi .L7
.L10:
b doit
but at least the bne + cmp can be
ccmp x0, 1, #2, eq
Note that clang attempts a branchless double-word comparison
subsx8, x0, x2
sbcsx9, x1, xzr
cmp x8, #1
csetw8, hi
cmp x9, #0
csetw9, gt
cselw8, w8, w9, eq
tbnzw8, #0, .LBB0_2
we can do better than that:
subsx8, x0, x2
sbcsx9, x1, xzr
// x9 < 0 || (x9 == 0 && x8 <= 1)
csetx10, lt
ccmpx8, #1, #2, ne(nzCv: eq -> hi)
ccmpx10, #0, #4, hi (nZcv: ls -> eq)
b.eq.L10
It's not 100% clear this is better than the 2 branch
version (with the ccmp), but at least it's no larger.
[Bug target/94174] Missed ccmp optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
Richard Henderson changed:
What|Removed |Added
Summary|__builtin_add_overflow vs |Missed ccmp optimizations
|ccmp|
Target||aarch64-*
--- Comment #1 from Richard Henderson ---
Case 2:
void test2(unsigned long a, unsigned long l)
{
if (l + 1 == 0 || a <= l + 1)
doit();
}
currently generates as
cmn x1, #1
beq .L13
add x1, x1, 1
cmp x1, x0
bcc .L12
but could be
addsx2, x1, #1
ccmpx0, x2, #0, ne
b.hi.L12
[Bug target/94174] New: __builtin_add_overflow vs ccmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
Bug ID: 94174
Summary: __builtin_add_overflow vs ccmp
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
(1) Case 1:
void doit(void);
void test(unsigned long a, unsigned long l)
{
if (!__builtin_add_overflow(a, 8 - 1, ) && a <= l)
doit();
}
currently generates as
addsx0, x0, #7
csetx2, cs
cmp x0, x1
eor w2, w2, 1
csetw0, ls
tst w0, w2
bne .L22
but could be
addsx2, x0, #7
ccmpx2, x1, #0, cc
b.ls.L22
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #7 from CVS Commits --- https://gcc.gnu.org/g:50c96067c8ed60f4b3fcbee89fe31c905241b356commit r10-7169-g50c96067c8ed60f4b3fcbee89fe31c905241b356Author: Aaron Sawdey Date: Fri Mar 13 18:14:22 2020 -0500Fix UBSAN error, shifting 64 bit value by 64.2020-03-13 Aaron Sawdey PR target/92379* config/rs6000/rs6000.c (num_insns_constant_multi) Don't shift a 64-bit value by 64 bits (UB).
[Bug target/94173] New: [RISCV] Superfluous stackpointer manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173
Bug ID: 94173
Summary: [RISCV] Superfluous stackpointer manipulation
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at gms dot tf
Target Milestone: ---
Created attachment 48033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48033=edit
demonstrate how bar function yields superfluous stackpointer instructions
GCC emits stackpointer decrement/increment instructions in some functions where
they are superfluous.
Example:
struct Pair {
char *s;
char *t;
};
typedef struct Pair Pair;
Pair bar(char *s, char *t)
{
return (Pair){s, t};
}
Expected assembly:
0002 :
2: 8082ret
Actual assembly:
0002 :
2: 1141addisp,sp,-16
4: 0141addisp,sp,16
6: 8082ret
Notes:
In an example where the function just returns one value the assembly code
actually just contain the expected assenbly code:
char *foo(char *s, char *t)
{
return s;
}
Note that per the RISC-V calling-conventions up to 2 integer like values are
returned via the a0/a1 registers, i.e. the same registers where also the first
2 function arguments are placed.
FWIW, Clang 9.0.1 generates for both examples the expected code without
superfluous stackpointer adjustments.
Example code is attched.
I tested with:
riscv64-linux-gnu-gcc -O3 -c -o pair.o pair.c
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #11 from Segher Boessenkool --- (In reply to Rich Felker from comment #10) > This is a rather huge bug to have been fixed silently. Could someone who > knows the commit that fixed it and information on what versions are affected > attach the info to the tracker here? And ideally some information on working > around it for older GCCs? > > From what I can tell experimenting so far, adding a dummy "0"(r0) > constraint, or using + instead of =, makes the problem go away, but > potentially has other ill effects from use of an uninitialized object..? This wasn't silent. There was a whole bunch of commits, all before this PR was filed. You can start looking at PR87600 maybe, and from there follow the trails. AFAIR all older versions (well, of this decade, anyway) have these problems, but the patches are much to involved to backport. You can work around it on older GCC by simply not using a register var for more than one asm operand, I think?
