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=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
Last reconfirmed||2020-11-11
Status|UNCONFIRME
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=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; disabletailcal
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=97844
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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 p
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=97916
Andrew Pinski changed:
What|Removed |Added
Keywords|documentation |
Last reconfirmed|
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=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 a
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=97964
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
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=97989
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=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=97992
Andrew Pinski changed:
What|Removed |Added
Depends on||69899
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Andrew Pinski changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
Ke
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=98106
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Summary|gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|[aarch64] Interna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Andrew Pinski changed:
What|Removed |Added
Host|Linux |
|5.8.15-301.fc33.x86_
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=98190
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #1 from Andrew Pi
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=88662
Andrew Pinski changed:
What|Removed |Added
CC||vstinner at redhat dot com
--- Comment #
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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=98209
--- Comment #1 from Andrew Pinski ---
Can you provide the preprocessed source?
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=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=98250
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=97202
--- Comment #1 from Andrew Pinski ---
Could this be a c++17 difference?
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=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=97222
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
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=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=98404
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=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
--- 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=98425
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski -
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=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=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 y
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=98502
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|c
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 singed
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=98634
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=98648
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski -
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=98663
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=98681
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=98621
Andrew Pinski changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98715
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
URL|https://go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #2 from Andrew Pinski
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=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=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=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=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=97787
Andrew Pinski changed:
What|Removed |Added
Component|target |lto
CC|
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=98841
--- Comment #4 from Andrew Pinski ---
-Weffc++ is really a bad option in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98847
--- Comment #2 from Andrew Pinski ---
I think this is a dup of bug 33661.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
--- Comment #1 from Andrew Pinski ---
I am 90% sure this is just a register allocation issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Andrew Pinski changed:
What|Removed |Added
Depends on||91753
--- Comment #2 from Andrew Pinski
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=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=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 workli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I think this code is undefined/unspecified as -86 is outside the range of an
> unsigned int.
Even with changing to cast to int first still gives the same. Note
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 ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98927
--- Comment #4 from Andrew Pinski ---
This issue has come up for both Altivec/VMX (RS6000) and ARM/AARCH64 intrinsics
before. I think they both came up slightly different solutions. I can't
remember fully what the solutions were but from what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98867
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-02-04
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98977
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
--- Comment #5 from Andrew Pinski ---
Note C and C++ are differ here. C says only if the return value is used it
becomes undefined while in C++ it is undefined at the point of return.
201 - 300 of 25813 matches
Mail list logo