https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Andrew Pinski changed:
What|Removed |Added
Keywords||build, wrong-code
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #3 from Andrew Pinski ---
One question I have is which stage fails? Is it stage 2 or stage 3? Because
if it is stage 3, then stage 2 is miscompiled which is causing a different
miscompile in stage 3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> One question I have is which stage fails? Is it stage 2 or stage 3?
> Because if it is stage 3, then stage 2 is miscompiled which is causing a
> different misco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #22 from Andrew Pinski ---
(In reply to Richard Biener from comment #20)
> where SLP vectorization is confused about (char) _19 vs. BIT_FIELD_REF
> but also wouldn't handle BIT_FIELD_REFs. It neither vectorizes the
> store to a store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94055
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94053
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054
--- Comment #1 from Andrew Pinski ---
You need to use the operand modifier P here:
__asm__ __volatile__ (
"vld1.f32 {d0,d1}, [%[src]]! \n\t"
"vtbl.8 d2, {d0,d1}, %P[t0] \n\t"
"vtbl.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054
--- Comment #2 from Andrew Pinski ---
related to PR PR 84343.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37188
Andrew Pinski changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052
Andrew Pinski changed:
What|Removed |Added
Blocks||89967
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052
Andrew Pinski changed:
What|Removed |Added
Blocks||89057
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Andrew Pinski changed:
What|Removed |Added
Depends on||89057
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052
--- Comment #4 from Andrew Pinski ---
(In reply to Tamar Christina from comment #1)
> I don't believe this ever worked.. At least testing 8,9 and 10 all ICE. So I
> didn't put a regression label on it. (and couldn't figure out the format for
> kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79755
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking
--- Comment #11 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #16 from Andrew Pinski ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
This should just change the costs of the register usage. Which means it might
be a latent bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
Andrew Pinski changed:
What|Removed |Added
Keywords||build, wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94064
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #20 from Andrew Pinski ---
The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
being copied into r8 and then copied back into r3 (return value), but not r0 is
used and that r0 is used for mtlr (moving back the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #24 from Andrew Pinski ---
(In reply to Martin Liška from comment #23)
> (In reply to Andrew Pinski from comment #20)
> > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> > being copied into r8 and then co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Severity|nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94075
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #35 from Andrew Pinski ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I
Mean the false ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
--- Comment #3 from Andrew Pinski ---
(In reply to vfdff from comment #2)
> thanks very much, you are right.
The same problem is here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> >The bug is *not* present on on Fedora:31 where the compiler reports:
>
> I doubt it is version based but rather based on what the CPU you are running
> on.
I M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #1 from Andrew Pinski ---
>The bug is *not* present on on Fedora:31 where the compiler reports:
I doubt it is version based but rather based on what the CPU you are running
on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #3 from Andrew Pinski ---
https://software.intel.com/sites/default/files/managed/98/4a/DRNG_Software_Implementation_Guide_2.1.pdf
5.3.1 Retry Recommendations
...
If only one thread is calling RDSEED infrequently, it is very unlikely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94089
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #1 from Andrew Pinski ---
>For coremark, this is not only harmful to performance, but also code size.
Bad, very bad benchmark
SPEC CPU is closer to real code but still bad benchmarks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> >For coremark, this is not only harmful to performance, but also code size.
>
>
> Bad, very bad benchmark
Coremark only handles very very small data sets b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-03-09
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
--- Comment #2 from Andrew Pinski ---
This might be just like PR 47120.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
--- Comment #1 from Andrew Pinski ---
The problem is just 'a' in the first (Modifier) column is wrong, it should have
been 'A'. I will commit the patch in a few minutes. Operand column is correct
to use 'A'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #2 from Andrew Pinski ---
long double has padding bits on x86_64 so that is not shocking there.
_Decimal3 is a different issue all together.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31386
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067
Andrew Pinski changed:
What|Removed |Added
CC||antonio.di.monaco at sap dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94116
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -O3 on|[9/10 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94118
Andrew Pinski changed:
What|Removed |Added
Depends on||37188
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94133
--- Comment #2 from Andrew Pinski ---
In the first example combine is able to combine:
Trying 13 -> 14:
13: {r96:SI=r103:SI&0x3f;clobber flags:CC;}
REG_DEAD r103:SI
REG_UNUSED flags:CC
14: {r97:TI=r95:TI<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94132
--- Comment #1 from Andrew Pinski ---
>Can we make this check more robust so valid usage isn't rejected?
Why do you think it is valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94133
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
Andrew Pinski changed:
What|Removed |Added
CC||coryan+gccbugzilla at google
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #3 from Andrew Pinski ---
Most targets output .lcommon or similar for this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
--- Comment #4 from Andrew Pinski ---
(In reply to Martin Liška from comment #3)
I did not notice the git to bugzilla comment connection was not working until
yesterday and then forgot to update this one. THanks for doing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94146
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158
--- Comment #1 from Andrew Pinski ---
A pointer returned from strdup has to be valid to be able pass to free.
Your testcase makes that invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Parker Thompson from comment #3)
> > As for alloc alignment, glibc strdup() does not use aligned_alloc, just
> > malloc. Which by my read of the spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #3 from Andrew Pinski ---
I think part of this optimization should be done on the tree level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
--- Comment #1 from Andrew Pinski ---
>GNU Tools for Arm Embedded Processors 8-2019-q3-update
You should report this to ARM really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182
--- Comment #2 from Andrew Pinski ---
Considering it is documented in another place where char is signed or unsigned.
I don't know if this needs to change.
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Characters-implementation.html#Characters-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94184
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94198
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94206
--- Comment #1 from Andrew Pinski ---
This again padding bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94207
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94207
--- Comment #3 from Andrew Pinski ---
#define ENUM_CLASS_TEST_INIT(k) \
mEnumClassTest[(int)EnumClassTest :: k] = EnumClassTest :: k;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
--- Comment #2 from Andrew Pinski ---
>(at least x86_64 is fine)
No, just FMA is not enabled by default.
If I use -march=skylake-avx512 , I get the same answers as on aarch64_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> >(at least x86_64 is fine)
> No, just FMA is not enabled by default.
> If I use -march=skylake-avx512 , I get the same answers as on aarch64_64.
Note I am runn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
--- Comment #4 from Andrew Pinski ---
Note also using -ffp-contract=off will also change the value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
--- Comment #2 from Andrew Pinski ---
__builtin_setjmp/__builtin_longjmp really should not be used. They are
normally used internally for Exception handling if dwarf2 eh is not enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Nonlocal-Gotos.html#index-_005f_005fbuiltin_005fsetjmp
"You should use the standard C library functions declared in in user
code instead of the builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> "This can make __builtin_setjmp and __builtin_longjmp more efficient than
> their library counterparts in some cases, but it can also cause incorrect
> and myster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
--- Comment #6 from Andrew Pinski ---
Also:
"GCC provides the built-in functions __builtin_setjmp and __builtin_longjmp
which are similar to, but not interchangeable with, the C library functions
setjmp and longjmp."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218
--- Comment #8 from Andrew Pinski ---
(In reply to gsdrtge6h from comment #7)
> Okay, but why the current layout is any better than the suggested layout.
Because these are not useful for anything really. The suggested layout might
require big c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
--- Comment #3 from Andrew Pinski ---
(In reply to Jaroslav Fojtík from comment #2)
> Sorry, it worked for many years without any problems. I has been fixed a
> problem in my WP2LaTeX now.
Well it depends on the ABI for va_list . On the targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #1 from Andrew Pinski ---
-mcmodel=large does not control long calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #2 from Andrew Pinski ---
A patch for -mlong-calls was posted a long time ago but never made it in:
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg02933.html
You should not need -mlong-calls really because the linker should ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #4 from Andrew Pinski ---
Do you have a source where you run into a relocation overflowing?
Or is there a specific reason why you need long calls here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94241
--- Comment #2 from Andrew Pinski ---
#include
int main()
{
struct s { int m; };
s r[] = { s{0}, s{1}, s{2}, s{3} };
std::ranges::find_if(r, [](auto const) { return true; });
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94241
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Component|libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=553
Andrew Pinski changed:
What|Removed |Added
CC||markd at kermodei dot com
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94244
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
--- Comment #1 from Andrew Pinski ---
Short types are promoted to int when passed to variable arguments functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #6 from Andrew Pinski ---
Note for Threos OS, please don't reuse the same target triplet as elf or linux;
use your own triplet. Also adding long calls is not hard and such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247
--- Comment #8 from Andrew Pinski ---
(In reply to Martin Sebor from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > No, it diagnoses the main bug
>
> Nope, it does not. -Wchar-subscripts is designed and documented to diagnose
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #8 from Andrew Pinski ---
(In reply to Eyal Rozenberg from comment #6)
> (In reply to Richard Biener from comment #5)
> > DSE part ... DCE
>
> DSE = Dead Statement Elimination? DCE = Dead Code Elimination?
I thought Dse was dead st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
--- Comment #2 from Andrew Pinski ---
I forgot to say one more thing, GCC is more strict than LLVM when it comes to
temps going out of scope too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
1 - 100 of 25767 matches
Mail list logo
