https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #21 from Andrew Pinski ---
(In reply to dave.anglin from comment #20)
> Both -fno-strict-aliasing and -fno-schedule-insns2 applied to
> compiler_visit_expr()
> work around issue.
The other option to try is -fstack-reuse=none. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #22 from John David Anglin ---
Created attachment 56542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56542&action=edit
Preprocessed source and assembly files for Python/compile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #23 from Sam James ---
(In reply to Andrew Pinski from comment #21)
> The other option to try is -fstack-reuse=none. There is definitely known
> issues with the code that coalesces stack variables together too (see PR
> 111843 for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #24 from dave.anglin at bell dot net ---
On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #23 from Sam James ---
> (In reply to Andrew Pinski from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #25 from Sam James ---
I am having the same thoughts. It would not be the first time Python had
something dubious, like...
* https://wiki.gentoo.org/wiki/Project:Python/Strict_aliasing ->
https://www.python.org/dev/peps/pep-3123/
* h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #26 from Jeffrey A. Law ---
As a compiler junkie, I tend to think compiler first until I can prove it
otherwise. I wouldn't get too hung up on aliasing issues and such at this
point.
Do we already have a dump for the key function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #27 from dave.anglin at bell dot net ---
On 2023-11-08 7:00 p.m., John David Anglin wrote:
> On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>>
>> --- Comment #23 from S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #28 from dave.anglin at bell dot net ---
On 2023-11-08 7:07 p.m., law at gcc dot gnu.org wrote:
> Do we already have a dump for the key function? Presumably f-m-o doesn't
> trigger*that* much. And if this is triggering w/o LTO we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #2 from Andrew Pinski ---
Created attachment 56543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56543&action=edit
little more reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Andrew Pinski changed:
What|Removed |Added
Attachment #56543|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #5 from Andrew Pinski ---
Note the 2 tmp variables need to be named the same. Otherwise fre won't merge
the 2 ".DEFERRED_INIT (1, 2, &"tmp"[0]);" .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
--- Comment #8 from Andrew Pinski ---
>From the dup:
The only difference between stage2-gcc/i386-expand.o and
stage3-gcc/i386-expand.o is
```
< ./stage2-gcc/i386-expand.o: file format elf64-x86-64
---
> ./stage3-gcc/i386-expand.o: file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Sam James changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Summa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
Bug ID: 112450
Summary: RVV vectorization ICE in vect_get_loop_mask, at
tree-vect-loop.cc:11037
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110936
Nathaniel Shead changed:
What|Removed |Added
CC||nathanieloshead at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110936
--- Comment #4 from Johel Ernesto Guerrero Peña ---
They talk about `-fno-delete-null-pointer-checks` in BUG71962.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112451
Bug ID: 112451
Summary: gcc_build was not updated to checkout via git
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112451
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #9 from Maciej W. Rozycki ---
Hmm, the host check for `__frexpieee128' in gcc/ will surely not do
what's intended: even if the host is `powerpc*-*-linux*', the target
will often be something else and vice versa (libgm2's host is GCC'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112452
Bug ID: 112452
Summary: : operator|(_Range&& __r, _Self&& __self)
should return decltype(auto)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
--- Comment #1 from Hongtao.liu ---
The below can fix that, there's typo for 2 splitters.
@@ -17082,7 +17082,7 @@ (define_insn_and_split "*avx2_pcmp3_4"
(match_dup 4))]
UNSPEC_BLENDV))]
{
- if (INTVAL (operands[5])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #1 from JuzheZhong ---
Oh. I see we have cond_xxx pattern for VLS modes.
like V64HImdoe. But we don't support partial vectorization for VLS modes.
VLS modes are supposed to used as SIMD GNU vectorization.
As long as COND_XXX is en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112453
Bug ID: 112453
Summary: : __take_of_repeat_view/__drop_of_repeat_view
should forwards __r._M_value
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #2 from JuzheZhong ---
if (loop_vinfo
&& LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
&& mask_out_inactive)
{
if (cond_len_fn != IFN_LAST
&& direct_internal_fn_supported_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112383
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807
--- Comment #13 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:e39b3e02c27bd771a07e385f9672ecf1a45ced77
commit r14-5260-ge39b3e02c27bd771a07e385f9672ecf1a45ced77
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111893
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108026
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
Andrew Pinski changed:
What|Removed |Added
CC||xmh970252187 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112423
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
--- Comment #3 from Andrew Pinski ---
Note clang has a decent error message for `0xe+100` but has just as bad one for
`123_to.`
Full testcase for a few:
```
int a = 0xe+100;
int b = 123_to.;
int c = 0xe_100e+10;
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109843
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #4 from LI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #2 from Zdenek Sojka ---
Created attachment 56545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56545&action=edit
testcase failing just at -O1
$ x86_64-pc-linux-gnu-gcc -O testcase2.c
testcase2.c: In function 'foo':
testcase2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #5 from LIU Hao ---
(In reply to LIU Hao from comment #4)
> lzcnt rax, rdx
> testrdx, rdx
> mov edx, 64
> cmove rax, rdx
There is actually another missed optimization here. LZCNT sets CF if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109906
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
La
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789
Andrew Pinski changed:
What|Removed |Added
Summary|__builtin_(add|mul)_overflo |__builtin_(add|mul)_overflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #10 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 54994 [details]
> gcc14-pr52339.patch
>
> Untested fix.
I think this might fix PR 108789 too ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
--- Comment #5 from Li Pan ---
(In reply to Li Pan from comment #4)
> (In reply to Richard Biener from comment #3)
> > Ah, yes, for lrint we have the builtins - I just looked for lceil here. So
> > yeah, where there are DEF_EXT_LIB_FLOATN_NX_BU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #5 from post+gcc at ralfj dot de ---
> See
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
That's unrelated. That's about whether operation on signaling NaNs can trap. I
am asking when operations can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #6 from post+gcc at ralfj dot de ---
Hm, OTOH the C standard says
> The expressions 1×x, x/1, and x are equivalent (on IEC 60559 machines, among
others).
So, it seems like when they say "The + ,- , * , and / operators provide the IE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
Bug ID: 112454
Summary: csinc (csel is though) is not being used when there is
matches twice
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #7 from post+gcc at ralfj dot de ---
I guess the idea is that by passing a signaling NaN to a float operation, I am
already entering unspecified behavior, so it's okay for that float operation to
violate its usual contract and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #10 from Thomas Schwinge ---
In addition to what Maciej said (..., and similarly, I don't have any proper
knowledge about PowerPC details):
(In reply to Gaius Mulley from comment #6)
> Created attachment 56522 [details]
> Proposed f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #3 from JuzheZhong ---
Add cond_len pattern for VLS mode can work around this bug.
Even though COND_LEN_xxx is not eventually
Testing a patch to fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
101 - 156 of 156 matches
Mail list logo
