https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #25 from Jeffrey A. Law ---
Well, at least in theory SPEC isn't supposed to be changing the sources or
validation criteria on us. So while our copy may be old, I would expect it's
still the same as Filip's.
That doesn't resolve
Snapshot gcc-11-20240314 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240314/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi Abhinav!
Thanks for your interest in contributing to GCC, and thanks to Martin for
all the information you already provided. Just a bit more, to get you
started on developing a proper project proposal:
On 2024-03-13T14:54:52+0100, Martin Jambor wrote:
> On Tue, Mar 12 2024, Abhinav Gupta
=== gcc Summary ===
# of expected passes179063
# of unexpected failures132
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4186
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82599
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #15 from Jakub Jelinek ---
Created attachment 57707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57707=edit
gcc14-pr114339.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114340
Bug ID: 114340
Summary: ` X / CST < X` -> `X > 0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority:
Hi
This is what I started to do.
For now I haven't touch to __cpp_lib_null_iterators definition as
_Safe_local_iterator still need some work.
libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
Consider range of value-initialized iterators as valid and empty.
libstdc++-v3/ChangeLog:
1462
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc version
14.0.1 20240314 (experimental) [native/master r14-9483-g6dbf0d252f6] (GCC)
=== g++ tests ===
Running target sde
FAIL: g++.target/i386/mv28.C -std=c++14 (test for errors, line 10)
FAIL: g++.
Regressions on native/master at commit r14-9483 vs commit r14-9475 on
Linux/x86_64
New failures:
FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
FAIL: g++.dg/torture/pr104601.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr104601.C -O0
LAST_UPDATED: Thu Mar 14 19:40:04 UTC 2024 (revision r14-9483-g6dbf0d252f6)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72)
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #13 from Jakub Jelinek ---
Nice, further cleaned up:
/* PR target/114339 */
/* { dg-do run } */
/* { dg-options "-O2 -Wno-psabi" } */
/* { dg-additional-options "-mavx" { target avx_runtime } } */
typedef long V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #12 from Andrew Pinski ---
I suspecting r13-3803-gfa271afb584230 which missed the border case of
INT_MAX/INT_MIN .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0, 12.1.0, 12.3.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #9 from Andrew Pinski ---
Reduced testcase:
```
#define vect128 __attribute__((vector_size(16)))
[[gnu::noinline]]
vect128 long f(vect128 long a)
{
return a <= (vect128 long){0, 9223372036854775807};
}
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #8 from Jakub Jelinek ---
Slightly simplified/cleaned up testcase:
/* { dg-do run } */
/* { dg-options "-O2 -fno-vect-cost-model" } */
/* { dg-additional-options "-mavx" { target avx_runtime } } */
struct S { int a; long b; int c;
On Tue, Mar 12, 2024 at 06:26:14PM -0400, Jason Merrill wrote:
> On 3/12/24 11:56, Marek Polacek wrote:
> > On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote:
> > > On 3/11/24 19:27, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
> > > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #7 from Andrew Pinski ---
This looks wrong:
```
;; mask_patt_17.15_55 = vect_cst__53 <= { 0, 9223372036854775807 };
(insn 21 20 22 (set (reg:V2DI 111)
(mem/u/c:V2DI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S16 A128]))
Regressions on releases/gcc-13 at commit r13-8438 vs commit r13-8432 on
Linux/x86_64
New failures:
FAIL: gcc.dg/2111-1.c (test for excess errors)
FAIL: gcc.dg/bconstp-4.c (test for errors, line 10)
FAIL: gcc.dg/bconstp-4.c (test for errors, line 10)
FAIL: gcc.dg/bitfld-2.c (test for
LAST_UPDATED: Thu Mar 14 08:30:04 UTC 2024 (revision r13-8438-gbdbcfbfcf59)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors)
ERROR: tcl error code NONE
ERROR: tcl error code NONE
Summary ===
# of expected passes179063
# of unexpected failures116
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4188
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(experimental) [remote
https://gcc.gnu.org/g:efab8c1b692ab080bcee99a6ef7ba6ee43ed
commit r14-9484-gefab8c1b692ab080bcee99a6ef7ba6ee43ed
Author: Jason Merrill
Date: Thu Feb 22 10:06:27 2024 +
tree-core: clarify clobber comments
It came up on the mailing list that OBJECT_BEGIN/END are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #24 from Robin Dapp ---
I rebuilt GCC from scratch with your options but still have the same problem.
Could our sources differ? My SPEC version might not be the most recent but I'm
not aware that mcf changed at some point.
Just
2078
# of unexpected failures170
# of unexpected successes 14
# of expected failures 1468
# of unsupported tests 3885
/home/gccbuild/build/nightly/build-gcc-12/gcc/xgcc version 12.3.1 20240314
[remotes/origin/releases/gcc-12 r12-10214-ga861f940ef] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #6 from Tamar Christina ---
vectorizer generates:
mask_patt_21.19_58 = vect_perm_even_49 >= vect_cst__57;
mask_patt_21.19_59 = vect_perm_even_55 >= vect_cst__57;
vexit_reduc_63 = mask_patt_21.19_58 | mask_patt_21.19_59;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91861
--- Comment #3 from Andrew Pinski ---
*** Bug 94413 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94413
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91861
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|invalid
On Thu, Mar 14, 2024 at 04:27:22PM -0400, Jason Merrill wrote:
> OK for trunk?
>
> -- 8< --
>
> It came up on the mailing list that OBJECT_BEGIN/END are described as
> marking object lifetime, but mark the beginning of the constructor and end
> of the destructor, whereas the C++ notion of
or warnings,
line 37)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++14 (test for excess errors)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings,
line 37)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 (test for excess errors)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
--- Comment #15 from Jason Merrill ---
Created attachment 57706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57706=edit
one approach
I tried just making implicit functions respect #pragma target, but that
regresses pr105306 due to
OK for trunk?
-- 8< --
It came up on the mailing list that OBJECT_BEGIN/END are described as
marking object lifetime, but mark the beginning of the constructor and end
of the destructor, whereas the C++ notion of lifetime is between the end of
the constructor and beginning of the destructor. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #6 from Andrew Pinski ---
(In reply to Pali Rohár from comment #5)
> There is one problem with it. I had to "hardcode" x86_64-w64-mingw32-windres
> name instead of just "windres". How to declare cross compile prefix? Because
> gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54454
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9058
Andrew Pinski changed:
What|Removed |Added
CC||mikulas at artax dot
karlin.mff.cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #5 from Pali Rohár ---
Thank you for info, I read that blog post and based on those details I adjusted
spec file
$ x86_64-w64-mingw32-gcc -dumpspecs > test.spec
by adding additional lines to test.spec:
.rc:
Regressions on releases/gcc-13 at commit r13-8438 vs commit r13-8432 on
Linux/x86_64
New failures:
FAIL: gcc.dg/20010405-1.c (test for excess errors)
FAIL: gcc.dg/20010405-1.c (test for excess errors)
FAIL: gcc.dg/20010405-1.c (test for excess errors)
FAIL: gcc.dg/20010405-1.c (test for excess
527230
# of unexpected failures639
# of unexpected successes 52
# of expected failures 3862
# of unresolved testcases 8
# of unsupported tests 7159
/export/
=== gcc Summary ===
# of expected passes179063
# of unexpected failures132
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4186
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91672
Andrew Pinski changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91672
--- Comment #2 from Andrew Pinski ---
Note the .size does match up with what GCC outputs though:
e.g. a1:
.size a1, 18
a1:
.xword 1
.hword 1
.hword 1
.zero 6
that is size of 18.
Basically gcc's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91672
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
unexpected failures125
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4078
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240314 (experimental) [master r14-9469-g9349aefa1df] (GCC)
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
John David Anglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 3/8/24 12:02, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Consider
constexpr int VAL = 1;
struct foo {
template
void bar(typename std::conditional::type arg) { }
};
template void foo::bar<1>(int arg);
where we since
(test for excess
errors)
=== gcc Summary ===
# of expected passes178055
# of unexpected failures148
# of unexpected successes 12
# of expected failures 1597
# of unsupported tests 4965
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc
Summary ===
# of expected passes179063
# of unexpected failures116
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4188
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(experimental) [remote
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4063
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240314 (experimental) [master-ia32 r14-9469-g9349aefa1df] (GCC)
=== gfortran tests ===
Running target unix
$ ../configure --prefix=/home/gaius/opt --libexecdir=/home/gaius/opt/lib
--enable-host-shared --enable-threads=posix --enable-clocale=gnu
--enable-checking --enable-long-longx --enable-languages=m2 --enable-multilib
--enable-plugin --enable-bootstrap
gcc-branch: master
git commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114294
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[14 regression]
https://gcc.gnu.org/g:6dbf0d252f69ab2924256e6778ba7dc55d5b6915
commit r14-9483-g6dbf0d252f69ab2924256e6778ba7dc55d5b6915
Author: Gaius Mulley
Date: Thu Mar 14 19:09:34 2024 +
PR modula2/114294 expression causes ICE
This patch fixes an ICE when encountering an expression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114294
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:6dbf0d252f69ab2924256e6778ba7dc55d5b6915
commit r14-9483-g6dbf0d252f69ab2924256e6778ba7dc55d5b6915
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #4 from Sam James ---
(In reply to Sam James from comment #3)
> Created attachment 57705 [details]
> larger.i
>
> Ah, wait, that might be a bad reduction. Let me attach a larger one, then I
> can give the original if needed too.
1462
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc version
14.0.1 20240314 (experimental) [native/master r14-9475-g7aeedff6a42] (GCC)
=== g++ tests ===
Running target sde
FAIL: g++.target/i386/mv28.C -std=c++14 (test for errors, line 10)
FAIL: g++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #3 from Sam James ---
Created attachment 57705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57705=edit
larger.i
Ah, wait, that might be a bad reduction. Let me attach a larger one, then I can
give the original if needed
LAST_UPDATED: Thu Mar 14 16:40:05 UTC 2024 (revision r14-9475-g7aeedff6a42)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72)
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #12 from Jakub Jelinek ---
Yeah. So the cases where we should do it is when we are reversing a narrowing
cast, or also something for the other PRs Andrew mentioned, like when reversing
BIT_AND_EXPR (but maybe also
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Fix REG+D address support before reload
When generating PA 1.x code or code for GNU ld, floating-point
accesses only support 5-bit displacements but integer accesses
support 14-bit displacements. I mistakenly assumed reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Sam James changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #1 from Sam James ---
The assert is at
https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.8.10/src/feature/client/entrynodes.c#L2072
```
(gdb) p delays
$3 = {{
maximum = 21600,
primary_delay = 600,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Bug ID: 114339
Summary: [14 regression] Tor miscompiled with -O2 -mavx
-fno-vect-cost-model
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/g:53fd0f5b1fd737a208c12909fa1188281cb370a3
commit r14-9482-g53fd0f5b1fd737a208c12909fa1188281cb370a3
Author: John David Anglin
Date: Thu Mar 14 18:32:56 2024 +
hppa: Fix REG+D address support before reload
When generating PA 1.x code or code for GNU ld,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #14 from GCC Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:53fd0f5b1fd737a208c12909fa1188281cb370a3
commit r14-9482-g53fd0f5b1fd737a208c12909fa1188281cb370a3
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> I really don't know how GORI etc. works.
> But, if when the switch handling determines that _1 (the switch controlling
> expression) has [irange] [111, 111]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141
--- Comment #7 from Andrew Pinski ---
Note I noticed the testcase in PR 90390 ICEs starting in GCC 13 and it seems
similar to the testcase in comment #0 here.
=== gcc Summary ===
# of expected passes179063
# of unexpected failures132
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4186
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Fixed for GCC 13+ by r13-2964-gbbdb5612f6661f2c64b0c0f1d2291cb59fde2b40 .
Or by r13-2963-g32b2eb59fb9049 .
Anyways both together are needed IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114332
--- Comment #1 from Jakub Jelinek ---
Given that the x86-64 psABI says:
\item The value of the unused bits beyond the width of the
\texttt{_BitInt(N)} value but within the size of the
\texttt{_BitInt(N)} are unspecified when stored in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114294
--- Comment #2 from Gaius Mulley ---
Created attachment 57704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57704=edit
Proposed fix
The proposed fix was to assign a type to the result constant created by HIGH.
The call to PutConst was
On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> Hi!
>
> After recent discussions on IRC and on the lists about maintainer-mode
> and various problems with auto-generated source files, I've written
> this small prototype.
>
> Based on those discussions, I assumed that people generally
On 3/14/24 10:16, Jose E. Marchesi wrote:
>
> Hi David.
>
>> Change the BPF backend to define INT8_TYPE with an explicit sign, rather
>> than a plain char. This is in line with other targets and removes the
>> risk of int8_t being affected by the signedness of the plain char type
>> of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #10 from Jakub Jelinek ---
I really don't know how GORI etc. works.
But, if when the switch handling determines that _1 (the switch controlling
expression) has [irange] [111, 111] MASK 0x0 VALUE 0x6f (does it actually? i.e.
for a
https://gcc.gnu.org/g:6cf4286ff9456685a29812a3560d00b956d62c39
commit r14-9481-g6cf4286ff9456685a29812a3560d00b956d62c39
Author: David Faust
Date: Thu Mar 14 09:05:38 2024 -0700
bpf: define INT8_TYPE as signed char
Change the BPF backend to define INT8_TYPE with an explicit sign,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #4 from Andrew Pinski ---
Note I added this to the list of Canonicalization issues in gimple on the wiki:
https://gcc.gnu.org/wiki/GimpleCanonical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Summary ===
# of expected passes179061
# of unexpected failures116
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4188
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240314
(experimental) [remote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #23 from Filip Kastl ---
Yeah I also don't know what else to do to make the gcda files work for you :-/
I can send you my compiler binaries but you should have exactly the same if you
compile from the same commit (if I'm not
After switching to LRA xtensa backend generates the following code for
saving/loading registers:
movi a9, 0x190
add a9, a9, sp
s32i.n a3, a9, 0
instead of the shorter and more efficient
s32i a3, a9, 0x190
E.g. the following code can be used to reproduce it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #8 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > You may want to look at:
> >
> > // Return the bitmask inherent in the range.
> >
> > irange_bitmask
> >
https://gcc.gnu.org/g:bc5a9dab55d13f888a3cdd150c8cf5c2244f35e0
commit r14-9480-gbc5a9dab55d13f888a3cdd150c8cf5c2244f35e0
Author: Max Filippov
Date: Thu Mar 14 04:20:36 2024 -0700
gcc: xtensa: reorder movsi_internal patterns for better code generation
during LRA
After switching
A restored build has been detected on builder gcc-fedora-mingw while building
gcc.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/262/builds/4988
Build state: build successful
Revision: 7580e39452b65ab5fb5a06f3f1ad7d59720269b5
Worker: bb1-2
Build Reason:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #22 from Robin Dapp ---
Still the same problem unfortunately.
I'm a bit out of ideas - maybe your compiler executables could help?
Hi David.
> Change the BPF backend to define INT8_TYPE with an explicit sign, rather
> than a plain char. This is in line with other targets and removes the
> risk of int8_t being affected by the signedness of the plain char type
> of the host system.
OK.
I would add to the commit message
ion 13.2.1 20240314
[releases/gcc-13 r13-8438-gbdbcfbfcf5] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O1 execution test
XPASS: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #7 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #6)
> You may want to look at:
>
> // Return the bitmask inherent in the range.
>
> irange_bitmask
> irange::get_bitmask_from_range () const
> {
> }
>
> IIRC,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #21 from Filip Kastl ---
Created attachment 57703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57703=edit
gcda data for the commit before robin's commit (v2)
Here are the gcda files generated with -march=znver4
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The fast path for "{}" format strings has a bug for negative integers
where the length passed to std::to_chars is too long.
libstdc++-v3/ChangeLog:
PR libstdc++/114325
* include/std/format (_Scanner::_M_scan): Pass correct length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114325
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
I forgot to update the commit log to remove the speculation, because
Stephan Lavavej confirmed that MSVC doesn't mark those functions
nodiscard because it would result in too many false positives. Although
it might find some real bugs, it
https://gcc.gnu.org/g:f89cfdb2f2e9b4fe517b1e00511c4d70a7014cbc
commit r14-9479-gf89cfdb2f2e9b4fe517b1e00511c4d70a7014cbc
Author: Jonathan Wakely
Date: Wed Mar 13 21:19:54 2024 +
libstdc++: Fix std::format("{}", negative_integer) [PR114325]
The fast path for "{}" format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114325
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f89cfdb2f2e9b4fe517b1e00511c4d70a7014cbc
commit r14-9479-gf89cfdb2f2e9b4fe517b1e00511c4d70a7014cbc
Author: Jonathan Wakely
https://gcc.gnu.org/g:df483ebd24689a3bebfae2089637a00eca0e5a12
commit r14-9478-gdf483ebd24689a3bebfae2089637a00eca0e5a12
Author: Jonathan Wakely
Date: Mon Feb 26 13:17:13 2024 +
libstdc++: Add nodiscard in
Add the [[nodiscard]] attribute to several functions in .
These
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Actually, looking at value-range.h, irange_bitmask doesn't have just the
> > mask but also value, so I wonder
Hi all, hi Thomas & Chung-Lin,
Thomas Schwinge wrote:
But I realized another thing: don't we have to handle the 'readonly'
modifier also in Fortran module files, that is, next to the OpenACC
'declare' 'copyin' handling in 'gcc/fortran/module.cc':
'AB_OACC_DECLARE_COPYIN' etc.?
I bet so; it is
Hi!
I've noticed a typo in the comment above ABI_VERSION_SPEC.
Fixed thusly, committed to trunk as obvious.
2024-03-14 Jakub Jelinek
* config/gcn/gcn-hsa.h (ABI_VERSION_SPEC): Fix comment typo.
--- gcc/config/gcn/gcn-hsa.h.jj 2024-01-27 13:03:55.589073484 +0100
+++
101 - 200 of 407 matches
Mail list logo
