https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #7 from pkoning at gcc dot gnu.org ---
Thanks Jakub.
Inspecting the generated assembly language is a sufficient check of the fix in
my view. It's interesting that the test case shows the problem only with -O0.
When optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #11 from pkoning at gcc dot gnu.org ---
(In reply to Stephen Casner from comment #9)
A lot of these questions should have answers in the GCC Internals manual, which
is quite good. And also quite dense. I know it a little, enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508
--- Comment #4 from pkoning at gcc dot gnu.org 2012-10-23 18:44:33 UTC ---
Author: pkoning
Date: Tue Oct 23 18:44:27 2012
New Revision: 192739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192739
Log:
PR deb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47214
Summary: False warning "null argument where non-null required"
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47214
--- Comment #2 from Paul Koning 2011-01-11
12:00:56 UTC ---
Not if you look at that call in isolation, true. But right before it in the
test program is a check that does exactly this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
Bug #: 50189
Summary: Wrong code error in -O2 compile, target independent
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #1 from Paul Koning 2011-08-25
17:19:23 UTC ---
Created attachment 25106
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25106
gcc -v output (configure options etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
Paul Koning changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Paul Koning 2011-08
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #6 from Paul Koning 2011-09-09
19:11:01 UTC ---
I saw the note that PR/49911 is fixed and thought that might mean this one is
fixed also. Unfortunately testing shows that is not the case, at least not in
4_5_branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
Bug #: 50569
Summary: Wrong code error: memcpy eliminated when it is needed
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
Paul Koning changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
--- Comment #3 from Paul Koning 2011-09-29
19:52:47 UTC ---
Created attachment 25383
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25383
Test case with main()
Here is an updated testcase. This one runs to completion with 4.5.1, aborts
wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
--- Comment #5 from Paul Koning 2011-09-29
20:55:15 UTC ---
If the memcpy actually happens, that is the expected result. The issue in the
MIPS case is that the memcpy is optimized away, and the source data accessed
instead, which would be ok if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #7 from Paul Koning 2011-10-10
20:41:35 UTC ---
Re comment 5, does "works by luck" mean that I should not look in trunk for a
fix to backport because nothing was actually fixed?
Should I just avoid all versions of GCC newer than 4.4?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #10 from Paul Koning 2011-10-11
19:03:24 UTC ---
Created attachment 25467
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25467
Tentative patch against 4.6.1
I chased the issue for a while, using 4.6.1 as the test version.
The p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #12 from Paul Koning 2011-10-12
14:04:30 UTC ---
You said "GCC treats types compatible when they have the same precision".
That's where the problem lies, because enums with -fstrict-enums have their
precision set to just enough bits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459
Paul Koning changed:
What|Removed |Added
Known to fail||4.1.2
--- Comment #2 from Paul Koning 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147
Bug #: 51147
Summary: attribute((mode(byte))) on an enum generates wrong
code
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147
Paul Koning changed:
What|Removed |Added
Priority|P3 |P2
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147
--- Comment #2 from Paul Koning 2011-11-16
01:47:27 UTC ---
Thanks, I'll give that a try for another workaround.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147
--- Comment #3 from Paul Koning 2011-11-18
11:49:56 UTC ---
That workaround seems to do the right thing for what I need, so I'm no longer
stuck. Thanks for the suggestion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88435
--- Comment #2 from pkoning at gcc dot gnu.org ---
I don't see it in the current V9, rev 266823.
./xgcc -B. -O2 -S ~/Documents/pr88435.c -m10
cat pr88435.s
.text
.even
.globl _pollConsole
_pollConsole:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639
pkoning at gcc dot gnu.org changed:
What|Removed |Added
CC||pkoning at gcc dot gnu.org
: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
This issue is exposed by test case testsuite/gcc.c-torture/compile/930326-1.c,
on platforms where ptrdiff_t is not "long"
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 44308
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44308&action=edit
Test case for the issue
The attached test program causes an ICE when compiled fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86271
--- Comment #1 from pkoning at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc/2018-06/msg00228.html is the discussion and mentions
a possible fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 44922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44922&action=edit
variable and function alignment test case
Variable alignment is
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and
label (-falign-label=n) alignment is not. This causes requests to the target
code to generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795
--- Comment #1 from pkoning at gcc dot gnu.org ---
Created attachment 44923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44923&action=edit
variable and function alignment test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795
--- Comment #2 from pkoning at gcc dot gnu.org ---
Created attachment 44924
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44924&action=edit
label alignment test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795
--- Comment #6 from pkoning at gcc dot gnu.org ---
(In reply to Joel Sherrill from comment #4)
> I added myself as a CC because I want to see if these become errors or
> warnings. For core parts of RTEMS, I can see wanting these to be
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 44977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44977&action=edit
Dump file before reload
I see this on pdp11, I haven't found a mai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944
--- Comment #1 from pkoning at gcc dot gnu.org ---
Created attachment 44978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44978&action=edit
Reload dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944
--- Comment #2 from pkoning at gcc dot gnu.org ---
Created attachment 44979
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44979&action=edit
Test program source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
--- Comment #1 from pkoning at gcc dot gnu.org ---
What is your target? I checked this on linux-x86_64 (native build). I don't
see the complaint about line 15 in that run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pkoning at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
--- Comment #5 from pkoning at gcc dot gnu.org ---
Could you post the full config specification and what the build system is? It
seems hard to reproduce, and it is rather puzzling for a powerpc build to
trigger a check that is explicitly there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
--- Comment #9 from pkoning at gcc dot gnu.org ---
Comment? I thought the comment is the null string after the regexp to match.
Should it read { target { pdp11-*-* } } with the extra braces?
Other examples show up both with the braces and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
--- Comment #11 from pkoning at gcc dot gnu.org ---
Thanks, I had forgotten.
Seurer, could you update to r265741 or later and check if that cures the issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
Summary: MIPS wrong code error with -O1
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
--- Comment #1 from Paul Koning 2011-05-13
16:40:55 UTC ---
GCC 4.6.0 gets it wrong also, in exactly the same way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
--- Comment #4 from Paul Koning 2011-05-13
18:16:11 UTC ---
Re comment 2: Sorry, my typo, I incorrectly transcribed the .s file. It's a
beq, not a beql.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
--- Comment #3 from Paul Koning 2011-05-13
18:14:00 UTC ---
The problem also shows up with -mabi=64, but it works correctly for -mabi=32
and -mabi=o64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
--- Comment #5 from Paul Koning 2011-05-13
18:20:42 UTC ---
Created attachment 24242
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24242
Assembly output from -mabi=n32 case, GCC 4.5.1
Here is the assembly file (with -dA so basic block boun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
--- Comment #6 from Paul Koning 2011-05-13
20:29:50 UTC ---
Created attachment 24243
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24243
debug dump from the pass before machdep
After some debugging, I see that the problem is that register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990
Paul Koning changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775
Paul Koning changed:
What|Removed |Added
CC||pkoning at gcc dot gnu.org
--- Comment #12
||2010.10.29 00:28:57
CC||pkoning at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |pkoning at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41822
Paul Koning changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459
Summary: attribute((mode(byte))) in a typedef produces wrong
debug information
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59942
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84437
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
This issue was revealed by bug 84437. The reproducer given there now produces
"correct" code but it's quite inefficient because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59847
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84438
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-03-19
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87821
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93719
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96050
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-03-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99645
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 54259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54259&action=edit
Reproducer for this issue
In gcc for pdp11-aout, compiling w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 53803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53803&action=edit
Reproducer. Compile with -O3
The attached code produces a stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107476
--- Comment #1 from pkoning at gcc dot gnu.org ---
I should mention that I reproduced this (a) on an M1 Mac running gcc (GCC)
13.0.0 20220827 (experimental), and also on an x86 Linux running gcc (GCC)
12.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113947
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-07-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93719
--- Comment #1 from pkoning at gcc dot gnu.org ---
This works with -mlra, so given the deprecation of old reload the right answer
seems to be to close this as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801
pkoning at gcc dot gnu.org changed:
What|Removed |Added
CC||pkoning at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806
pkoning at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96050
--- Comment #1 from pkoning at gcc dot gnu.org ---
There certainly are some missing earlyclobbers in the MD file. Someone else
reported bad code from this and a patch to add the missing "&" fixed those.
Curious that it doesn&#
75 matches
Mail list logo
