https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92669
--- Comment #1 from Andrew Pinski ---
fma-steering is an aarch64 specific pass so this is a target issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #11 from Andrew Pinski ---
(In reply to Klaus Leppkes from comment #9)
>
> g++ -c error_large_lvalue.cpp
> error_large_lvalue.cpp: In function ‘void DoNotOptimize(Tp&) [with Tp =
> Large]’:
> error_large_lvalue.cpp:16:48: error: inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #5 from Andrew Pinski ---
(In reply to Jonny Grant from comment #4)
> This test case for similar does have a nice warning.
>
> Interestingly, G++ does not indicate that 5147483647 is already 34 bits long:
> 1001100101101010111011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
--- Comment #3 from Andrew Pinski ---
(In reply to Jürgen Reuter from comment #2)
> (In reply to Richard Biener from comment #1)
> > Try -fcommon, it's default recently was swapped to -fno-common.
>
> The default for gcc was changed? Which commi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
--- Comment #2 from Andrew Pinski ---
bit-fields in C is a type.
while in C++, it is not.
So:
st.v2 << 3
This is not ((long)st.v2) << 3 but rather (long:45)<<3. So it gets truncated.
C11:
fff8
0xfff8
1ffffff8
1 2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684
--- Comment #3 from Andrew Pinski ---
There is a defect report dealing with this in C and such.
Both are correct for C11 but would be incorrect for C90 which defines bit-field
types because of the defect report. GCC decided to follow the C90 way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
Andrew Pinski changed:
What|Removed |Added
Keywords|easyhack|
--- Comment #8 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
Andrew Pinski changed:
What|Removed |Added
CC||boostcpp at gmail dot com
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
--- Comment #2 from Andrew Pinski ---
index was the POSIX name for strchr (because issue 6 marked as legacy):
https://pubs.opengroup.org/onlinepubs/009695399/functions/index.html
GCC does not have full control over glibc and even then read the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92689
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
--- Comment #4 from Andrew Pinski ---
See PR 11196 and PR 2082 for that issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> See PR 11196 and PR 2082 for that issue ...
More to the point is glibc still does not do the right thing for what is needed
to support C++11 and above:
https://s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92689
--- Comment #3 from Andrew Pinski ---
The argument p could have been a non const when it was passed to foo.
That is outside of the this TU:
static int t;
void (void)
{
foo (&t);
}
void fn(void)
{
t++;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92689
--- Comment #4 from Andrew Pinski ---
Actually the testcase which causes the return true to be correct would be:
extern int data;
void (void)
{
foo (&data);
}
void fn(void)
{
data++;
}
CUT ---
I think you need either a better testca
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
Created attachment 47375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
--- Comment #2 from Andrew Pinski ---
Also #pragma are considered statements. There is another issue like this but
instead using _Pragma .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #1 from Andrew Pinski ---
>it turns out the issue is a gcc issue and a glibc issue.
NOTE I had missed out a word here:
This should have read:
it turns out the issue is a gcc issue and NOT a glibc issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Also #pragma are considered statements. There is another issue like this
> but instead using _Pragma .
I should say some Pragmas are considered statements.
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
Andrew Pinski changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #4 from Andrew Pinski ---
(In reply to Wilco from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I think this has been a latent bug since revision 243200:
> > [AArch64] Separate shrink wrapping hooks implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #6 from Andrew Pinski ---
(In reply to Wilco from comment #5)
> Well I'm looking at the latest version
> (https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in
> figure B2-5 it explicitly states that a store that d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #2 from Andrew Pinski ---
Most likely what is happening is the following:
inlining happens twice but the detection of bswap does not happen until after
both inlining so the cost huestric for byteswap function is high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #1 from Andrew Pinski ---
I don't think this is a bug, __DATE__ is one of the predefined macros and I
think it is included in GCC's precompiled headers.
Really ccache is broken anyways.
>As builds of regular C(++) files are determin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #7 from Andrew Pinski ---
(In reply to Richard Biener from comment #6)
> Well, pch files essentially contain a memory dump of GCCs internal state so
> I very much expect differences for example when address-space randomization
> is tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733
--- Comment #1 from Andrew Pinski ---
This error message does not make sense. Xgcc/xg++ should not be used to link
cc1. For a cross.
Can you provide how you configured?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
--- Comment #1 from Andrew Pinski ---
>is too general and important a piece of information to be buried in the
>documentation of individual warning flags.
Yes because you should read the whole documentation rather than bits and pieces
of it. W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
--- Comment #2 from Andrew Pinski ---
I don't think this is a valid testcase, given:
Both KeyId and Value may be non-trivial (non-POD) types provided
a suitabe Traits class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92762
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
--- Comment #4 from Andrew Pinski ---
*** Bug 92762 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Only values are being used in the whole of GCC are all PODs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #3 from Andrew Pinski ---
But isn't the case magic could be considered a variable length field since it
is st the end of the struct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92786
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: pinskia at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Target: aarch64_be-marvell-linux-gnu
cpugen.go:3:1: error: expected operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
--- Comment #2 from Andrew Pinski ---
(In reply to Tim Ruehsen from comment #1)
> BTW, llvm-cxxfilt does not show this behavior.
Could it because it does not implement the D demangler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
Andrew Pinski changed:
What|Removed |Added
Keywords||build
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
--- Comment #3 from Andrew Pinski ---
Are you saying the warning shows up which causes the bootstrap to fail?
Because at runtime there should be no out of bounds access.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu, m68k
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #3 from Andrew Pinski ---
Next error:
/bajas/pinskia/src/toolchain-10/scripts/../src/libgo/go/internal/syscall/unix/getrandom_linux.go:35:34:
error: reference to undefined name ‘randomTrap’
35 | r1, _, errno := syscall.Syscall(ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Testing that (and see what the next failure is)
After the above patch, there are no build failures; I have not tried to run the
testsuite yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #23 from Andrew Pinski ---
(In reply to Maxim Kuvyrkov from comment #21)
>
> Is there a way to fix the problem gcc-9-branch in less intrusive way?
Could this be an alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92850
--- Comment #1 from Andrew Pinski ---
The crash itself should report to llvm project for sure.
Are you sure concepts are fully implemented in clang?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
--- Comment #1 from Andrew Pinski ---
The libstdc++ headers have visibility extern on them. Looks like the symbol
you are pointing out would be one of those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-09
CC||pinskia at gcc dot gnu.org
Target Milestone|--- |10.0
Summary|regressions on aarch64 |[10 Regression] testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92857
--- Comment #4 from Andrew Pinski ---
(In reply to Joshua Saxby from comment #2)
> (In reply to Richard Biener from comment #1)
> > I think the warning is about foo - bar being carried out in type 'int' due
> > to
> > integer promotion and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92869
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Andrew Pinski changed:
What|Removed |Added
Target||i?86-linux-gnu
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92880
--- Comment #1 from Andrew Pinski ---
Because the fixed types in C99 are just typedef of normal types. So it really
does not need to describe that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92891
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92889
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92892
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92892
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902
--- Comment #1 from Andrew Pinski ---
This is a target specific issue. That is each target decides where to put the
jump table. On some targets, it is already done not in the text section but
the rodata section. It seems like sparc is not one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92903
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92903
--- Comment #3 from Andrew Pinski ---
There are a lot of bswap optimizations missing I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92903
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92915
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902
--- Comment #16 from Andrew Pinski ---
(In reply to Jean-Christophe Dubois from comment #15)
> Am I missing something?
YES. Most likely it will not be loaded in the instruction cache as it is
larger than the cache line size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659
--- Comment #8 from Andrew Pinski ---
I have a C testcase which I will be adding by the end of the week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659
--- Comment #9 from Andrew Pinski ---
Author: pinskia
Date: Fri Dec 13 08:31:42 2019
New Revision: 279338
URL: https://gcc.gnu.org/viewcvs?rev=279338&root=gcc&view=rev
Log:
Add C testcases for PR 86659
testsuite/ChangeLog:
2019-12-13 Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> I have a C testcase which I will be adding by the end of the week.
Done:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00924.html
https://gcc.gnu.org/ml/gcc-cvs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92922
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92921
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92934
--- Comment #3 from Andrew Pinski ---
The gcc patch that is attached has incorrect definition for allegrex_madd and
allegrex_msub. It uses match_dup when it should really be using match_operand
and the constraint of "0".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92934
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92934
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932
--- Comment #1 from Andrew Pinski ---
Dup of at least PR92294 and PR54666; I thought there was a much older bug
dealing with the alias attribute but I can't seem to find it right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92938
--- Comment #2 from Andrew Pinski ---
I don't think this is a GCC bug.
The reasoning is bitmap_replace is not marked as being in the section .init_*
at all. GCC decides to clone it for constant-prop. Really any function which
is marked as __gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92938
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While working on lowering bit-field accesses (to allow better optimizations on
the tree level rather than just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #1 from Andrew Pinski ---
Created attachment 47501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47501&action=edit
The current bit-field lowering patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 47501 [details]
> The current bit-field lowering patch
I attached the current bit-field lowering patch so if someone wants to work on
this, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
Andrew Pinski changed:
What|Removed |Added
Summary|bswap/store merging does|bswap/store merging does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #4 from Andrew Pinski ---
Created attachment 47502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47502&action=edit
one testcase
This is just one example expanded; note scan-tree-dump-times needed to be
updated as I added a few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
--- Comment #1 from Andrew Pinski ---
Is the printf before or after main?
If before, then the problem is the order of variables initialized from
different translational units is unspecified and therefore undefined.
If after, then maybe somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
--- Comment #8 from Andrew Pinski ---
NOTE yes there is a missing -Wshadow warning, I will file it in a second.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int t;
struct g{
int t;
void h(void)
{
t++;
}
};
CUT ---
I would have thought there would be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #11 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> NOTE yes there is a missing -Wshadow warning, I will file it in a second.
PR92954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
--- Comment #3 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #2)
> Well, the aarch64 backend does not implement subv4 pattern in the
> first place, which would be required for efficient branchy code:
>
> foo:
> subs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92963
--- Comment #1 from Andrew Pinski ---
Take:
if (p == q)
r = p;
else
r = q;
p cannot be q as they cannot be based on each other based on my reading of
6.7.3.1p3.
Therefore r is only ever based on q.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #63 from Andrew Pinski ---
Note match.pd has a similar bug. Here is the patch which fixes it:
diff --git a/gcc/match.pd b/gcc/match.pd
index 92b93b0..8607abe 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5676,16 +5676,18 @@ DEFINE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #5 from Andrew Pinski ---
Note bswap pass is very fragile. In fact if we increase the limit by 1, things
dont work any more. There needs to be a better way of handling this.
Oh when I was adding bit insert to it, it falls over due
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
Take these two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
Andrew Pinski changed:
What|Removed |Added
Depends on||92979
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Note bswap pass is very fragile. In fact if we increase the limit by 1,
> things dont work any more. There needs to be a better way of handling this.
PR 92979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #4 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #3)
>
> ptrop ---> src1 + 18446744073709551612;
> intop ---> j
>
> It seems on purpose???
Kinda.
What needs to happen is a sign extend rather than a zero extend which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92957
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from
601 - 700 of 29156 matches
Mail list logo
