rity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
When compiling with g++ anonymous structs / unions inside C functions conflict
based on their variable name. That wa
: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Created attachment 44775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44775&action=edit
Repro
Hi,
With the attached, obviously heavily condensed, testcase I get a spurious
-W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
--- Comment #2 from Andres Freund ---
Maybe (In reply to Jonathan Wakely from comment #1)
> The first XLogRegisterData could change the value of xl_xinfo.xid to be
> non-zero, in which case the second XLogRegisterData call would happen
> despite
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 40989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #6 from Andres Freund ---
Hi,
Can confirm this patch fixes the specific code generation issue I
complained about, leading to an overall 1.9% improvement in TPC-H
performance. There's still some counterproductive jumps, but they're
u
ent: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
In gcc 4.8 a binary compiled with "gcc -g3 ... -g" would include the extended
debug information (e.g. macros), while in gcc 4.9 the second -g seems to lower
the debug level.
That'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #2 from Andres Freund ---
Hi,
On 2014-04-30 14:54:20 +, pinskia at gcc dot gnu.org wrote:
> -g is the same as -g2 and the later option is supposed to override the first
> one. Jus like how -O is handled.
The point is that this ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #5 from Andres Freund ---
Hi,
On 2014-04-30 15:48:33 +, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
>
> --- Comment #4 from Andrew Pinski ---
> It was not on accident, see
> http://gcc.g
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
I'm working on some interpreter like constructs in postgres. To reduce the
number of mispredictions I wanted to use the "typical" jump threading approach.
Unfortu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #1 from Andres Freund ---
Created attachment 38845
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38845&action=edit
reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076
--- Comment #4 from Andres Freund ---
(In reply to Patrick Palka from comment #3)
> Fixed for GCC 11. Thanks for the report.
Thanks!
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
When compiling one of postgres' source files with -O3 I see the following:
gcc-11 -O3 -Wall -o /dev/null -c tsvector_op.i
In function 'tsCom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
--- Comment #2 from Andres Freund ---
Created attachment 50763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50763&action=edit
preprocessed reproducer
Huh, sorry for that. I thought I had attached it. When I tried again now it
failed due
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
recently started seeing bogus warnings using gcc 12 to build postgres. I
reduced the problem
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
The attached reproducer shows a miscompilation I found building postgres. I've
bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #1 from Andres Freund ---
Created attachment 53441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53441&action=edit
reproducer
: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 53529
--> https://gcc.gnu.
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Created attachment 53693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53693&action=edit
reproducer
Hi,
When building postgres with gcc 13 I get a lot of ICEs. I rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
--- Comment #4 from Andres Freund ---
> Ending up with an excessive range isn't uncommon in code that freely converts
> between signed and unsigned integers (e.g., by passing an int to a size_t
> argument) and involves conditionals like those
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Created attachment 51168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51168&action=edit
sim
atus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
Whenever an allocator function annotated with attribute((malloc(freelike)) is
defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110609
--- Comment #2 from Andres Freund ---
(In reply to Andrew Pinski from comment #1)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 110546 ***
Are they really the same? This bug happens at -O0 and requires -fPIC and
-fno-semantic-i
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Created attachment 55531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55531&action=edit
reproducer
Hi,
The attached minimized reproducer (from postgres code) tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #8 from Andres Freund ---
FWIW, a few of postgres' CI instances (which intentionally track a snapshot
gcc) are hitting this (see e.g. [1]). I reproduced the failure locally, applied
the patch from [2], after which the build succeeds.
24 matches
Mail list logo