https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #15 from Sam James ---
at what point can we consider a revert for 14 and revisit for 15? there's a few
things which keep cropping up and I don't want to be ignoring other regressions
because I'm assuming it's the same as this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
--- Comment #2 from Tamar Christina ---
looks like get_virtual_phi returned NULL. but this loop shouldn't have
vectorized. The submitted fix for PR113588 "fixes" it too by not allowing it
to be vectorized.
Such loops need to be handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
--- Comment #1 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
Andrew Pinski changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #26 from Tamar Christina ---
Ah great, just checking it wasn't left unattended :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> Just to put it somewhere I ran dwlocstat on cc1plus before/after the
> offending change and it looks almost the same. We go from
>
> cov%samples cumul
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637
--- Comment #2 from Andrew Pinski ---
&& (INTEGRAL_TYPE_P (TREE_TYPE (loc))
|| POINTER_TYPE_P (TREE_TYPE (loc)))
&& (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (loc)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113651
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Kewen Lin changed:
What|Removed |Added
Summary|Failed bootstrap on ppc |[14 regression] Failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #3 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #2)
> Actually it is caused by option -funsafe-math-optimizations but not
> -mavx10.1.
>
> Before my commit, while using option:
>
> -frounding-math -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #2 from Haochen Jiang ---
Actually it is caused by option -funsafe-math-optimizations but not -mavx10.1.
Before my commit, while using option:
-frounding-math -O3 -mavx512fp16 -mavx512vl -funsafe-math-optimizations
It will also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112551
--- Comment #2 from Sam James ---
Writeup about this:
https://hacks.mozilla.org/2024/01/option-soup-the-subtle-pitfalls-of-combining-compiler-flags/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #11 from Kewen Lin ---
In gcc, lfiwzx is guarded with TARGET_LFIWZX => TARGET_POPCNTD (ISA2.06), while
-mvsx will guarantee TARGET_POPCNTD (ISA_2_6_MASKS_SERVER) set, so it considers
lfiwzx is supported. IMHO the underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #10 from Sam James ---
(In reality, I think it is a regression, given:
a) it regresses non-release checking (which we sometimes use even for released
versions, it's opt-in though);
b) it blocks further testing with GCC 14
but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Kewen Lin changed:
What|Removed |Added
Summary|[14 regression] Failed |Failed bootstrap on ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #3)
> I will try bisect.
Most likely r11-5094-gafa6adbd6c83ee or r11-4987-g602c6cfc79ce4a or
r11-4986-ga1fdc16da34118 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113654
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Add -fno-ivopts also fixes the issue ...
Note -fstack-reuse=none does NOT fix the issue so it is NOT the same as those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594
Nathaniel Shead changed:
What|Removed |Added
Target Milestone|--- |14.0
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 107594, which changed state.
Bug 107594 Summary: ICE in module_state, at cp/module.cc:3810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:a88e08feb8367898e0562622517d33f95684a03d
commit r14-8513-ga88e08feb8367898e0562622517d33f95684a03d
Author: Nathaniel Shead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #8 from Andrew Pinski ---
So t-float128 has this line:
# Build the emulator without ISA 3.0 hardware support.
FP128_CFLAGS_SW = -Wno-type-limits -mvsx -mfloat128 \
...
Which gets added to some of the libgcc object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #25 from Hongtao Liu ---
(In reply to Tamar Christina from comment #24)
> Just to avoid confusion, are you still working on this one Richi?
I'm working on a patch to add a target hook as #c18 mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #7 from Kewen Lin ---
oops, I meant --enable-checking rather than --checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #6 from Kewen Lin ---
I think this is related to r10-580-ge154242724b084 and this failure is expected
and a use error.
With it applied, we don't always pass -many to assembler with CHECKING_P
enabled. Actually compilers (gcc-13,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #1 from Haochen Jiang ---
>From the first glance, it seems that the op here is wrongly interpreted.
Investigating why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113666
Bug ID: 113666
Summary: RISC-V: Cost model test regression due to recent
middle-end loop vectorizer changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112840
--- Comment #3 from Matheus Afonso Martins Moreira ---
(In reply to uecker from comment #2)
> I would go for a more generic feature where one can specify some invariant /
> condition that needs be true when a member of a struct / union is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |ipa
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813
--- Comment #5 from Lennox Ho ---
Thanks for the insight.
I think the only potential blocker would be CreateSymbolicLinkW requires at
least Vista/WinSer2008.
I'm not able to figure out MinGW (or at least mingw-w64)'s OS requirements.
I might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
--- Comment #2 from Lennox Ho ---
Created attachment 57257
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57257=edit
hard_link_count patch for Windows
I've put together a patch (attached).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
--- Comment #1 from Christoph Rüthing ---
Note, that the volatile variables are just there to provide a minimal example
and not have the entire loop optimized away. In the origian implementation I
deduced this minimal example from, there was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
Bug ID: 113665
Summary: Regular for Loop results in Endless Loop with -O2
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
--- Comment #3 from Andrew Pinski ---
https://github.com/python/cpython/issues/96821 is the issue to re-enable
strict-overflow ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
--- Comment #2 from Stefan Krah ---
Thanks for the explanation! I agree that one should not rely on
-fno-strict-overflow. In this case, my project is "vendored" in CPython and
they compile everything with -fno-strict-overflow, so it's out of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
--- Comment #6 from Patrick Palka ---
Indeed, looks like we implement CWG408 since r158075.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
--- Comment #1 from Andrew Pinski ---
-fno-strict-overflow turns on -fwrapv-pointer which allows pointers to wrap
which means if s was non-null, then `s+1` can be still a null pointer ...
And then we go and prop null into dot and s is equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
Bug ID: 113664
Summary: False positive warnings with -fno-strict-overflow
(-Warray-bounds, -Wstringop-overflow)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
--- Comment #5 from Andrew Pinski ---
(In reply to Patrick Palka from comment #4)
> This seems to be the variable template version of
> https://cplusplus.github.io/CWG/issues/408.html, the resolution of which
> predated variable templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
--- Comment #4 from Daniel Berrange ---
(In reply to Jakub Jelinek from comment #3)
> Obviously using __has_builtin is much better than using the really badly
> designed __has_feature/__has_extension.
> That said, wcs{chr,cmp,len,ncmp} and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
--- Comment #4 from Patrick Palka ---
This seems to be the variable template version of
https://cplusplus.github.io/CWG/issues/408.html, the resolution of which
predated variable templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Jakub Jelinek changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #5 from Christopher Fore ---
I've managed to get the args down to the following as well:
gcc -mcpu=7450 -O0 -ftree-coalesce-vars -mvsx -c _kf_to_sd.i
-mcpu=7450 seems to be (one of) the root causes along with
-ftree-coalesce-vars.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79459
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813
--- Comment #4 from Jonathan Wakely ---
For example, filesystem::is_symlink doesn't work on Windows, and
create_symlink, and create_directory_symlink etc. etc.
So we could make equivalent work, but that's just a small part of what's
missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813
--- Comment #3 from Jonathan Wakely ---
Nobody has even tried to implement symlink support, so I have no idea if there
are any blocking issues. It's probably just a case of somebody doing the work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #18 from Robin Dapp ---
Hehe no it doesn't make sense... I wrongly read a v2 as a v1. Please
disregard the last message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
Rama Malladi changed:
What|Removed |Added
CC||rvmallad at amazon dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
--- Comment #1 from Lennox Ho ---
Created attachment 57256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57256=edit
repro.cpp
Added minimal repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #24 from Tamar Christina ---
Just to avoid confusion, are you still working on this one Richi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
Bug ID: 113663
Summary: [MinGW] std::filesystem::hard_link_count always
returns 1
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338
--- Comment #3 from anlauf at gcc dot gnu.org ---
I just tried the example in comment#0 with ifort/ifx and noticed that it
may be over-simplified: the contained procedure is internal and thus not
visible to the external C code. The BIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
--- Comment #3 from Andrew Pinski ---
Add -fno-ivopts also fixes the issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
--- Comment #2 from Viktor Ostashevskyi ---
Adding --param=ranger-recompute-depth=1 or --param=ranger-recompute-depth=2
also fixes the issue. Higher values behave wrongly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #4 from Christopher Fore ---
Created attachment 57255
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57255=edit
minimized preprocessed file
Here's the minimized file (still errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113544
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813
Lennox Ho changed:
What|Removed |Added
CC||lennoxhoe at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113544
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:77d3fb39c62558838c0e905df717903b5393dfc9
commit r14-8502-g77d3fb39c62558838c0e905df717903b5393dfc9
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
Bug ID: 113662
Summary: [13/14 Regression] Wrong code for std::sort with fancy
pointer
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
--- Comment #3 from Tamar Christina ---
arg wrong one again. anyway, this is a duplicate
*** This bug has been marked as a duplicate of bug 113588 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
--- Comment #2 from Tamar Christina ---
*** This bug has been marked as a duplicate of bug 113576 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
Bug ID: 113661
Summary: [14 Regression] xalancbmk miscompiled on aarch64 since
r14-7194-g6cb155a6cf3142
Product: gcc
Version: 14.0
Status: UNCONFIRMED
six
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
--- Comment #6 from Rich Felker ---
I'm aware of the allowance to accept "other forms". It's unfortunately
underspecified (does the implementation need to be specific in what forms?
document them per the normal rules for implementation-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #21 from Richard Sandiford ---
(In reply to Alex Coplan from comment #13)
> The problem seems to be this code in aarch64_process_components:
>
> while (regno != last_regno)
> {
> bool frame_related_p =
posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
--- Comment #2 from Andrew Pinski ---
Newer libc++ does the "correct" thing even:
https://github.com/llvm/llvm-project/blob/430c1fd50d774dc30a9628bcf60ce243f74ff376/libcxx/include/__string/constexpr_c_functions.h#L121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
Rich Felker changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
--- Comment #1 from Andrew Pinski ---
Hmm, Most other conditional uses of builtin use __has_builtins instead.
Interesting one projection just conditionalized it on
cxx_constexpr_string_builtins .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #3 from Erhard F. ---
(In reply to Christopher Fore from comment #0)
> Created attachment 57251 [details]
> original preprocessed file
>
> Steps to reproduce:
> 1. Attempt to build GCC 14 (latest snapshot attempted is Gentoo's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Bug ID: 113658
Summary: GCC 14 has incomplete impl for declared feature
"cxx_constexpr_string_builtins"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
--- Comment #3 from Andrew Pinski ---
Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c24 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83222
Andrew Pinski changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
YunQiang Su changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
--- Comment #2 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:8e84b4fad149b9b9544c7b1fc61a45cf6139176e
commit r14-8500-g8e84b4fad149b9b9544c7b1fc61a45cf6139176e
Author: YunQiang Su
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #17 from Robin Dapp ---
Grasping for straws by blaming qemu ;)
At some point we do the vector shift
vsll.vv v1,v2,v2,v0.t
but the mask v0 is all zeros:
gdb:
b = {0 }
According to the mask-undisturbed policy set before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
--- Comment #1 from YunQiang Su ---
Thank for your report. It's due to a typo
I will fix it now.
hms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:bad991a1c5960e90c4686a9362a1258ef29e195b
commit r14-8499-gbad991a1c5960e90c4686a9362a1258ef29e195b
Author: Matthieu Longo
1 - 100 of 163 matches
Mail list logo
