https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #7 from Richard Biener ---
(In reply to Robin Dapp from comment #6)
> Created attachment 55902 [details]
> Tentative
>
> You're referring to the case where we have init = -0.0, the condition is
> false and we end up wrongly doing -0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #18 from Jan Wassenberg ---
Ah, got it. We'll change the pragma to ",htm" as you suggest. Thank you :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421
Bug ID: 111421
Summary: constexpr not working with array subscript
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Actually we should transform it into
> ((convert)zero_one_valued_p) & (a != 0)
>
> Or ^1 for the == 0 case ...
>
> This should allow for better code I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #7 from Andrew Pinski ---
Actually we should transform it into
((convert)zero_one_valued_p) & (a != 0)
Or ^1 for the == 0 case ...
This should allow for better code I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.0|13.3
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110665
--- Comment #3 from Lehua Ding ---
Fixed by the commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fdd59c0f73e9e681cd5f4d0eee2dd58d60d8dbe1
with compiler option --param=riscv-vector-abi.
Confirmed after support riscv-vector-abi in default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #17 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #16)
> Interesting, the following works for me:
>
> % /usr/bin/c++ -O1 -mcpu=power8 -mno-htm -flto=auto -c skeleton_test.cc
Yeah, the suggestion on an extra option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111381
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:68cb873fd360dbb64f2a6dfb28e79399ff99d07d
commit r14-4008-g68cb873fd360dbb64f2a6dfb28e79399ff99d07d
Author: Lehua Ding
Date: Thu Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998
--- Comment #11 from Andrew Pinski ---
https://reviews.llvm.org/D33305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
AK changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #4 from AK ---
good catch. By mistake i built at -O0, i wanted to build at -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #3 from Andrew Pinski ---
Or just this function is huge for -O0 in which case riscv does not have a good
code model for that case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #2 from Andrew Pinski ---
This might be a binutils bug ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #1 from AK ---
I got this error while building clang (ninja clang) on a riscv machine.
root@lpi4a:~# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target: riscv64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
Bug ID: 111420
Summary: relocation truncated to fit: R_RISCV_JAL against
`.L12287'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #4 from Andrew Pinski ---
What we had before in GCC 13:
# RANGE [irange] unsigned short [0, 1] NONZERO 0x1
d.3_19 = (unsigned short) _3;
_21 = -d.3_19;
_22 = (short intD.17) _21;
_6 = (short intD.17) b.0_1;
_7 = _6 & _22;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #3 from Andrew Pinski ---
So this was fixed by accident via r14-3721-ge6bcf83989478348428c732 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
--- Comment #11 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-September/059756.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111419
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2023-09-14
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #9 from AK ---
i think it is okay to close this bug as this doesn't seem to be related to gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #7 from Richard Sandiford ---
It's proving difficult to generate a reliable reproducer from
pure C code, due to the ways in which we handle out-of-range
offsets. But FWIW, here's one that uses the RTL frontend,
compiled with -O -fdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #6 from Richard Sandiford ---
Thanks, I can reproduce it now. I had been trying with tip of trunk, but it
seems to have gone latent after 9ea74d235c7e7816b996a17c61288f02ef767985.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111419
Bug ID: 111419
Summary: Eager instantiation of function return type in concept
causes compilation error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-09-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #5 from Sam James ---
(In reply to Richard Sandiford from comment #4)
> I'm struggling to reproduce this. Do you know what your -mcpu=native expands
> to?
# arch=native; for t in param target; do cmd="gcc -Q -O2 -mcpu=$arch
--help=$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
--- Comment #3 from Martin Jansa ---
Reproduced with:
13.2.1 20230914 (revision 9cddebd822aeff9b7c0e9951909d5ec96c959e4f)
and
14.0.0 20230914 (experimental) (revision
8517317ce8e9fbea0b4c7a8f87a86d07d95dc8c7)
as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
--- Comment #3 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630358.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362
--- Comment #2 from Zdenek Sojka ---
Thank you the fix; the testcase is still failing with a bit different flags
though:
Adding -fno-dce -fschedule-insns:
$ riscv64-unknown-linux-gnu-gcc -O -fno-tree-ch
--param=max-completely-peel-times=0 -mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #6 from Robin Dapp ---
Created attachment 55902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55902&action=edit
Tentative
You're referring to the case where we have init = -0.0, the condition is false
and we end up wrongly do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #4 from rsandifo at gcc dot gnu.org
---
I'm struggling to reproduce this. Do you know what your -mcpu=native expands
to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415
--- Comment #1 from Andrew Pinski ---
I am pretty sure there is a dup of this bug already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111417
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
Andrew Pinski changed:
What|Removed |Added
CC||ross at burtonini dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
--- Comment #1 from Martin Jansa ---
https://github.com/csmith-project/creduce
reduced my test case to:
typedef a;
typedef struct {
short b __attribute__((aligned(8)))
} c;
typedef struct {
short d __attribute__((aligned(8)))
} e;
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #16 from Mathieu Malaterre ---
Interesting, the following works for me:
% /usr/bin/c++ -O1 -mcpu=power8 -mno-htm -flto=auto -c skeleton_test.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I see what I did wrong.
> Looks like I need to check to make sure the integer_onep is a non vector.
That is:
diff --git a/gcc/match.pd b/gcc/match.pd
index 07ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #18 from Andrew Pinski ---
I think the only thing left is supporting floating point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #17 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:5e4a248b03f01f422b0dbc9e1464eb6c2f2bafc6
commit r14-3995-g5e4a248b03f01f422b0dbc9e1464eb6c2f2bafc6
Author: Andrew Pinski
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #15 from Mathieu Malaterre ---
For some reason the no-htm flag does not seems to work in my case:
% /usr/bin/c++ -O1 -mcpu=power8 -flto=auto -c skeleton_test.cc
skeleton_test.cc: In member function 'TestFloorLog2::operator() >(int,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272
--- Comment #5 from Marek Polacek ---
(In reply to Paul Keir from comment #4)
> I believe P2448R2 would only allow the code, without the static_assert.
> Explicitly calling `test()`, `Jam::Jam()` and then `Jam::ft()` here would
> mean evaluating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #6 from Mathieu Malaterre ---
Code in #c4 and #c5 are bogus. They also fails with g++-12. Let me start my
cvise machinery over again (may take some time).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:27fce25cc07f7efe11db05eb2fe74a465c41475f
commit r11-11008-g27fce25cc07f7efe11db05eb2fe74a465c41475f
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:eba46f1137683b6f92ea6f95ed84e3e5cfc42377
commit r12-9877-geba46f1137683b6f92ea6f95ed84e3e5cfc42377
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:7b0abd4a8ee9d2057febe443de67009dcdfe7574
commit r13-7817-g7b0abd4a8ee9d2057febe443de67009dcdfe7574
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:557a858f2ead4ae8b64b157d7fd33830a81646d5
commit r14-3992-g557a858f2ead4ae8b64b157d7fd33830a81646d5
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
Bug ID: 111418
Summary: ICE with the CVE-2023-4039 patches applied
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111417
Bug ID: 111417
Summary: Incorrect optimization when linker-generated symbols
are used
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Bug ID: 111416
Summary: [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent
Load can be Reordered before Store of RMW when v7 and
v7 Implementations are Mixed
Product: gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415
Bug ID: 111415
Summary: False positive array-bounds warning with -O3
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #15 from John Soo ---
Just for some context on what limit is hit: under man sysconf you will find a
description of ARG_MAX
(https://www.man7.org/linux/man-pages/man3/sysconf.3.html)
> ARG_MAX - _SC_ARG_MAX
> The maximum length of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
Richard Biener changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9ea74d235c7e7816b996a17c61288f02ef767985
commit r14-3982-g9ea74d235c7e7816b996a17c61288f02ef767985
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
Bug ID: 111414
Summary: ICE in verify_gimple failed since
r14-3719-gb34f3736356
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #8 from Franz Sirl ---
I see a similar profiledbootstrap failing with x86_64-linux-gnu:
/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111413
Bug ID: 111413
Summary: libgomp >= 13 segfault on loading if environ is NULL
Product: gcc
Version: og13 (devel/omp/gcc-13)
Status: UNCONFIRMED
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406
--- Comment #3 from Richard Biener ---
These are only used in the install targets which when bootstrapped will have
used GCC from earlier stages. When building cross compilers we require GCC as
host compiler.
So I think this isn't an issue unl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #41 from richard.sandiford at arm dot com ---
"juzhe.zhong at rivai dot ai" writes:
> I try this following code to set ELSE_VALUE:
>
> static tree
> riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111412
Bug ID: 111412
Summary: [release/gcc13 bug]RISC-V:ICE in phase 6 of vsetvl
pass
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #40 from JuzheZhong ---
I try this following code to set ELSE_VALUE:
static tree
riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
tree *ops)
{
if (riscv_v_ext_mode_p (TYPE_MODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111395
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:53ad1bd520759580b9a5cc590a81a1a30b9e2e28
commit r14-3979-g53ad1bd520759580b9a5cc590a81a1a30b9e2e28
Author: Juzhe-Zhong
Date: Thu Sep 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #10 from Richard Biener ---
But this stmt isn't the issue, BB7 is
[local count: 118111600]:
# _31 = PHI
_4 = (unsigned char) _31;
_6 = (int) a.8_28;
j_22 = (short int) _4;
_33 = _31 & 255;
if (_33 > 11)
and that doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #9 from Richard Biener ---
Created attachment 55898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55898&action=edit
alternative patch for simple_dce_from_worklist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #8 from Richard Biener ---
(In reply to Andrew Pinski from comment #7)
> Created attachment 55892 [details]
> version of using simple_dce_from_worklist in forwprop
>
> This is a version of using simple_dce_from_worklist in forwprop
75 matches
Mail list logo
