https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
--- Comment #3 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Sounds like the binutils does not have the needed support for (32bit)
> > multilib.
>
> so I should build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #1 from Andrew Pinski ---
This feels like an use after something goes out of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-10-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
--- Comment #1 from Andrew Pinski ---
Could this be a c++17 difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215
--- Comment #3 from Andrew Pinski ---
fopen/fread/fwrite DOES NOT come from GCC, but rather than in this case mingw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97225
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98647
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98634
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98572
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88731
Andrew Pinski changed:
What|Removed |Added
CC||vonchun at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98572
--- Comment #1 from Andrew Pinski ---
>Even if integer promotion happens, it should be promoted as "unsigned int" as
>well.
Why do you think it should be promoted to unsigned int rather int? Since a
24bit unsigned int fits into a 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #1 from Andrew Pinski ---
so you are asking not to show the source file for #warning ?
I don't see why this warning should be treated as any different from any other
warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278
--- Comment #9 from Andrew Pinski ---
(In reply to danikiw542 from comment #8)
> https://kodlogs.com/blog/852/warning-control-reaches-end-non-void-function-
> wreturn-type
values not defined in enum's are still valid and well defined, that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98159
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98168
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Andrew Pinski changed:
What|Removed |Added
Host|Linux |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
Andrew Pinski changed:
What|Removed |Added
CC||vstinner at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #4 from Andrew Pinski ---
(In reply to Victor Stinner from comment #3)
> Well, either all 64 bits of w4 and w5 registries should be initialized
> properly, or the comparison should be done only on the least significant 8
> bits:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98207
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> The default is to use fused multiple add.
> If you don't want to use FMA, then use -ffp-contract=off (the default =fast).
>
>
> x84_64 by default does not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98207
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
--- Comment #1 from Andrew Pinski ---
Can you provide the preprocessed source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976
--- Comment #1 from Andrew Pinski ---
I don't think there is a bug here.
This loop here:
for (const int* pi = data; pi; ++pi)
invokes undefined behavior as pi can never become null after doing the
increment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #1 from Andrew Pinski ---
Are you sure this just not a divide by zero? On x86, an integer divide by zero
will throw an FPU exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97992
Andrew Pinski changed:
What|Removed |Added
Depends on||69899
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|[aarch64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Summary|gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Andrew Pinski changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055
--- Comment #1 from Andrew Pinski ---
See the thread starting at:
https://gcc.gnu.org/pipermail/gcc-patches/2019-June/523700.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98070
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366
--- Comment #2 from Andrew Pinski ---
The question be asked if (S[]){{.alignment = 3, '(', 2.0}} has a defined S[0].b
to be 0 or is uninitialized?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98250
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #3 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #2)
> Oh, but you didn't enable any optimization at all, so who cares about the
> performance?
I was thinking the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98261
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98425
--- Comment #2 from Andrew Pinski ---
Note your optimum code is wrong.
movl %esi, %eax
Is a zero extend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98425
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98436
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98436
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98436
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418
--- Comment #1 from Andrew Pinski ---
Shifting into the sign bit is problematic. I cant remember the exact rules.
Using ull is valid though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416
--- Comment #4 from Andrew Pinski ---
You need to use the target atrribute on CPU_ProbePower9 so GCC won't use power9
instructions on it.
Something like:
bool CPU_ProbePower9() __attribute__((target("cpu=power7")));
bool CPU_ProbePower9()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98286
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.5.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98404
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
--- Comment #1 from Andrew Pinski ---
Reassociation is done for signed types and places where it could introduce
overflows.
If you -fwrapv, you should get the optimization. Likewise for unsigned types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97802
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97802
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-11-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831
--- Comment #1 from Andrew Pinski ---
I can think of a simple way disabling tail calls:
static void disabletailcallfunc(void*) __attribute__((noipa));
static void disabletailcallfunc(void *x){}
#define disabletailcall() do {int a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831
--- Comment #2 from Andrew Pinski ---
I think this was rejected 3 years ago:
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-05/msg02221.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
And see https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg00130.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97916
Andrew Pinski changed:
What|Removed |Added
Keywords|documentation |
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97916
Andrew Pinski changed:
What|Removed |Added
Component|c |bootstrap
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #6 from Andrew Pinski ---
(In reply to luoxhu from comment #4)
> float foo(float f, float x, float y) {
> return (fabs(f)*x+y);
> }
>
> the input of fabs is float type, so use fabsf is enough here, drafted a
> patch to avoid double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97677
Andrew Pinski changed:
What|Removed |Added
Known to work||7.5.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97658
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743
--- Comment #4 from Andrew Pinski ---
What about:
(-B)&743
Is that faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> What about:
> (-B)&743
> Is that faster?
Never mind I see it was not :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98467
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #2 from Andrew Pinski ---
(In reply to ktkachov from comment #1)
> Or a =r,r,r alternative to the FCSEL pattern instead...
Should most likely add the r alternative to *cmov_insn (GPF) and the w
alternative to *cmov_insn (ALLI). So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-12-30
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485
--- Comment #1 from Andrew Pinski ---
I thought the C++ rule was all specializations has to be seen when you use one
or the other. Otherwise this becomes an ODR issue and therefor invalid code
(not have to be diagnostic at compile time).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667
--- Comment #2 from Andrew Pinski ---
Is this directly on a i486 box or VirtualBox? VirtualBox might have a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98715
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98621
Andrew Pinski changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801
--- Comment #1 from Andrew Pinski ---
I don't think we need a builtin. Because we could just improve the code
generation instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829
--- Comment #1 from Andrew Pinski ---
NaNs do prograte but as far as I know can change values as long as it is still
a NaN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #5 from Andrew Pinski ---
(In reply to Jiu Fu Guo from comment #0)
> For the below code:
> ---t.c
> void
> foo (const double* __restrict__ A, const double* __restrict__ B, double*
> __restrict__ C,
> int n, int k, int m)
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98794
--- Comment #1 from Andrew Pinski ---
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98758
Andrew Pinski changed:
What|Removed |Added
Version|unknown |11.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98649
Andrew Pinski changed:
What|Removed |Added
Component|c++ |middle-end
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93390
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817
--- Comment #3 from Andrew Pinski ---
This cannot be done due to race conditions too:
https://gcc.gnu.org/wiki/Atomic/GCCMM/DataRaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Andrew Pinski changed:
What|Removed |Added
Component|target |lto
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
--- Comment #1 from Andrew Pinski ---
I think you misunderstood the diagnostic. It is saying unsigned int is for %u.
The type you have is int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98682
--- Comment #1 from Andrew Pinski ---
I think this is a dup of bug 772.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98648
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98502
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #2 from Andrew Pinski ---
See PR 29305 and others too on why this is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
--- Comment #1 from Andrew Pinski ---
So ccp3 is doing it.
Visiting statement:
quo_lo_52 = floorf (_51);
which is likely CONSTANT
Match-and-simplified floorf (_51) to -8.6e+1
Lattice value changed to CONSTANT -8.6e+1. Adding SSA edges to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
--- Comment #3 from Andrew Pinski ---
unsigned quo = (uint32_t)(int64_t)(quo_hi) +
(uint32_t)(int64_t)(quo_lo);
Fixes the issue ..
1 - 100 of 23181 matches
Mail list logo