https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
--- Comment #1 from Andrew Pinski ---
This is a devirtualization issue ...
Let me find the dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Bug ID: 114643
Summary: Call to a template function emitted but without the
code for the template function itself
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #75 from Martin Jambor ---
The above fixes the testcase from comment #58. I am not sure if any other
testcases discussed here remain unresolved. I am also not sure to what extent
we want to that patch of mine, I guess I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] LTO |[13 Regression] LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #26 from Martin Jambor ---
This should be fixed on master, I'll backport the fix in a few weeks to at
least gcc-13 where it was reported.
uccesses 12
# of expected failures 1597
# of unsupported tests 5021
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240408
(experimental) [remotes/origin/HEAD r14-9835-g97069657c4] (GCC)
=== gfortran tests ===
ary ===
# of expected passes154085
# of unexpected failures140
# of unexpected successes 3
# of expected failures 902
# of unresolved testcases 28
# of unsupported tests 5187
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #25 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1e3312a25a7b34d6e3f549273e1674c7114e4408
commit r14-9841-g1e3312a25a7b34d6e3f549273e1674c7114e4408
Author: Martin Jambor
Date:
https://gcc.gnu.org/g:1e3312a25a7b34d6e3f549273e1674c7114e4408
commit r14-9841-g1e3312a25a7b34d6e3f549273e1674c7114e4408
Author: Martin Jambor
Date: Mon Apr 8 18:53:23 2024 +0200
ICF: Make ICF and SRA agree on padding
PR 113359 shows that (at least with -fno-strict-aliasing) ICF
https://gcc.gnu.org/g:1162861439fd3c4b30fc3ccd49462e47e876f04a
commit r14-9840-g1162861439fd3c4b30fc3ccd49462e47e876f04a
Author: Martin Jambor
Date: Mon Apr 8 18:53:23 2024 +0200
ipa: Compare jump functions in ICF (PR 113907)
In PR 113907 comment #58, Honza found a case where ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #74 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1162861439fd3c4b30fc3ccd49462e47e876f04a
commit r14-9840-g1162861439fd3c4b30fc3ccd49462e47e876f04a
Author: Martin Jambor
Date:
Patch v2.
I realised that it's not only negative delim values that cause the
problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
will cause traits_type::find to match 'a' but then the eq_int_type
comparison will fail because (int)'a' != (int)('a' + 256).
This version of the
I recently disabled _Utf8_view for -fno-char8_t, but we can just make it
use char instead of char8_t. The existing uses of it in the library are
unaffected.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Instead of just omitting the definition of __unicode::_Utf8_view when
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Adjust expected errors or skip tests as UNSUPPORTED if -fno-char8_t is
used in the test flags.
libstdc++-v3/ChangeLog:
* testsuite/20_util/integer_comparisons/equal_neg.cc: Use
no-opts selector for errors that
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:feb6a2d3569095706170c9400e93add27a66e034
commit r14-9839-gfeb6a2d3569095706170c9400e93add27a66e034
Author: Jonathan Wakely
https://gcc.gnu.org/g:feb6a2d3569095706170c9400e93add27a66e034
commit r14-9839-gfeb6a2d3569095706170c9400e93add27a66e034
Author: Jonathan Wakely
Date: Tue Apr 2 22:46:55 2024 +0100
libstdc++: Use char for _Utf8_view if char8_t isn't available [PR114519]
Instead of just omitting
https://gcc.gnu.org/g:cd77e152875d3bc9c8966fc20241d73aa47532b3
commit r14-9838-gcd77e152875d3bc9c8966fc20241d73aa47532b3
Author: Jonathan Wakely
Date: Tue Apr 2 20:53:11 2024 +0100
libstdc++: Fix tests that fail with -fno-char8_t
Adjust expected errors or skip tests as
https://gcc.gnu.org/g:87bc20676ce606b0f75f12a35b24206df05a9f0a
commit r14-9837-g87bc20676ce606b0f75f12a35b24206df05a9f0a
Author: Jonathan Wakely
Date: Tue Apr 2 21:22:01 2024 +0100
libstdc++: Combine two std::from_chars tests into one
We don't need separate tests for the C++17
On Mon, Apr 8, 2024 at 6:29 PM Richard Biener wrote:
>
>
>
> > Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
> >
> > On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> PR middle-end/114604
> *
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
Best regards,
Pierre-Emmanuel
--
Prevent rust language from building when cargo is
missing.
config/ChangeLog:
* acx.m4:
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
Best regards,
Pierre-Emmanuel
--
Prevent rust language from building when cargo is
missing.
config/ChangeLog:
* acx.m4:
https://gcc.gnu.org/g:2123589bb1fed4fe083ccb58ff96d249a7ad603b
commit 2123589bb1fed4fe083ccb58ff96d249a7ad603b
Author: Michael Meissner
Date: Mon Apr 8 12:37:53 2024 -0400
Update ChangeLog.*
Diff:
---
gcc/ChangeLog.test | 173 +
1 file
https://gcc.gnu.org/g:079fec07cd162dcbabad089c5d5298143a3669f9
commit 079fec07cd162dcbabad089c5d5298143a3669f9
Author: Michael Meissner
Date: Mon Apr 8 12:35:00 2024 -0400
Add power10 wide immediate fusion
2024-04-08 Michael Meissner
gcc/
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113006
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
> Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
>
> On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>>
>> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
PR middle-end/114604
* gimple-range.cc (enable_ranger): Initialize the global
12/gcc/xgcc version 12.3.1 20240408
[releases/gcc-12 r12-10315-g98374792dc] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/default_format_2.f90 -O0 execution test
XPASS: gfortran.dg/default_format_2.f90 -O1 execution test
XPASS: gfortran.dg/defaul
On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>
> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > > PR middle-end/114604
> > > * gimple-range.cc (enable_ranger): Initialize the global
> > > bitmap obstack.
> > > (disable_ranger): Release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
--- Comment #2 from Richard Sandiford ---
Fixed on trunk. I'll backport in a few weeks if there's no fallout.
Not sure how this happend, but: svsudot is supposed to be expanded
as USDOT with the operands swapped. However, a thinko in the
expansion of svsudot meant that the arguments weren't in fact
swapped; the attempted swap was just a no-op. And the testcases
blithely accepted that.
Tested on
On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > PR middle-end/114604
> > * gimple-range.cc (enable_ranger): Initialize the global
> > bitmap obstack.
> > (disable_ranger): Release it.
> > ---
> > gcc/gimple-range.cc | 4
> > 1 file changed,
https://gcc.gnu.org/g:2c1c2485a4b1aca746ac693041e51ea6da5c64ca
commit r14-9836-g2c1c2485a4b1aca746ac693041e51ea6da5c64ca
Author: Richard Sandiford
Date: Mon Apr 8 16:53:32 2024 +0100
aarch64: Fix expansion of svsudot [PR114607]
Not sure how this happend, but: svsudot is supposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2c1c2485a4b1aca746ac693041e51ea6da5c64ca
commit r14-9836-g2c1c2485a4b1aca746ac693041e51ea6da5c64ca
Author: Richard Sandiford
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".
The branch, master has been updated
via 7cd7e13e443da8e2aae389fa30eb547530c6e2c8 (commit)
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112616
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
Date: Mon Apr 8 17:34:33 2024 +0200
ipa: Self-DCE of uses of removed call LHSs (PR 108007)
PR 108007 is another manifestation where we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
--- Comment #23 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
Regressions on native/master at commit r14-9833 vs commit r14-9823 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: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
=== gcc Summary ===
# of expected passes49479
# of unexpected failures197
# of unexpected successes 5
# of expected failures 56
# of unsupported tests 1464
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc version
14.0.1 20240408 (e
LAST_UPDATED: Mon Apr 8 13:40:05 UTC 2024 (revision r14-9833-g278cad85077)
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
Define following macros for APX options:
1. __APX_EGPR__: -mapx-features=egpr.
2. __APX_PUSH2POP2__: -mapx-features=push2pop2.
3. __APX_NDD__: -mapx-features=ndd.
4. __APX_PPX__: -mapx-features=ppx.
5. __APX_INLINE_ASM_USE_GPR32__: -mapx-inline-asm-use-gpr32.
They can be used to make assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Xi Ruoyao changed:
What|Removed |Added
CC||teodor_spaeren at riseup dot
net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114637
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
On Mon, Apr 8, 2024 at 11:50 AM Richard Biener wrote:
>
> The following fixes ranger bitmap allocation when invoked from IPA
> context where the global bitmap obstack possibly isn't initialized.
> Instead of trying to use one of the ranger obstacks the following
> simply initializes the global
On 03/04/2024 14:23, Christophe Lyon via Gcc wrote:
> On Wed, 3 Apr 2024 at 14:59, Joel Sherrill wrote:
>>
>> Another possible issue which may be better now than in years past
>> is that the versions of autoconf/automake required often had to be
>> installed by hand. I think newlib has gotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
Bug ID: 114642
Summary: new test case gcc.dg/debug/btf/btf-datasec-3.c from
r14-6195-gb8cf266f4ca4ff fails for 32 bits
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #7 from rguenther at suse dot de ---
> Am 08.04.2024 um 16:55 schrieb tnfchris at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
>
> --- Comment #6 from Tamar Christina ---
> (In reply to Jakub
5241
# of unsupported tests 23129
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240408
(experimental) [master r14-9833-g278cad8507] (GCC)
=== gcc tests ===
Running target unix/-m32
FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
Bug ID: 114641
Summary: sh: fdpic optimization of function address breaks
pointer equality
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
ion 13.2.1 20240408
[releases/gcc-13 r13-8593-gc5a5bdf3b9] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/default_format_2.f90 -O0 execution test
XPASS: gfortran.dg/default_format_2.f90 -O1 execution test
XPASS: gfortran.dg/default_format_2.f90 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #6 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Now, with SVE/RISCV vectors the actual vectorization factor is a poly_int
> rather than constant. One possibility would be to use VLA arrays in those
>
2079
# 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 20240408
[remotes/origin/releases/gcc-12 r12-10315-g98374792dc] (GCC)
A new failure has been detected on builder gcc-autoregen while building gcc.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/269/builds/4193
Build state: failed 'git diff ...' (failure)
Revision: 97069657c4e40b209c7b774e12faaca13812a86c
Worker: bb1-1
Build
LAST_UPDATED: Sat Apr 6 23:23:55 UTC 2024 (revision r14-9823-g4e3c8257304)
Native configuration is powerpc-ibm-aix7.2.5.0
=== g++ tests ===
Running target unix
FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute
XPASS: g++.dg/debug/pr46583.C -gdwarf-2 -g1
Committed to trunk, thanks Tatsuyuki!
On Fri, Mar 29, 2024 at 2:32 PM Kito Cheng wrote:
>
> Hi Tatsuyuki:
>
> Thanks for your hard work and keep updating, the patch set is LGTM, I
> plan to commit this next week if no further comments :)
>
> Hi MaskRay:
>
> Thanks for your review on the
https://gcc.gnu.org/g:97069657c4e40b209c7b774e12faaca13812a86c
commit r14-9835-g97069657c4e40b209c7b774e12faaca13812a86c
Author: Tatsuyuki Ishi
Date: Fri Mar 29 14:52:39 2024 +0900
RISC-V: Implement TLS Descriptors.
This implements TLS Descriptors (TLSDESC) as specified in [1].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d5d84487dec06186fd9246b505f44ef68a66d6a2
commit r14-9834-gd5d84487dec06186fd9246b505f44ef68a66d6a2
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/g:d5d84487dec06186fd9246b505f44ef68a66d6a2
commit r14-9834-gd5d84487dec06186fd9246b505f44ef68a66d6a2
Author: Jakub Jelinek
Date: Mon Apr 8 16:22:13 2024 +0200
s390: Fix s390_const_int_pool_entry_p and movdi peephole2 [PR114605]
The following testcase is
Here are two more patches for the condition coverage.
Inlined conditions are actually counted this time, as the recorded
expression mapping uses the new, deep-copied gconds as keys and not the
pointers from the source function.
The reported UB is gone when the number of conditions are exactly 64
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
constant for the next iteration at the end of the loop body, even if there
was never a next
Properly add the condition -> expression mapping of inlined gconds from
the caller into the callee map. This is a fix for PR114599 that works
beyond fixing the segfault, as the previous fixed copied references to
the source gconds, not the deep copied ones that end up in the calle
body.
The new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
--- Comment #3 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #1)
> Note we get 2 difference ICEs depending on if `#if ` is 1 or 0.
> It seems like it would be useful if some more torture tests for _BitInt were
> included so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
failures 3852
# of unsupported tests 20896
/home/gccbuild/build/nightly/build-gcc-12/gcc/xg++ version 12.3.1 20240408
[remotes/origin/releases/gcc-12 r12-10315-g98374792dc] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/uninit-pred-7_a.c bogus
an/ieee128-math.f90 -O (test for excess
errors)
=== gcc Summary ===
# of expected passes179287
# of unexpected failures114
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4244
/home/gccbuild/build/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Victor Do Nascimento changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |victorldn at gcc dot
On Mon, 8 Apr 2024, 13:00 Matheus Afonso Martins Moreira via Gcc, <
gcc@gcc.gnu.org> wrote:
>
> Compiler support for system calls help by eliminating the need for the
> system call stub functions traditionally provided by these C libraries.
> There's no need to link against the C libraries just
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240408
(experimental) [remotes/origin/HEAD r14-9831-g1a96eb0a431] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
Hi!
The
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Richard Ball writes:
> Hi all,
>
> Adding the NEON-SVE bridge intrinsics that were missed
> in the last patch.
>
> Thanks,
> Richard
OK, thanks.
Richard
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index
>
LAST_UPDATED: Mon Apr 8 04:30:04 UTC 2024 (revision r12-10314-g88abe04de2f)
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)
FAIL: gcc.dg/analyzer/torture/conftest-1.c -O0 (test
Regressions on releases/gcc-12 at commit r12-10314 vs commit r12-10303 on
Linux/x86_64
New failures:
FAIL: gcc.dg/vect/vect-bic-bitmask-3.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-bic-bitmask-4.c -flto -ffat-lto-objects (test for excess
errors)
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640
--- Comment #1 from simon at pushface dot org ---
It turns out that the error does not occur if I change
if First_Term = Invalid_Node_Access then
-- Empty or all virtual
return
> There is quite a bit of variance in how the kernel is entered.
I assume you mean the vDSO. It is also documented and stable.
https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#vdso
> Unless otherwise noted, the set of symbols with any given version
> and the ABI of those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #28 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640
Bug ID: 114640
Summary: ICE on 'elsif' with complex function call
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
On 4/8/24 3:55 AM, Kewen.Lin wrote:
> on 2024/4/6 06:28, Peter Bergner wrote:
>> +mno-direct-move
>> +Target Undocumented WarnRemoved
>> +
>> mdirect-move
>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>> +Target Undocumented WarnRemoved
>
> When reviewing my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
Priority|P3
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m3_eabi-build/385/:
LAST_UPDATED: 2024-04-08T12:33:40+00:00 (master revision
gcc-14-9830-gb93836d5ca3) arm-eabi
{-mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto}
Target is arm-unknown-eabi
Host is
Hi,
I've been working on strengthening auto-vectorization on intel CPUs
recently. I tried to do it in the GIMPLE pass. And I noticed that some
vector types in the GIMPLE code are confusing to me. The example code
is here:
_1 = MEM[(const __m256i_u * {ref-all})_2];
I wondered how I could
Hi all,
Adding the NEON-SVE bridge intrinsics that were missed
in the last patch.
Thanks,
Richarddiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
9fd224c1df3f05eadcedaaa41c0859e712b93b78..df63af48298564de9c35bab1dd35891c2581e3d6
100644
--- a/htdocs/gcc-14/changes.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #26 from rguenther at suse dot de ---
On Mon, 8 Apr 2024, douglas.boffey at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
>
> --- Comment #25 from Douglas Boffey ---
> (In reply to rguent...@suse.de
https://gcc.gnu.org/g:278cad85077509b73b1faf32d36f3889c2a5524b
commit r14-9833-g278cad85077509b73b1faf32d36f3889c2a5524b
Author: Swinney, Jonathan
Date: Mon Apr 8 14:02:33 2024 +0100
aarch64: Fix vld1/st1_x4 intrinsic test
The test for this intrinsic was failing silently and so
"Swinney, Jonathan" writes:
> The test for this intrinsic was failing silently and so it failed to
> report the bug reported in 114521. This patch modifes the test to
> report the result.
>
> Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114521
>
> Signed-off-by: Jonathan Swinney
>
On Mon, 8 Apr 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> >> There is quite a bit of variance in how the kernel is entered. On
> >> x86-64, one once popular mechanism is longer present in widely-used
> >> kernels.
> >
> > I assume you're implicitly referencing the vsyscall
git commit g:97d5cd8740384dbce5a83080916388f80d8976dd
gcc-descr r14-9829-g97d5cd8740384d
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: Mon Apr 8 11:28:53 UTC 2024
git commit g:97d5cd8740384dbce5a83080916388f80d8976dd
gcc-descr r14-9829-g97d5cd8740384d
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: Mon Apr 8 10:50:39 UTC 2024
https://gcc.gnu.org/g:080cac15ce0c3e6b396b9161055cb76974882c07
commit r14-9832-g080cac15ce0c3e6b396b9161055cb76974882c07
Author: Jakub Jelinek
Date: Mon Apr 8 14:46:30 2024 +0200
ChangeLog: Add by hand ChangeLog entry for PR114361 revert.
This commit has been added to
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, April 8, 2024 9:43 PM
> To: Jiang, Haochen
> Cc: Hongtao Liu ; gcc-patches@gcc.gnu.org; Liu, Hongtao
> ; ubiz...@gmail.com
> Subject: Re: [PATCH] i386: Fix aes/vaes patterns [PR114576]
>
> On Mon, Apr 08, 2024 at 12:33:39PM
On Mon, Apr 08, 2024 at 12:33:39PM +, Jiang, Haochen wrote:
> Sorry for the late response since I am on vacation for now.
>
> > As the following testcase shows, the above change was incorrect.
> >
> > Using aes isa for the second alternative is obviously wrong, aes is enabled
> > whenever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #5 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> As for the dependence analysis itself - the issue is that the D.5606[_33]
> style accesses have no access functions - I'm not sure how they evolve,
> but I see
Hi Jakub,
Sorry for the late response since I am on vacation for now.
> As the following testcase shows, the above change was incorrect.
>
> Using aes isa for the second alternative is obviously wrong, aes is enabled
> whenever -maes is, regardless of -mavx or -mno-avx, so the above change
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #25 from Douglas Boffey ---
(In reply to rguent...@suse.de from comment #24)
> dumpbin /headers executable.exe
...
C0 size of stack reserve
1000 size of stack commit
...
Hope this helps.
301 - 400 of 530 matches
Mail list logo
