https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
--- Comment #7 from bin cheng ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542038.html
It's a latent bug exposed by the mentioned alias analysis change, however:
unsigned char b, f;
short d[1][8][1], *g = &d[0][3][0];
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
Eric Gallager changed:
What|Removed |Added
Known to work||10.0
Known to fail|
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
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
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
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.
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: Su
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 e
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,
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 u
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
register
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
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
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.
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
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: Sa
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: Sa
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: Sa
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 ])
>
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?)
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
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.
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
ev
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!
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
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 regis
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;
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 t
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 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #36 from CVS Commits ---
PR c/93218 - Testing
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 functi
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.
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 requir
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
Andrzej Krzemienski changed:
What|Removed |Added
Version|6.1.0 |10.0
Keywords|
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/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
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:
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?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
Richard Henderson changed:
What|Removed |Added
Summary|__builtin_add_overflow vs |Missed ccmp optimizations
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
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
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: tar
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
> att
48 matches
Mail list logo
