git commit g:239728ffd579e4947c9f9932ccea8a4801b58800
gcc-descr r11-11308-g239728ffd579e4
power8
Linux 5.4.0-174-generic ppc64le
GNU Make 4.2.1
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 04:22:16 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #7 from uecker at gcc dot gnu.org ---
What is strange is that not updating TYPE_CANONICAL also seems wrong even
before C23, because then it seems we should be able to get pointers with
different TYPE_CANONICAL which are compatible
git commit g:356e23e3d9862806665b77e02094d2f65a6553d5
gcc-descr r12-10308-g356e23e3d98628
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 04:16:01 UTC 2024
Regressions on master at commit r14-9773 vs commit r14-9738 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
New passes:
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc version 14.0.1
20240403 (experimental) [master r14-9773-gd60968de696] (GCC)
=== gfortran tests ===
Running target unix
=== gfortran Summary for unix ===
# of expected passes6991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #6)
> (In reply to kargls from comment #5)
> > The pointers to expr->symtree is NULL. This new patch catches your example.
>
> It does, but behaves weird for
git commit g:fe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
gcc-descr r14-9780-gfe385c219994f6
power8
Linux 5.4.0-174-generic ppc64le
GNU Make 4.2.1
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 02:27:45 UTC 2024
LAST_UPDATED: Wed Apr 3 17:05:13 UTC 2024 (revision r14-9777-g5c749db15fa)
=== acats tests ===
FAIL: cb1010a
=== acats Summary ===
# of expected passes2327
# of unexpected failures1
Native configuration is s390x-ibm-linux-gnu arch14
git commit g:fd24c47e48c0e4a99e2393e3cd249d6c990060b5
gcc-descr r13-8578-gfd24c47e48c0e4
power9 IEEE128
Linux 6.9.0-0.rc2.20240402git026e680b0a08.24.fc41.ppc64le ppc64le
GNU Make 4.4.1
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
git commit g:fd24c47e48c0e4a99e2393e3cd249d6c990060b5
gcc-descr r13-8578-gfd24c47e48c0e4
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 02:50:29 UTC 2024
# From https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/1927/:
LAST_UPDATED: 2024-04-04T03:03:31+00:00 (master revision
gcc-14-9780-gfe385c21999) armv8l-unknown-linux-gnueabihf
Native configuration is armv8l-unknown-linux-gnueabihf
=== libatomic tests ===
Running
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m33_eabi-build/403/:
LAST_UPDATED: 2024-04-04T02:33:13+00:00 (master revision
gcc-14-9780-gfe385c21999) arm-eabi
{-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto}
Target is arm-unknown-eabi
git commit g:fe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
gcc-descr r14-9780-gfe385c219994f6
power9 IEEE128
Linux 6.9.0-0.rc2.20240402git026e680b0a08.24.fc41.ppc64le ppc64le
GNU Make 4.4.1
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
git commit g:fe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
gcc-descr r14-9780-gfe385c219994f6
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 01:20:58 UTC 2024
LAST_UPDATED: Thu Apr 4 00:40:05 UTC 2024 (revision r14-9780-gfe385c21999)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target sde
FAIL: gcc.target/i386/apx-ndd-tls-1b.c scan-assembler-times addq[
\\t]+%r[a-z0-9]+, a@gottpoff(%rip),
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4101
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240403 (experimental) [master-ia32 r14-9777-g5c749db15fa] (GCC)
=== gfortran tests ===
Running target unix
unexpected failures125
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4116
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240403 (experimental) [master r14-9777-g5c749db15fa] (GCC)
==
LAST_UPDATED: Thu Apr 4 00:40:05 UTC 2024 (revision r14-9780-gfe385c21999)
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
Hi Nada,
Apologies for not being able to reply earlier as well. I’m glad to hear
you’re interested in continuing this project! There is still a lot of work
to be done — my work from last summer is in a very prototype stage. As
David mentioned, familiarizing myself with the analyzer took some
git commit g:88ce7fbcc7e9a1ffcd684bab53d1f46017860c25
gcc-descr r14-9779-g88ce7fbcc7e9a1
power8
Linux 5.4.0-174-generic ppc64le
GNU Make 4.2.1
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 00:21:52 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33068
Andrew Pinski changed:
What|Removed |Added
Known to work||13.1.0
--- Comment #3 from Andrew
Hi all,
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the spaces to see if it is a comma or semicolon.
If so, I
git commit g:356e23e3d9862806665b77e02094d2f65a6553d5
gcc-descr r12-10308-g356e23e3d98628
power9 IEEE128
Linux 6.9.0-0.rc2.20240402git026e680b0a08.24.fc41.ppc64le ppc64le
GNU Make 4.4.1
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
git commit g:239728ffd579e4947c9f9932ccea8a4801b58800
gcc-descr r11-11308-g239728ffd579e4
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Thu Apr 4 00:23:34 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25548
Andrew Pinski changed:
What|Removed |Added
Known to fail||
Keywords|accepts-invalid
outputs-23 exe savetmp named2-2: outputs.ld1_args
FAIL: outputs-24 exe savetmp named2-3: outputs.ld1_args
FAIL: outputs-25 exe savetmp named2-4: outputs.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld_args
=== gcc Summary ==
https://gcc.gnu.org/g:fe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
commit r14-9780-gfe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
Author: Eugene Rozenfeld
Date: Tue Mar 26 16:28:08 2024 -0700
Don't set full_profile in auto-profile [PR113765]
auto-profile currently doesn't guarantee that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #8 from GCC Commits ---
The master branch has been updated by Eugene Rozenfeld :
https://gcc.gnu.org/g:fe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
commit r14-9780-gfe385c219994f6d5c1ffe00bcaf5a62c3d18caaf
Author: Eugene Rozenfeld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89305
--- Comment #2 from Andrew Pinski ---
I should note even though the other examples of DR 253 seems to be correctly
accepting now; this one still fails.
Note also EDG rejects this even though accepting the other examples of DR 253
issues; maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57820
Andrew Pinski changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #6 from Andrew Pinski
successes 1
# of expected failures 1763
# of unresolved testcases 1
# of unsupported tests 4481
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc
version 14.0.1 20240403 (experimental) [master revision
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284
Andrew Pinski changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10118
--- Comment #12 from Andrew Pinski ---
Hmm, clang accepts this also for -std=c++17 (and above).
While EDG accepts this for --c++11 (and above).
Is this valid in C++11+ or C++17+ now?
of unsupported tests 3437
=== gcc Summary ===
# of expected passes601586
# of unexpected failures401
# of unexpected successes 59
# of expected failures 4657
# of unsupported tests 10826
/export/gnu/import/git/gcc-test-master-
Regressions on master at commit r14-9773 vs commit r14-9752 on Linux/x86_64
New failures:
New passes:
FAIL: gcc.dg/torture/convert-dfp-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
FAIL: gcc.dg/torture/convert-dfp.c -O2 -flto -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40771
--- Comment #4 from Andrew Pinski ---
AARCH64 vectorization looks decent too:
```
dup v31.8h, w0
adrpx2, .LC0
adrpx0, .LC1
adrpx1, .LANCHOR0
ldr q30, [x2, #:lo12:.LC0]
ldr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
Andrew Pinski changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #6
uccesses 12
# of expected failures 1597
# of unsupported tests 5019
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240403
(experimental) [remotes/origin/HEAD r14-9778-gf375550287] (GCC)
=== gfortran tests ===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28141
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
--- Comment #4 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #3)
> vaesenc etc. instructions can be used even if just -maes -mavx, not just
> -mvaes -mavx512vl.
Correct, that's just VEX-prefixed AESNI instructions.
VAES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47048
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Keywords|
A retry build has been detected on builder gcc-fedora-x86_64 while building gcc.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/159/builds/9369
Build state: worker not available
Revision: (unknown)
Worker: bb2-1
Build Reason: (unknown)
Blamelist: Joseph
# of expected passes160371
# of unexpected failures273
# of expected failures 1017
# of unresolved testcases 1
# of unsupported tests 9346
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
version 14.0.1 20240403 (e
an/ieee128-math.f90 -O (test for excess
errors)
=== gcc Summary ===
# of expected passes179247
# of unexpected failures114
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4242
/home/gccbuild/build/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40988
--- Comment #3 from Andrew Pinski ---
One more note the Linux kernel sources has been corrected already.
They do now:
asm volatile(__ASM_SIZE(btr) " %2,%1"
CC_SET(c)
: CC_OUT(c) (oldbit)
get/s390/vxe/popcount-1.c scan-assembler vpopctb\\t%v24,%v24
XPASS: gcc.target/s390/vxe/popcount-1.c scan-assembler vpopcth\\t%v24,%v24
=== gcc Summary for unix/-m64 ===
# of expected passes180712
# of unexpected failures182
# of unexpected successes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40988
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240403
(experimental) [remotes/origin/HEAD r14-9778-gf3755502871] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|willschm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36512
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #15 from Adrian Bunk ---
(In reply to Tobias Burnus from comment #11)
> RFC draft patch – also to solve an offload problem with atomic and nvptx
> libgomp:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556297.html
> See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32775
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34629
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
f expected failures 1550
# of unsupported tests 3992
/home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc version 13.2.1 20240403
[releases/gcc-13 r13-8577-gae11f01541] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426
--- Comment #7 from Patrick Palka ---
There's a patch pending review at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647203.html
Until that's merged, one should be able to work around this error with a trunk
compiler by using
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m33_eabi-build/398/:
LAST_UPDATED: 2024-04-03T20:34:41+00:00 (master revision
gcc-14-9691-gdb41057a94f) arm-eabi
{-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto}
Target is arm-unknown-eabi
Alex Coplan writes:
> On 23/02/2024 16:41, Ajit Agarwal wrote:
>> Hello Richard/Alex/Segher:
>
> Hi Ajit,
>
> Sorry for the delay and thanks for working on this.
>
> Generally this looks like the right sort of approach (IMO) but I've left
> some comments below.
>
> I'll start with a meta comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 4/3/24 15:16, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 12:58:12PM -0400, Jason Merrill wrote:
On 4/3/24 12:42, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
Using std::is_constant_evaluated directly in a loop condition is, as the
paper says,
https://gcc.gnu.org/g:f37555028717cb1454ee258afdf68aea1c7a50e9
commit r14-9778-gf37555028717cb1454ee258afdf68aea1c7a50e9
Author: Joseph Myers
Date: Wed Apr 3 20:47:47 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86466
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86466
--- Comment #1 from Andrew Pinski ---
Created attachment 57870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57870=edit
testcase
Please next time attach or place the testcase inline instead of just linking to
godbolt, we were just lucky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86303
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail
Fix the issue by checking if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> The pointers to expr->symtree is NULL. This new patch catches your example.
It does, but behaves weird for some other cases. Try:
program main
complex
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240403
[releases/gcc-13 r13-8577-gae11f01541] (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86027
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017
Andrew Pinski changed:
What|Removed |Added
CC||subscribe at teskor dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85919
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85919
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85620, which changed state.
Bug 85620 Summary: Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
--- Comment #7 from Andrew Pinski ---
clang does not implement this intrinsics either and there is no issue filed
there about it either (I am kinda of shocked).
Note ICX (which is the new ICC but with using clang/LLVM) does and it calls
unexpected failures125
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4116
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240403 (experimental) [master r14-9773-gd60968de696] (GCC)
==
an-tree-dump-times ompexp
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-3.c -std=gnu++20 scan-tree-dump-times ompexp
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-9.c -std=gnu++98 scan-tree-dump-times ompexp
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #3 from Jonathan Wakely ---
So maybe:
--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_istream::
ignore(streamsize __n, int_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
--- Comment #6 from Andrew Pinski ---
https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#!=undefined=SVML=_mm256_atan2_ps_expand=393
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4101
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
20240403 (experimental) [master-ia32 r14-9773-gd60968de696] (GCC)
=== gfortran tests ===
Running target unix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577
Bug ID: 114577
Summary: Inefficient codegen for SVE/NEON bridge
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
uccesses 12
# of expected failures 1597
# of unsupported tests 5019
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240403
(experimental) [remotes/origin/HEAD r14-9777-g5c749db15f] (GCC)
=== gfortran tests ===
On Wed, Apr 03, 2024 at 12:58:12PM -0400, Jason Merrill wrote:
> On 4/3/24 12:42, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
> > > Using std::is_constant_evaluated directly in a loop condition is, as the
> > > paper says, unlikely and "horrendous code",
Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gcc:
> Hello all,
>
> On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote:
> > > My take a way is that software needs to become less complex. Do
> > > we really still need complex build systems such as autoconf?
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 113363, which changed state.
Bug 113363 Summary: ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target
Regressions on native/master at commit r14-9777 vs commit r14-9773 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
New passes:
FAIL: gcc.dg/torture/convert-dfp-2.c -O2 -flto -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
=== gcc Summary ===
# of expected passes49472
# of unexpected failures197
# of unexpected successes 5
# of expected failures 56
# of unsupported tests 1462
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc version
14.0.1 20240403 (e
On Wed, 3 Apr 2024 at 19:36, Toon Moene wrote:
>
> On 4/3/24 20:25, Ian Lance Taylor wrote:
>
> > Note that the attack really didn't have anything to do with
> > compressing data. The library used an IFUNC to change the PLT of a
> > different function, so it effectively took control of the code
On Apr 03 2024, Paul Floyd via Gcc wrote:
> On 03-04-24 14:32, Martin Uecker via Gcc wrote:
>
>> The backdoor was hidden in a complicated autoconf script...
>
> How many uncomplicated autoconf scripts exist in the real world?
Probably the same amount as in any other build system. Building
Hello all,
On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote:
> > My take a way is that software needs to become less complex. Do
> > we really still need complex build systems such as autoconf?
>
> (And, FWIW, testing for features isn't "complex". And have you looked at
> other build
LAST_UPDATED: Wed Apr 3 16:40:05 UTC 2024 (revision r14-9777-g5c749db15fa)
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
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240403
(experimental) [remotes/origin/HEAD r14-9777-g5c749db15fa] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
On 4/3/24 20:25, Ian Lance Taylor wrote:
Note that the attack really didn't have anything to do with
compressing data. The library used an IFUNC to change the PLT of a
different function, so it effectively took control of the code that
verified the cryptographic key. The only part of the
On Wed, Apr 3, 2024 at 11:05 AM Toon Moene wrote:
>
> Two questions arise (as far as I am concerned):
>
> 1. Do daemons like sshd *have* to be linked with shared libraries ?
> Or could it be left to the security minded of the downstream
> (binary) distributions to link it statically with
> On Apr 3, 2024, at 2:04 PM, Toon Moene wrote:
>
> On 4/1/24 17:06, Mark Wielaard wrote:
>
>> A big thanks to everybody working this long Easter weekend who helped
>> analyze the xz-backdoor and making sure the impact on Sourceware and
>> the hosted projects was minimal.
>
> Thanks for
On 3/28/24 08:22, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The testcase in comment 15 of the linked PR is caused because the
following assumption in depset::hash::make_dependency doesn't hold:
if (DECL_LANG_SPECIFIC (not_tmpl)
On 4/1/24 17:06, Mark Wielaard wrote:
A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.
Thanks for those efforts !
Now, I have seen two more days of thinking about this
1 - 100 of 339 matches
Mail list logo
