https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
Peter Bergner changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
--- Comment #4 from Peter Bergner ---
Jeevitha is looking into this, but the last thing I saw, it looked like an
issue on powerpc where the callee mistakenly thinks the caller has allocated a
param save area (which is located in the caller's sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #13 from Peter Bergner ---
(In reply to Alexandre Oliva from comment #12)
> I'll give them a try and report back.
Thanks. Just don't use the patch in Comment #2. Please use the patches in
Comment #7 and Comment #9 instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #9 from Peter Bergner ---
(In reply to Peter Bergner from comment #8)
> Both messages seem valid, so I think we can probably modify the test case to
> look for both error messages.
This fixes the test case:
diff --git a/gcc/testsuit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> (In reply to Peter Bergner from comment #1)
> > > but the conditions that enable the expansion of
> > > __builtin_scalar_byte_in_set
> > > are those of [power9-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #2 from Peter Bergner ---
(In reply to Peter Bergner from comment #1)
> > but the conditions that enable the expansion of __builtin_scalar_byte_in_set
> > are those of [power9-64], namely TARGET_MODULE && TARGET_POWERPC64.
> I beli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640
Bug ID: 119640
Summary: ICE: verify_ssa failed error compiling gem5 since
r15-3509-gd34cda72098867
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
Peter Bergner changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
Bug ID: 119597
Summary: SEGV on Cobol "hello world" on Power
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> (In reply to Peter Bergner from comment #5)
> > bergner@kubota:COBOL$ ./a.out
> > Hello, world!
> > Segmentation fault (core dumped)
>
> The return address at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
--- Comment #5 from Peter Bergner ---
So some AIX documentation specifies a language tag value (7) for Cobol in the
traceback table:
https://www.ibm.com/docs/en/aix/7.1?topic=ops-tbtag-pseudo-op
...so this fixes the ICE:
diff --git a/gcc/co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
--- Comment #6 from Peter Bergner ---
(In reply to Peter Bergner from comment #5)
> bergner@kubota:COBOL$ ./a.out
> Hello, world!
> Segmentation fault (core dumped)
The return address at the beginning of main ends up not being the address we
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
Peter Bergner changed:
What|Removed |Added
CC||doko at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
--- Comment #3 from Peter Bergner ---
I've recreated it too. I'll have someone on my team have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117674
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117674
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #11 from Peter Bergner ---
(In reply to Peter Bergner from comment #10)
> Similarly for -O2 -m64 -mcpu={power6,power5,power4,...}, LRA goes into a
> infinite loop.
Adding a little info for Vlad. The insn LRA is transforming is:
(in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #10 from Peter Bergner ---
(In reply to Peter Bergner from comment #9)
> extern void bar (void);
> void
> foo (_Decimal32 *dst, _Decimal32 src)
> {
> bar ();
> *dst = src;
> }
I'll note if I configure my gcc as a --target=powerp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #9 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Peter Bergner from comment #6)
> > (In reply to Segher Boessenkool from comment #5)
> > > I cannot get the testcase to fail at all. Please give
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Summary|[15 Regression] ICE: in |[15 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #4 from Peter Bergner ---
So this isn't 32-bit specific. powerpc-linux defaults to -mcpu=601 and
powerpc64-linux defaults to -mcpu=power4. Using -mcpu=power4 with either -m32
or -m64, we do not ICE. When using -mcpu=601 with eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2025-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
Peter Bergner changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118502
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118533
Peter Bergner changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #11 from Peter Bergner ---
(In reply to Sam James from comment #8)
> I'm still seeing this, but I think it's an actual bug, not a testism.
I will restate that Surya's IRA commit is a correct fix, so the
missed-optimization bug lies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #8 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #7)
> So, what happened with this PR? I see the patch has been reviewed and small
> nits requested to be changed, but then I don't see it being committed nor
> repost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
--- Comment #12 from Peter Bergner ---
(In reply to Janis Johnson from comment #4)
> The tests also fail on powerpc64-linux, although the first one gets the same
> error with and without optimization.
>
> elm3c105% cat 43374-1.c
> int func(_Deci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #4)
> (In reply to Peter Bergner from comment #3)
>> There look to be more effective target tests we need a similar fix for.
>
> Yes, there is PR113535 opened tracking fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #3 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> gcc.dg/vect/pr112325.c
This is compiling some explict vector code, so I wouldn't expect this to run on
power4, but it does. I would have thought the dg-requ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #2 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> gcc.target/powerpc/pr92488.c
This is a DFP runtime test and it seems for pre-power6 (ie, pre DFP hardware
insns), we get a precision difference with power6 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
--- Comment #1 from Peter Bergner ---
(In reply to Michael Meissner from comment #0)
> I build a GCC trunk on the gcc110 cfarm system. I got the following
> failures when I built GCC without using --with-cpu=. These failures
> are gone if I us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #2 from Peter Bergner ---
With the scalar version, we have in the fwprop dump:
propagating insn 5 into insn 6, replacing:
(set (reg:DI 120 [ var ])
(mem/c:DI (reg/f:DI 119) [1 var+0 S8 A64]))
successfully matched this instructio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-11-20
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
Bug ID: 117718
Summary: Inefficient address computation for d-form vector
loads
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117444
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117444
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-11-05
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117444
--- Comment #1 from Peter Bergner ---
Well that patch disables jump tables for -O0 and the test case assumes they'll
be generated. The test case is not compiled with any optimization levels, so
we could either explicitly add -O1 or -fjump-table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #11 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Peter Bergner from comment #4)
> > These die because the struct we're using to check the alignment of uses long
> > double as the "big" aligne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #13 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> (In reply to Peter Bergner from comment #10)
> > void
> > stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> > {
> > #if defined(HAVE_SETRLIMIT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #10 from Peter Bergner ---
(In reply to Andreas Schwab from comment #8)
> See PR c++/49756. It uses 64MB, not unlimited.
[bergner@ltcden2-lp1 ICE]$ ulimit -s 8192
[bergner@ltcden2-lp1 ICE]$ /opt/gcc-nightly/trunk/bin/gcc -S test.c
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #7 from Peter Bergner ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
Peter Bergner changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #1 from Peter Bergner ---
Created attachment 59434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59434&action=edit
gzip'd test case that segvs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
Bug ID: 117291
Summary: Simple but large test case uses up over 8M of stack
and hits SEGV
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
--- Comment #9 from Peter Bergner ---
(In reply to munroesj52 from comment #8)
> looks good, thanks.
So everything that was asked for is now implemented so we can close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #9 from Peter Bergner ---
(In reply to Jonathan Wakely from comment #8)
> Could it be the call to __builtin_cpu_supports("darn") which happens in the
> std::random_device x("default") initialization in test01?!
>
> Could that system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546
Bug ID: 116546
Summary: Missed optimization of redundant comparison
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #10 from Peter Bergner ---
Fixed on trunk with a slightly different (but functionally identical) patch
than posted above. I'll let it sit there for a few days to ensure we didn't
expose any other issues with the patch before backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #6 from Peter Bergner ---
(In reply to Peter Bergner from comment #5)
> I'm testing a fix.
>
> Our P8 swap optimization has some special handling for TImode usage. The
> __atomic_compare_exchange call introduces a PTImode use and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Peter Berg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #4 from Peter Bergner ---
Here's a C testcase that shows the same problem:
bergner@ltcden2-lp1:BUG$ cat bug.c
#include
#include
typedef union {
struct {
uint64_t a;
uint64_t b;
} t;
__uint128_t raw_data;
} Value;
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #2 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-08-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
--- Comment #2 from Peter Bergner ---
(In reply to Kewen Lin from comment #0)
> I think not having TARGET_P10_VECTOR isn't intentional, as we still allow
> -mno-vsx with -mcpu=power10. We have TARGET_P8_VECTOR and TARGET_P9_VECTOR
> for P8 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #18 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #17)
> Does it also work if you spell the option name correctly? All unknown
> configure
> options are always accepted silently.
Sorry, it was a typo here, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #16 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #14)
> So, can you explain how could libquadmath build at all in such
> configurations?
> __float128 type is supported and not TFmode?
> Is that because it is KFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> Yup, that sounds eminently plausible :-) Thanks.
For the given that error message, yes, it seems plausible. But I don't know
how an error like that can b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #4)
> Actually not that, but
> s/int g;/short int g;/
Yes, this does not abort with either -m32 or -m64 for me. The other suggestion
still aborted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
--- Comment #2 from Peter Bergner ---
It's the same code on powerpc64le-linux and it passes, so the uninitialized
stack space we load must be zero?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116061
Peter Bergner changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
--- Comment #13 from Peter Bergner ---
(In reply to Peter Bergner from comment #11)
> Fixed on trunk. I'll push the backports after a little burn-in time on
> trunk.
All of Bill's CI testers were green wrt this test case, so I've started
backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548
Peter Bergner changed:
What|Removed |Added
Known to fail|12.0|
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115988
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
Reso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Peter Bergner changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #2 from Peter Bergner ---
(In reply to Kewen Lin from comment #0)
> As Peter found in the PR115688, there isn't a warning for:
>
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
> return 0;
> }
>
> It's expecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> (In reply to Peter Bergner from comment #4)
> > That said, how does your patch handle the following test case?
> >
> > long __attribute__ ((target ("no-alt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #4 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> // 32 bit has altivec_abi unset, so that's why it doesn't ICE at -m64.
Ah yes, that does explain the difference between 32-bit and 64-bit!
...and that means it ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-06-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Bug ID: 115688
Summary: ICE on simple test case from r15-703-gb390b011569635
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #11 from Peter Bergner ---
(In reply to Kewen Lin from comment #10)
> (In reply to Peter Bergner from comment #9)
> > (In reply to Kewen Lin from comment #8)
> > > Should be fixed on trunk, it's not a regression, but we probably want
1 - 100 of 563 matches
Mail list logo
