https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #40 from Jakub Jelinek ---
For unsigned _BitInt(4) or unsigned _BitInt(2) we mask it whenever loading from
memory or function argument or whatever other ABI specific spot (and also when
storing because that is how RTL expects it; bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766
--- Comment #3 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9ec08782b45869b33fec2a8772c25118221208e3
commit r14-8875-g9ec08782b45869b33fec2a8772c25118221208e3
Author: Pan Li
Date: Wed Feb 7 16:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #4 from Andrew Pinski ---
(In reply to martin from comment #3)
> typedef character(kind=1) struct
> character(kind=1)[1:slen.1][1:slen.1];
> pstr.2 = 0B;
> slen.1 = 0;
Maybe the order here. slen.1 should be set to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #3 from martin ---
Thanks for the patch, it does the job. But if I compile with
"gfortran-14 -fopenmp -Wuninitialized"
then I obtain
20 | out = concat_f('0123456 ', some()) // ' abc'
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #1 from Andrew Pinski ---
static integer(kind=8) slen.1;
inside
void check (integer(kind=4) & restrict i)
pstr.2 = 0B;
slen.1 = 0;
concat_f (&pstr.2, &slen.1, &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
That is it used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
--- Comment #6 from Sam James ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
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=113576
--- Comment #39 from Hongtao Liu ---
> > the question is whether that matches the semantics of GIMPLE (the padding
> > is inverted, too), whether it invokes undefined behavior (don't do it - it
> > seems for people using intrinsics that's what i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
Bug ID: 113822
Summary: aarch64_evpc_reencode could/should use
new_shrunk_vector instead of manually doing it
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
--- Comment #3 from Huaqi ---
(In reply to Andrew Pinski from comment #2)
> Yes this is where shrink wrapping incorrects incorrectly with
> riscv_zcmp_can_use_popretz optimization. Basically popretz should be
> disabled for shrink wrapped functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #14 from Matthias Klose ---
the proposed patch also fixes the arm-linux-gnueabi build (armv5t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #38 from Hongtao Liu ---
> I think we should also mask off the upper bits of variable mask?
>
> notl%esi
> orl %esi, %edi
> notl%edi
> andl$15, %edi
> je .L3
with -mbmi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
--- Comment #4 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
--- Comment #9 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059
--- Comment #8 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #37 from Hongtao Liu ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>
> notl%esi
> orl %esi, %edi
> cmpb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113764
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Andrew Pinski changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Bug ID: 113821
Summary: Missed optimization for final classes: expensive check
for result of dynamic cast
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #5 from anlauf at gcc dot gnu.org ---
Even worse: it's the unary minus:
print *, -someInf
pr113799.f90:5:19:
5 | print *, -someInf
| 1
Error: Arithmetic overflow at (1)
free(): invalid pointer
f951:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #4 from anlauf at gcc dot gnu.org ---
It's the simplification of minval:
program p
implicit none
real, parameter :: inf = real(z'7F80')
real, parameter :: someInf(*) = [inf, 0.]
print *, minval(-someInf)
end
pr113799.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #13 from Jonathan Wakely ---
It looks like libc++ did it for this reason:
[libc++] Fix a hard error in `contiguous_iterator`.
Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #5 from seurer at gcc dot gnu.org ---
I should note that pinned-2 also fails on powerpc64 LE.
make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-1.c execution test
FAIL: libgomp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Andrew Pinski changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
--- Comment #8 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820
Bug ID: 113820
Summary: [14 Regression] libdruntime fails to build on
arm-linux-gnueabi (armv5t)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #2)
> Reproduced with all versions I have here (14.0, 13.2, 12.3, 11.4 and 10.5).
... but passes with -fno-range-check ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #6 from Sérgio Basto ---
and any workaround to build mlt on x86_64 ,exist ?
I tried disable lto, hardening and also disable strict symbols (-Wl,-z,defs )
and still not build neither in koji nor in my machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #12 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #10)
> When Jose reported this issue in Chromium I pushed back on fixing on our
> side because I thought libstdc++ had the same issue. But this is a distinct
> issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 57354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57354&action=edit
Tentative partial patch
This appears to fix the malloc size for character arrays, but not for
alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #11 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #8)
> There's currently no simple and blessed route for consumers to convert
> raw-or-fancy-pointer input types to raw pointers.
I disagree, std::to_address does e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #10 from Peter Kasting ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Created attachment 56905 [details]
> > testcase which shows libc++ and libstdc++ difference
> >
> > with libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 56905 [details]
> testcase which shows libc++ and libstdc++ difference
>
> with libstdc++, both GCC and clang reject this.
> with libc++, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #5 from Jonathan Wakely ---
https://gcc.gnu.org/pipermail/gcc-patches/2016-January/439448.html described
the reason for the current approach.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #4 from Jonathan Wakely ---
And we have the same pattern in include/c_global/cmath and
include/bits/std_abs.h so I'm also very reluctant to change just one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #3 from Jonathan Wakely ---
(In reply to John David Anglin from comment #0)
> stdlib.h is fixed on this target. The #include_next pulled stdlib.h
> from /usr/include instead of ./prev-gcc/include-fixed/stdlib.h.
Why did that happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
--- Comment #5 from Andrew Pinski ---
*** Bug 113819 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113819
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113818
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-07
Ever confirmed|0
extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240207 (experimental) (GCC)
-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240207 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Sam James changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817
Sam James changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817
Bug ID: 113817
Summary: ice in move_early_exit_stmts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #2 from dave.anglin at bell dot net ---
On 2024-02-07 2:43 a.m., redi at gcc dot gnu.org wrote:
> Using #include definitely won't work, that would just create a cycle between
> the libstdc++ versions of stdlib.h and cstdlib, at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455
--- Comment #6 from Joseph S. Myers ---
-frounding-math is only relevant for arithmetic that occurs as-if at runtime in
the abstract machine. Conversion of constants to their type (or a type with
excess range and precision as indicated by DEC_EV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #3 from Jakub Jelinek ---
unsigned long long a[32], b[32], v[32], r[32];
void
foo (unsigned int n)
{
unsigned long long c = 0;
for (unsigned long i = 0; i < n; i += 2)
{
unsigned long j = i + 1;
b[i] = __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113816
Bug ID: 113816
Summary: Using SVE bit op reduction for SLP
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Peter Kasting changed:
What|Removed |Added
CC||pkasting at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113815
Bug ID: 113815
Summary: error: there is no applicable operator "*" for a
string type (possible regression)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113710, which changed state.
Bug 113710 Summary: [14 Regression] g++.dg/modules/hello-1 ICE: canonical types
differ for identical types since r14-8710-g65b4cba9d6a9ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814
--- Comment #1 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ff41862357ca2ea56177209a2e3b7d9c64bcfa8c
commit r14-8870-gff41862357ca2ea56177209a2e3b7d9c64bcfa8c
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
--- Comment #6 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ff41862357ca2ea56177209a2e3b7d9c64bcfa8c
commit r14-8870-gff41862357ca2ea56177209a2e3b7d9c64bcfa8c
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814
Bug ID: 113814
Summary: [modules] ICE with imported partial specialization
matching existing template-id
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113813
Bug ID: 113813
Summary: Reduction of xor/and/ior of 16 bytes can be improved
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #3 from Tobias Burnus ---
Inside omp_build_struct_sibling_lists, the following assignment:
11654 grp->grp_start = new_next;
has on the LHS the [3] array with value:
(gdb) p *grp
$147 = {grp_start = 0x771f9688, grp_en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #2 from Tobias Burnus ---
Inside: omp_build_struct_sibling_lists
new_next
= omp_accumulate_sibling_list (region_type, code,
struct_map_to_clause, *grpmap,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #14 from Andrew Pinski ---
*** Bug 113812 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Torbjorn Svensson
:
https://gcc.gnu.org/g:0cdb04629641c51498f099db04021e8de51adedb
commit r13-8297-g0cdb04629641c51498f099db04021e8de51adedb
Author: Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
--- Comment #2 from Gabriel Ravier ---
Also I guess this is a simpler minimal example:
void f(int x)
{
int(x), 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
--- Comment #1 from Andrew Pinski ---
I suspect this is a dup of bug 29834.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
Bug ID: 113812
Summary: Comma expression parsed as declaration when ambiguous
type name cast is present
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #14 from Martin Jambor ---
(In reply to rguent...@suse.de from comment #13)
> Might be also an interaction with IPA ICF in case there's a pointer to
> the pair involved?
Yes, this is exactly what seems to be happening. The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811
Bug ID: 113811
Summary: std::rotate does 64-bit signed division
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #36 from Richard Biener ---
For example with AVX512VL and the following, using -O -fgimple -mavx512vl
we get simply
notl%esi
orl %esi, %edi
cmpb$15, %dil
je .L6
typedef long v4si __a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Andrew Pinski changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113804
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Patrick Palka changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8636c538b68068cd2a4115fece531dc3e3e3a84a
commit r14-8869-g8636c538b68068cd2a4115fece531dc3e3e3a84a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810
Bug ID: 113810
Summary: A lambda with this auto style that captures this in a
member function cannot use this pointer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #8 from Richard Biener ---
It's surely a bug in the vectorizer early exit handling. I just don't know
what exactly is wrong right now ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690
--- Comment #5 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:99200573096c03120c8d4514383951acecdd5ab1
commit r14-8868-g99200573096c03120c8d4514383951acecdd5ab1
Author: Roger Sayle
Date: Wed F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #7 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > Started with r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
> > The regression status is unclear because we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #6 from Richard Biener ---
With the following I don't see things going wrong, but we end up with the loop
having the STOP exit last instead and thus a PEELED case.
function bar (n) result (k)
integer :: n, k
!$omp simd lastpriva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #14 from Sebastian Huber ---
Thanks for your help, it seems that this patch fixes the issue for RTEMS:
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 57a2325991b..b36e64fec77 100644
--- a/gcc/config/rs6000/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113809
Bug ID: 113809
Summary: Error of constexpr variable creation due to combined
use of std::tuple, copy constructor and static
function
Product: gcc
Version: 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Started with r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
> The regression status is unclear because we emitted sorry on this
> before r14-2634-g85da0b405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #4 from Richard Biener ---
Reduced a bit, w/o collapse:
program main
integer :: n, i,k
n = 11
do i = 1, n,2
!$omp simd lastprivate(k)
do k = 1, i + 41
if (k > 11 + 41 .or. k < 1) error stop
end do
end do
1 - 100 of 169 matches
Mail list logo
