https://gcc.gnu.org/g:109f1b28fc94c93096506e3df0c25e331cef19d0
commit r14-9885-g109f1b28fc94c93096506e3df0c25e331cef19d0
Author: Richard Biener
Date: Wed Apr 10 07:57:03 2024 +0200
Revert "combine: Don't combine if I2 does not change"
This reverts commit
This reverts commit 839bc42772ba7af66af3bd16efed4a69511312ae.
I have now pushed the temporary reversion of this to resolve the
P1 regressions this caused. I'll re-install it on trunk once 14.1
was released (which might be a week or two after stage1 opens).
Richard.
---
gcc/combine.cc | 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot
On Tue, Apr 09, 2024 at 07:24:33AM -0700, H.J. Lu wrote:
> Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid
> the sanitizer configure check failure.
OK for binutils. (I just fixed my local copy of autoconf so I
wouldn't run into this again.) The proper fix of course is
On Tue, Apr 9, 2024 at 11:02 PM Andrew Pinski (QUIC)
wrote:
>
> While looking into PR 114666, I noticed that we don't verify COND_EXPR's
> first operand. In most of my recent patches to match.pd, I was assuming that
> it would be a boolean (or a type which would contain
> [0,1]) but this PR
git commit g:7924e352523b37155ed9d76dc426701de9d11a22
gcc-descr r14-9884-g7924e352523b37
power9 BE
Linux 6.7.9-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Wed Apr 10 04:02:49 UTC 2024
git commit g:2047ecb27e5fd44c7ccfd549c1b8bd9eef0bdb43
gcc-descr r13-8596-g2047ecb27e5fd4
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: Wed Apr 10 04:21:29 UTC 2024
601789
# of unexpected failures406
# of unexpected successes 59
# of expected failures 4657
# of unsupported tests 10840
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc version 14.0.1
20240409 (experimental) [master r14-9872-g32fb04adae9] (GCC)
Regressions on master at commit r14-9872 vs commit r14-9823 on Linux/x86_64
New failures:
FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #4 from kugan at gcc dot gnu.org ---
This particular loop has loop->safelen set to 16. Does this mean this can never
be loop vectorized for VLA?
git commit g:8c77bfbb366b6aeb1f8ac068929f54d7bd4a9c3d
gcc-descr r11-11314-g8c77bfbb366b6a
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: Wed Apr 10 03:28:39 UTC 2024
git commit g:7924e352523b37155ed9d76dc426701de9d11a22
gcc-descr r14-9884-g7924e352523b37
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:7924e352523b37155ed9d76dc426701de9d11a22
gcc-descr r14-9884-g7924e352523b37
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: Wed Apr 10 02:51:43 UTC 2024
-trunk-r14-9877-20240409180605-g1f719aa7c0d-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240409 (experimental) (GCC)
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote:
On 3/11/24 12:53, Patrick Palka wrote:
r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #3 from kugan at gcc dot gnu.org ---
For SVE mode in vect_analyze_loop_2, we have
(gdb) p min_vf
$15 = {coeffs = {4, 4}}
(gdb) p max_vf
$16 = 16
Thus maybe_lt (max_vf, min_vf)) is false. This results in bad data dependence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #2 from kugan at gcc dot gnu.org ---
Thanks. I see the following in the log:
test.cpp:33:53: missed: not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed: bad operation or
LAST_UPDATED: Tue Apr 9 17:05:13 UTC 2024 (revision r14-9877-g1f719aa7c0d)
=== acats tests ===
FAIL: cb1010a
=== acats Summary ===
# of expected passes2327
# of unexpected failures1
Native configuration is s390x-ibm-linux-gnu arch14
git commit g:2047ecb27e5fd44c7ccfd549c1b8bd9eef0bdb43
gcc-descr r13-8596-g2047ecb27e5fd4
power9 BE
Linux 6.7.9-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Wed Apr 10 02:32:19 UTC 2024
git commit g:ea665f90260acb3ffd2e39fcd2e200e702ee0ead
gcc-descr r14-9882-gea665f90260acb
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: Wed Apr 10 01:32:00 UTC 2024
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_eabi-build/451/:
LAST_UPDATED: 2024-04-10T02:45:45+00:00 (master revision
gcc-14-9883-g0774240b4df) arm-eabi
{-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp}
Target is arm-unknown-eabi
Host is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #13 from Li Pan ---
overriding TARGET_CLASS_LIKELY_SPILLED_P hook may not be a fix as it will
generate sorts of spill for the below sample code.
vbool2_t test_vmfge_vf_f16m8_b2(vfloat16m8_t op1, float16_t op2, size_t vl) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #8 from Kewen Lin ---
(In reply to Peter Bergner from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Pre-IRA fix was done to specifically reject this:
> > https://inbox.sourceware.org/gcc-patches/
> >
git commit g:221ae01abd54dd14e603c7d616261969eafe4f7f
gcc-descr r12-10317-g221ae01abd54dd
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
> note: some syscalls / features don't work without asm
> (posix thread cancellation, vfork, signal return,..)
That's true. On the other hand, POSIX compliance
is not always a goal or a requirement.
> and using raw syscalls outside of the single runtime the
> application is using is problematic
ution test
=== gcc Summary ===
# of expected passes197297
# of unexpected failures120
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4109
/export/gnu/import/git/gcc-test-master-ia32/bld/gcc/xgcc version 14.0.1
On 4/9/24 3:19 PM, Peter Bergner wrote:
> Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
> keep the same behavior for GCC 14 (before removing in stage1), we want just:
>
> mdirect-move
> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>
[^n]* = foo.simdclone" 2
=== gcc Summary ===
# of expected passes197247
# of unexpected failures128
# of unexpected successes 27
# of expected failures 1556
# of unsupported tests 4124
/export/gnu/import/git/gcc-test-master-ia32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/g:7924e352523b37155ed9d76dc426701de9d11a22
commit r14-9884-g7924e352523b37155ed9d76dc426701de9d11a22
Author: Peter Bergner
Date: Tue Apr 9 15:24:39 2024 -0500
rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
[PR101865]
This is a cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #18 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:7924e352523b37155ed9d76dc426701de9d11a22
commit r14-9884-g7924e352523b37155ed9d76dc426701de9d11a22
Author: Peter Bergner
Date:
git commit g:8c77bfbb366b6aeb1f8ac068929f54d7bd4a9c3d
gcc-descr r11-11314-g8c77bfbb366b6a
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: Wed Apr 10 01:44:12 UTC 2024
git commit g:77c0b5b23f91404004a9bf710981f6d615b63f57
gcc-descr r14-9881-g77c0b5b23f9140
power9 BE
Linux 6.7.9-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Wed Apr 10 00:59:09 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 107068, which changed state.
Bug 107068 Summary: Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
What|Removed |Added
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_eabi-build/388/:
LAST_UPDATED: 2024-04-10T02:01:02+00:00 (master revision
gcc-14-9882-gea665f90260) arm-eabi
{-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto}
Target is arm-unknown-eabi
Host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
> I see systems making it more difficult for code to make syscalls,
> not easier.
That's true.
I think it's because other systems can afford to keep that ABI unstable.
Since Linux is an independently developed kernel, it _must_ be possible
to target the kernel directly with no user space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #15 from Kewen Lin ---
(In reply to Michael Matz from comment #14)
> Hmm? But this is not how the global-to-local hand-off is implemented (and
> expected by tooling): a fall-through. The global entry sets up the GOT
> register,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114671
Bug ID: 114671
Summary: [RISC-V] -fvar-tracking -gas-locview-support -ggdb
emits a non-constant .uleb128
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #14 from Yang Yujie ---
Is it not really necessary for now, since there is no LSX/LASX support in GCC
12 / 13?
git commit g:2047ecb27e5fd44c7ccfd549c1b8bd9eef0bdb43
gcc-descr r13-8596-g2047ecb27e5fd4
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 104040, which changed state.
Bug 104040 Summary: linker: when exported template class from module is used in
several .cpp with same tpl arg ~ undefined reference to not default non-inline
destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
Target
> Now the question comes is the argument long or some other type?
I believe so. Every library I've seen and the kernel itself uses long.
Other types just get typecasted to long. I think it's just supposed to
mean "register type" since all the arguments must be in registers.
> E.g. for some 32bit
=== gcc Summary ===
# of expected passes49494
# of unexpected failures197
# of unexpected successes 5
# of expected failures 56
# of unsupported tests 1465
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc version
14.0.1 20240409 (e
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240409
(experimental) [remotes/origin/HEAD r14-9879-g92b38ec84f2] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
LAST_UPDATED: Tue Apr 9 23:40:05 UTC 2024 (revision r14-9879-g92b38ec84f2)
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
On Tue, Apr 09, 2024 at 10:28:01AM -0400, Jason Merrill wrote:
> On 4/9/24 09:36, Nathaniel Shead wrote:
> > On Mon, Apr 08, 2024 at 11:17:27PM -0400, Jason Merrill wrote:
> > > On 4/4/24 07:27, Nathaniel Shead wrote:
> > > > On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:0774240b4df9a9bc48ce33a9625788e402498f5a
commit r14-9883-g0774240b4df9a9bc48ce33a9625788e402498f5a
Author: Nathaniel Shead
https://gcc.gnu.org/g:0774240b4df9a9bc48ce33a9625788e402498f5a
commit r14-9883-g0774240b4df9a9bc48ce33a9625788e402498f5a
Author: Nathaniel Shead
Date: Fri Mar 29 13:53:54 2024 +1100
c++: Keep DECL_SAVED_TREE of cdtor instantiations in modules [PR104040]
A template instantiation
> As noted by J. Wakely, you don't need to have one variant
> for each number of arguments.
Yes, he is right about that. I have already deleted
all the variants from my code since the variadic
builtin will be able to generate optimal code,
unlike a variadic C function.
> I assume you're talking
On 2/16/24 10:06, Patrick Palka wrote:
On Thu, 15 Feb 2024, Patrick Palka wrote:
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as we do for tree flag streaming, to at least be
optimized by the compiler into individual bit operations using
statically known
uccesses 12
# of expected failures 1597
# of unsupported tests 5023
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240409
(experimental) [remotes/origin/HEAD r14-9879-g92b38ec84f] (GCC)
=== gfortran tests ===
https://gcc.gnu.org/g:ea665f90260acb3ffd2e39fcd2e200e702ee0ead
commit r14-9882-gea665f90260acb3ffd2e39fcd2e200e702ee0ead
Author: Hongyu Wang
Date: Tue Apr 9 09:50:11 2024 +0800
[APX] Prohibit SHA/KEYLOCKER usage of EGPR when APX enabled
The latest APX spec announced removal of
f unresolved testcases 1
# of unsupported tests 9444
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
version 14.0.1 20240409 (experimental) [master revision
gcc-14-9879-g92b38ec84f2] (GCC)
Host is x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #23 from Jonathan Wakely ---
Re https://github.com/cplusplus/draft/issues/6922
It can't possibly mean that the returned time zone *needs* to be the same as
the C library, because that's impossible in general, because the C library
On Tue, Apr 9, 2024 at 3:05 PM Hongyu Wang wrote:
>
> The latest APX spec announced removal of SHA/KEYLOCKER evex promotion [1],
> which means the SHA/KEYLOCKER insn does not support EGPR when APX
> enabled. Update the corresponding constraints to their EGPR-disabled
> counterparts.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #22 from Jonathan Wakely ---
I do still consider it incorrect.
But what I mean re libc++ is that *even ignoring* the general problems with
using TZ, *their implementation* of using TZ isn't even correct. If the
intention is to
an/ieee128-math.f90 -O (test for excess
errors)
=== gcc Summary ===
# of expected passes179314
# of unexpected failures114
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4246
/home/gccbuild/build/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 99377, which changed state.
Bug 99377 Summary: [modules] undefined std::string_view::empty() if referenced
in inline exported function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
Nathaniel Shead changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
5241
# of unsupported tests 23133
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240409
(experimental) [master r14-9879-g92b38ec84f] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
https://gcc.gnu.org/g:77c0b5b23f91404004a9bf710981f6d615b63f57
commit r14-9881-g77c0b5b23f91404004a9bf710981f6d615b63f57
Author: Nathaniel Shead
Date: Thu Apr 4 23:16:08 2024 +1100
c++: Track declarations imported from partitions [PR99377]
The testcase in comment 15 of the linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
--- Comment #17 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:77c0b5b23f91404004a9bf710981f6d615b63f57
commit r14-9881-g77c0b5b23f91404004a9bf710981f6d615b63f57
Author: Nathaniel Shead
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_eabi-build/386/:
LAST_UPDATED: 2024-04-09T20:41:39+00:00 (master revision
gcc-14-9840-g1162861439f) arm-eabi
{-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto}
Target is arm-unknown-eabi
Host
rm/simd/mve-vshr.c scan-assembler-times
vshl.s[0-9]+tq[0-9]+, q[0-9]+ 3
FAIL: gcc.target/arm/simd/mve-vshr.c scan-assembler-times
vshl.u[0-9]+tq[0-9]+, q[0-9]+ 3
=== gcc Summary ===
# of expected passes180653
# of unexpected failures316
# of expected fa
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240409
(experimental) [remotes/origin/HEAD r14-9878-g639215c5eb6] (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=114645
--- Comment #21 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Harald van Dijk from comment #18)
> > (In reply to Jonathan Wakely from comment #16)
> > > ... incorrectly though?
> >
> > Given that you
-threading.c scan-tree-dump-times optimized
"Invalid sum" 0
FAIL: outputs-22 exe savetmp namedb-2: outputs.ld1_args
FAIL: 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-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #20 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Jonathan Wakely from comment #16)
> > ... incorrectly though?
>
> Given that you have expressed your view that *any* attempt at using TZ is
On Tue, 09 Apr 2024 09:57:11 PDT (-0700), buga...@gmail.com wrote:
On Tue, Apr 9, 2024 at 7:24 PM Palmer Dabbelt wrote:
> I assume the buildbot failure that I just got an email about is
> unrelated; it's failing on some RISC-V thing.
Sorry if I missed something here, do you have a pointer?
I didn't actually regenerate this as I can't figure out how, I've just
pasted in the diff from the sourceware buildbot (which is complaining
about post-regeneration diff).
Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> I would expect TZ=:Europe/London to work according to POSIX,
Well, POSIX says ":characters" is implementation-defined, but for Glibc it
looks up an IANA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #18 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #16)
> ... incorrectly though?
Given that you have expressed your view that *any* attempt at using TZ is
inherently incorrect, I am not surprised that you view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #17 from Jonathan Wakely ---
And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if
I'm reading it correctly, some European zones and the US zones can be used in
$TZ with libc++ but most IANA zones won't
gcc Summary ===
# of expected passes601806
# of unexpected failures407
# of unexpected successes 59
# of expected failures 4657
# of unsupported tests 10840
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc version 14.0.1
20240409 (experim
Regressions on master at commit r14-9871 vs commit r14-9833 on Linux/x86_64
New failures:
FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #16 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Jonathan Wakely from comment #8)
> > None of libstdc++, LLVM libc++, MSVC STL or the
> > date/tz.h reference implementation uses $TZ for
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m33_eabi-build/408/:
LAST_UPDATED: 2024-04-09T22:34:07+00:00 (master revision
gcc-14-9840-g1162861439f) arm-eabi
{-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto}
Target is arm-unknown-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #15 from Jonathan Wakely ---
(In reply to Hristo Venev from comment #13)
> > $TZ allows you to override it per-process (and even change it during the
> > lifetime of a process by using setenv and tzset). We don't support that for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
On Tue, Apr 9, 2024 at 4:08 PM Sam James wrote:
>
> "H.J. Lu" writes:
>
> > When -fsanitize=address,undefined is used to build, the mmap configure
> > check failed with
>
> I think Paul fixed this in autoconf commit
> 09b6e78d1592ce10fdc975025d699ee41444aa3f, so we should add a comment
> about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Tested x86_64-linux. Richi confirmed this fixes rx-elf bootstrap.
Pushed to trunk.
-- >8 --
If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.
This fixes a build error for targets where __cpp_lib_to_chars is not
https://gcc.gnu.org/g:92b38ec84f2990d217f036dc6c5a32cde5ecfb93
commit r14-9879-g92b38ec84f2990d217f036dc6c5a32cde5ecfb93
Author: Jonathan Wakely
Date: Mon Apr 8 17:37:32 2024 +0100
libstdc++: Fix build for targets without FP std::from_chars [PR114633]
If the faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:92b38ec84f2990d217f036dc6c5a32cde5ecfb93
commit r14-9879-g92b38ec84f2990d217f036dc6c5a32cde5ecfb93
Author: Jonathan Wakely
https://gcc.gnu.org/g:6f4ac1d0611df6e1ab50d6408ecd6f1a3bf78c3d
commit 6f4ac1d0611df6e1ab50d6408ecd6f1a3bf78c3d
Author: Michael Meissner
Date: Tue Apr 9 19:13:55 2024 -0400
Add xvrlw support.
2024-04-09 Michael Meissner
gcc/
* config/rs6000/altivec.md
https://gcc.gnu.org/g:2c5222ca63b78a756e294a45f58806552d1d6d79
commit 2c5222ca63b78a756e294a45f58806552d1d6d79
Author: Michael Meissner
Date: Tue Apr 9 19:12:48 2024 -0400
Revert all changes
Diff:
---
gcc/config/rs6000/altivec.md | 14 -
"H.J. Lu" writes:
> When -fsanitize=address,undefined is used to build, the mmap configure
> check failed with
I think Paul fixed this in autoconf commit
09b6e78d1592ce10fdc975025d699ee41444aa3f, so we should add a comment
about that so we can clean this up in future.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114670
Bug ID: 114670
Summary: `(a ^ 1) <= 3` can be optimized to `a <= 3`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #6 from Andrew Pinski ---
Note fixing the `!A ? B : C` pattern generates worse code in this case but that
is a different issue where we don't convert `a <= 2` into `a == 1` if we know
only 1 could be the value that works (I have a
On 4/9/24 15:22, Sam James wrote:
Paul Eggert writes:
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
To be clear - not saying it's immune.
Sure, but someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
/s390/vector/vec-scalar-cmp-1.c scan-assembler
ne:\\n[^:]*\\twfcdb\\t%v[0-9]*,%v[0-9]*\\n\\t[^:]+\\tlocghine\\t%r2,1
XPASS: gcc.target/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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Bug ID: 114669
Summary: use >= comparison when testing high bits
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Paul Eggert writes:
> On 4/9/24 14:58, Sam James wrote:
>> Meson doesn't allow user-defined functions
>
> Meson has ways to execute arbitrary user-defined code, so it's not
> immune to this sort of exploit.
To be clear - not saying it's immune. Just that it scopes the
user-defined code part to
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
It's of course better (all other things being equal) to use a build
system with a smaller attack surface. However,
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240409
(experimental) [remotes/origin/HEAD r14-9877-g1f719aa7c0d] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
1 - 100 of 466 matches
Mail list logo
