: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
Following reduced testcase gives a bogus -Wdangling-pointer:
struct tEntry
{
int value;
};
struct tOut
{
int outvalue;
};
extern struct tOut *out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90809
Thomas De Schampheleire changed:
What|Removed |Added
CC||patrickdepinguin at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90816
Thomas De Schampheleire changed:
What|Removed |Added
CC||patrickdepinguin at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173
--- Comment #4 from Thomas De Schampheleire
---
Note also that in the test program of comment #3, there is no problem if using
the 'password' or 'application' fields, rather than 'user', which is first in
the structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173
--- Comment #3 from Thomas De Schampheleire
---
While the original test program failed on gcc 11.2.0 but not on gcc 9.4.0, I
now encounter a very similar case that does fail on gcc 9.4.0:
--
#include
#define
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 and gcc 9.4.0 give a bogus format-truncation warning on following
test case compiled with -Wall and -O2
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 reports the following on a reduced test case:
$ powerpc-linux-gcc -c array-bounds-fruit.c -O2 -Wall -Werror
array
: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 gives a bogus warning of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #23 from Thomas De Schampheleire ---
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #33 from Thomas De Schampheleire ---
(In reply to Andrew Pinski from comment #32)
> >I'm currently using -march=octeon3 or -march=octeon2 as appropriate.
>
> Can you report this to Marvell (Cavium)? O32 was not used much on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #31 from Thomas De Schampheleire ---
(In reply to Maciej W. Rozycki from comment #27)
> Yes, it is the same problem, the same address calculation occurs here,
> and the lack of 32-bit address space wraparound is a part of the n32
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #30 from Thomas De Schampheleire ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #26 from Thomas De Schampheleire ---
(In reply to Thomas De Schampheleire from comment #25)
> Is it possible that this same problem is applicable on the 'lwx' instruction?
> I am using MIPS64 n32.
>
> I first saw the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #25 from Thomas De Schampheleire ---
Is it possible that this same problem is applicable on the 'lwx' instruction?
I am using MIPS64 n32.
I first saw the original problem as described in this bug with instruction
'lwxc1'. I then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24551
--- Comment #4 from Thomas De Schampheleire
---
Could it not be that #14167 is now fixed after fixing #86964 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #18 from Thomas De Schampheleire ---
Second version of patch, fixing testsuite failures, was posted:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01403.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #17 from Thomas De Schampheleire ---
Thanks, see:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00922.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #15 from Thomas De Schampheleire ---
Created attachment 46361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46361=edit
Make -feliminate-unused-debug-symbols the default
Attached patch makes -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #13 from Thomas De Schampheleire ---
I have applied the patch on a gcc 7.4 PPC toolchain, and tested on a code base
where the problem existed. The original ELF object size (of one example source
file) in a pre-gcc-7 toolchain (gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #11 from Thomas De Schampheleire ---
It seems the necessary patch is applied now, are these the only changes
The target milestone is set 7.5. Do you have any rough idea when that would be
released?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #11 from Thomas De Schampheleire ---
Any feedback? With the reduced testcase qemu is out of the picture.
Do you agree that this is a bug in gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #4 from Thomas De Schampheleire
---
I am suffering from this same problem using gcc 7.3.0 on a Broadcom SDK.
Due to this, compiled object files increase from 90 KiB (using gcc 4.9.2) to 15
MiB (gcc 7.3.0). This size increase is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #10 from Thomas De Schampheleire ---
I was able to further investigate and reduce the problem.
Qemu is now out of the picture, I can reproduce the issue directly on a real
CPU. All I need to do is enable the 'underflow' exception bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #8 from Thomas De Schampheleire
---
To clarify the situation with underflow / denormal exception I will debug the
issue again and inspect the corresponding registers.
I'm not familiar with 'NaNs': is it a specific value that I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #6 from Thomas De Schampheleire
---
(In reply to Florian Weimer from comment #5)
> (In reply to Thomas De Schampheleire from comment #4)
> > When analyzing this problem with gdb, we looked at the floating-point status
> > register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #4 from Thomas De Schampheleire
---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Thomas De Schampheleire from comment #0)
> > gcc 7.3.0 optimizes below code in a way that may cause a floating-point
> > underflow (SIGFPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #1 from Thomas De Schampheleire
---
Created attachment 45112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45112=edit
gzipped source file, part 2
: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
Created attachment 45111
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85398
--- Comment #3 from Thomas De Schampheleire
---
(In reply to Richard Biener from comment #2)
>
> We could change the warning to have a "may be above array bounds" form
> for your case but that wouldn't handle the bar() case.
The problem with
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
In following test program:
--
#define NB_DEV 1
extern unsigned int max;
uns
30 matches
Mail list logo
