Summary ===
# of expected passes179065
# of unexpected failures116
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4196
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240315
(experimental) [remote
(test for excess
errors)
=== gcc Summary ===
# of expected passes178057
# of unexpected failures148
# of unexpected successes 12
# of expected failures 1597
# of unsupported tests 4973
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Given the large number of AMD GPU ISAs and the number of files which
have to be adapted, I wonder whether it makes sense to consolidate this
a bit, especially in the light that we may want to support more in the
future.
Besides using some macros, I also improved the diagnostic if the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-03-15
CC|
/xgcc version 14.0.1 20240315 (experimental)
[master r14-9490-g90b9872311c] (GCC)
=== gdc tests ===
Running target unix
=== gdc Summary ===
# of expected passes13854
# of unsupported tests 1
/home/toon/scratch/bld2302836/gcc/gdc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Bug ID: 114353
Summary: ICE when passing LTO object files compiled for
x86_64-pc-linux-gnu to x86_64-w64-mingw32-gcc
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240315
[releases/gcc-13 r13-8440-gc471d29aff] (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=108843
--- Comment #5 from David Binderman ---
Created attachment 57711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57711=edit
C source code
Another test case.
foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -O3 bug1023.c)
real
On 15/03/2024 07:35, Richard Biener wrote:
On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
Don't enable excess lanes when inverting vector bit-masks smaller than the
integer mode. This is yet another case of wrong-code due to
Hi Chung-Lin!
I realized: please add "PR libgomp/92840" to the Git commit log, as your
changes are directly a continuation of my earlier changes.
On 2024-03-05T01:18:28+0900, Chung-Lin Tang wrote:
> On 2023/10/31 11:06 PM, Thomas Schwinge wrote:
>>> @@ -691,15 +694,27 @@ goacc_exit_datum_1
Hi!
When backporting r14-9315 to 13 branch, I've noticed I've missed
one letter in a comment. And grepping for similar issues I found
one word with too many.
Committed to trunk as obvious.
2024-03-15 Jakub Jelinek
* lower-subreg.cc (resolve_simple_move): Fix comment typo,
https://gcc.gnu.org/g:30e1c3d7e828b2bf2eee1660661bbc79f4151bd6
commit r14-9495-g30e1c3d7e828b2bf2eee1660661bbc79f4151bd6
Author: Jakub Jelinek
Date: Fri Mar 15 12:20:04 2024 +0100
lower-subreg, edit-context: Fix comment typos
When backporting r14-9315 to 13 branch, I've noticed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #4 from Alex Coplan ---
I think the problem is that the arm backend incorrectly sets the const
attribute on this builtin, but it can't be const because it reads memory (it
should be pure instead):
sizes-gimplified
Given how, at present, the choice of using LSE128 atomic instructions
by the toolchain is delegated to run-time selection in the form of
Libatomic ifuncs, responsible for querying target support, the
`+lse128' target architecture compile-time flag is absent from GCC.
This, however, contrasts with
Regressions on master at commit r14-9486 vs commit r14-9458 on Linux/x86_64
New failures:
FAIL: g++.dg/torture/pr104601.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr104601.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr104601.C -O0 (test for excess errors)
FAIL:
ect/git/gcc-test-master-intel64/bld/gcc/xgcc version 14.0.1
20240315 (experimental) [master r14-9486-gd7d05824ae6] (GCC)
=== gfortran tests ===
Running target unix
=== gfortran Summary for unix ===
# of expected passes69713
# of expected failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #29 from Robin Dapp ---
Yes, that also appears to work here. There was no lto involved this time?
Now we need to figure out what's different with SPEC.
ion 13.2.1 20240315
[releases/gcc-13 r13-8440-gc471d29aff] (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
d failures30
# of unexpected successes 10
# of expected failures 1892
# of unsupported tests 4666
/home/tcwg-buildslave/workspace/tcwg_gnu_2/abe/builds/destdir/aarch64-unknown-linux-gnu/bin/aarch64-unknown-linux-gnu-gcc
version 14.0.1 20240315 (experimental) [master rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #28 from Filip Kastl ---
Created attachment 57710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57710=edit
gcda data for himeno
I've tried sharing non-SPEC gcda data between machines. I used this benchmark
Ping!
Kind regards,
Torbjörn
On 2024-03-08 10:14, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-22 09:51, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 regression] Tor |[13 regression] Tor
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Given that this is a regression, is this okay for gcc 13 and mainline?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup structure. That data structure
assumes that is
On Thu, Jan 25, 2024 at 04:18:19AM -0800, Andi Kleen wrote:
> Some programing styles use a lot of inline assembler, and it is common
> to use very complex preprocessor macros to generate the assembler
> strings for the asm statements. In C++ there would be a typesafe alternative
> using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114160
Christoph Müllner changed:
What|Removed |Added
CC||christophm30 at gmail dot com
---
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 20240315
[remotes/origin/releases/gcc-12 r12-10215-gcaabffc463] (GCC)
=== gcc Summary ===
# of expected passes179065
# of unexpected failures132
# of unexpected successes 19
# of expected failures 1614
# of unsupported tests 4187
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240315
(ex
Hi YunQiang Su,
On Fri, Mar 15, 2024 at 03:33:28PM +0800, YunQiang Su wrote:
> Great work. The CI works well now: it blames me ;)
> https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
>
> When I add '-mstrict-align' option to MIPS,
> the riscv.opt.urls, sysv4.opt.urls,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #16 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ab2da8fb67b1aa0557a16b62689a888730dba610
commit r14-9494-gab2da8fb67b1aa0557a16b62689a888730dba610
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/g:ab2da8fb67b1aa0557a16b62689a888730dba610
commit r14-9494-gab2da8fb67b1aa0557a16b62689a888730dba610
Author: Jakub Jelinek
Date: Fri Mar 15 10:46:47 2024 +0100
i386: Fix a pasto in ix86_expand_int_sse_cmp [PR114339]
In r13-3803-gfa271afb58 I've added an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
--- Comment #12 from Xi Ruoyao ---
(In reply to Dimitrij Mijoski from comment #8)
> This bug manifested at large on Github Actions CI/CI system in the last few
> days most likely because Ubuntu's kernel also got updated to use 32 random
> bits.
# of unexpected failures2
/opt/gcc/gcc-20240315/Build/./gcc/gccgo version 14.0.1 20240315 (experimental)
[master r14-9486-gd7d05824ae68da] (GCC)
=== libgomp tests ===
Running target unix/-mabi=lp64
=== libgomp Summary ===
# of expected passes16260
On 15/03/2024 03:45, Hongtao Liu wrote:
On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
Don't enable excess lanes when inverting vector bit-masks smaller than the
integer mode. This is yet another case of wrong-code due to mishandling
of oversized bitmasks.
This issue shows up in
Summary ===
# of expected passes179065
# 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 20240315
(experimental) [remote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #27 from Robin Dapp ---
Can you try it with a simpler (non SPEC) test? Maybe there is still something
weird happening with SPEC's scripting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 114009, which changed state.
Bug 114009 Summary: [11/12/13/14 Regression] Missed optimization: (!a) * a => 0
when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Fri, Mar 15, 2024 at 9:50 AM Jakub Jelinek wrote:
>
> Hi!
>
> In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
> comparison against CONST_VECTOR. As the comments say:
> /* x <= cst can be handled as x < cst + 1 unless there is
> wrap around in cst + 1.
Oops. Jakub has fixed this now.
On Thu, 14 Mar 2024 at 23:45, wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es). Please find some details below. If you have any questions,
> please follow up on linaro-toolch...@lists.linaro.org mailing list,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
--- Comment #11 from Dimitrij Mijoski ---
(In reply to Sam James from comment #10)
> I don't plan on pursuing it myself, leaving it to someone else, as I can't
> reproduce on my main workstation and I don't want to faff w/ kernel config.
You
https://gcc.gnu.org/g:7dd3b2b09cbeb6712ec680a0445cb0ad41070423
commit r14-9493-g7dd3b2b09cbeb6712ec680a0445cb0ad41070423
Author: Joe Ramsay
Date: Fri Mar 15 09:20:45 2024 +
match.pd: Only merge truncation with conversion for -fno-signed-zeros
This optimisation does not honour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #19 from Dimitar Yordanov ---
I've rerun related tests and they look OK with the latest patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114332
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/g:0319f265eddd17c32cb037b71489d9882a6eb00d
commit r14-9492-g0319f265eddd17c32cb037b71489d9882a6eb00d
Author: Jakub Jelinek
Date: Fri Mar 15 10:10:57 2024 +0100
expand: EXTEND_BITINT CALL_EXPR results [PR114332]
The x86-64 and aarch64 psABIs (and the unwritten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114332
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0319f265eddd17c32cb037b71489d9882a6eb00d
commit r14-9492-g0319f265eddd17c32cb037b71489d9882a6eb00d
Author: Jakub Jelinek
Date:
Hi!
On Thu, Mar 14, 2024 at 04:58:41PM +, Jonathan Wakely wrote:
> Add the [[nodiscard]] attribute to several functions in .
r14-9478 added [[nodiscard]] to various APIs including find_if
the pr104601.C testcase uses. As it is an optimization bug fix testcase,
haven't tried to adjust the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
--- Comment #2 from Richard Biener ---
*** Bug 114351 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/g:8ae7062bf4005c08b093828d40e2c9278e6f6d9c
commit r14-9491-g8ae7062bf4005c08b093828d40e2c9278e6f6d9c
Author: Jakub Jelinek
Date: Fri Mar 15 10:01:41 2024 +0100
testsuite: Fix up pr104601.C for recent libstdc++ changes
r14-9478 added [[nodiscard]] to various
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341
--- Comment #4 from Andrew Pinski ---
(In reply to Kang-Che Sung from comment #3)
> I missed one case that is more obvious:
> (1 << __builtin_ctz(y)) == (y & -y)
>
> Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #26 from Filip Kastl ---
Yes, the "before" is r14-5075-gc05f748218a0d5.
I just tried to take the gcda data and use them to compile mcf on another
machine. I also ran into
output.c:87:1: error: corrupted profile info: number
(test for excess
errors)
=== gcc Summary ===
# of expected passes178057
# of unexpected failures148
# of unexpected successes 12
# of expected failures 1597
# of unsupported tests 4965
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc
On Fri, 15 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The x86-64 and aarch64 psABIs (and the unwritten ia64 psABI part) say that
> the padding bits of _BitInt are undefined, while the expansion internally
> typically assumes that non-mode precision integers are sign/zero extended
> and extends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #6 from rguenther at suse dot de ---
On Fri, 15 Mar 2024, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
>
> --- Comment #5 from Tamar Christina ---
> (In reply to Richard Biener from
On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
>
>
>
> 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.
>
Hi!
In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
comparison against CONST_VECTOR. As the comments say:
/* x <= cst can be handled as x < cst + 1 unless there is
wrap around in cst + 1. */
...
/* For LE punt if some element is
Regressions on master at commit r14-9469 vs commit r14-9451 on Linux/x86_64
New failures:
New passes:
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
LAST_UPDATED: Thu Mar 14 13:30:08 UTC 2024 (revision r14-9469-g9349aefa1df)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/guality/example.c -O0 execution test
XPASS: gcc.dg/guality/example.c -Og -DPREVENT_OPTIMIZATION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341
--- Comment #3 from Kang-Che Sung ---
I missed one case that is more obvious:
(1 << __builtin_ctz(y)) == (y & -y)
Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y)) can
simplify to (y & -y). (I didn't think of a reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114346
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Hi!
The x86-64 and aarch64 psABIs (and the unwritten ia64 psABI part) say that
the padding bits of _BitInt are undefined, while the expansion internally
typically assumes that non-mode precision integers are sign/zero extended
and extends after operations. We handle that mismatch with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #6 from Kang-Che Sung ---
(In reply to Richard Biener from comment #5)
> For canonicalization the BIT_AND variants might be preferable since they
> possibly combine with other logical ops. Also more constant operands
> when the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113466
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi!
While for __mulbitint3 we actually don't negate anything and perform the
multiplication in unsigned style always, for __divmodbitint4 if the operands
aren't unsigned and are negative, we negate them first and then try to
negate them as needed at the end.
quotient is negated if just one of the
Committed below as obvious. The } got lost in my copy from the internal system.
Sorry for the inconvinience.
--
gcc/testsuite/ChangeLog:
PR testsuite/114343
* gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
Added missing } in the dg-bogus comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. We
> basically lack "constant folding" of .LOAD_LANES and similarly of course
> we
https://gcc.gnu.org/g:c471d29affba0d98d5cc6ab044b53f009f35324b
commit r13-8440-gc471d29affba0d98d5cc6ab044b53f009f35324b
Author: Torbjörn SVENSSON
Date: Fri Mar 15 09:25:06 2024 +0100
testsuite: Added missing } in the dg-bogus comment [PR114343]
gcc/testsuite/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
--- Comment #1 from Li Pan ---
Test GCC version:
riscv64-unknown-elf-gcc (GCC) 14.0.1 20240315 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Torbjorn Svensson
:
https://gcc.gnu.org/g:c471d29affba0d98d5cc6ab044b53f009f35324b
commit r13-8440-gc471d29affba0d98d5cc6ab044b53f009f35324b
Author: Torbjörn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #4 from Richard Biener ---
Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. We
basically lack "constant folding" of .LOAD_LANES and similarly of course
we can't see through .STORE_LANES of a constant when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #1 from Sam James ---
ice-on-invalid reduction:
```
struct integral_constant {
} template using __bool_constant integral_constant;
template
, typename, typename > using ExtractOrT integral_constant;
template using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Richard Biener changed:
What|Removed |Added
Known to work||13.2.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
Bug ID: 114352
Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and
build with rv64gc -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351
Bug ID: 114351
Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and
build with rv64gc -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/g:90b9872311ccb24685ba33b6ba6f374d50f03874
commit r14-9490-g90b9872311ccb24685ba33b6ba6f374d50f03874
Author: Jakub Jelinek
Date: Fri Mar 15 09:16:43 2024 +0100
bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice
calls [PR113466]
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113466
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:90b9872311ccb24685ba33b6ba6f374d50f03874
commit r14-9490-g90b9872311ccb24685ba33b6ba6f374d50f03874
Author: Jakub Jelinek
Date:
=== gcc Summary ===
# of expected passes179065
# 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 20240315
(ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #5 from Richard Biener ---
For canonicalization the BIT_AND variants might be preferable since they
possibly combine with other logical ops. Also more constant operands
when the number of operations is the same might be preferable.
Added diagnostics for build_invoke.
Ok for 15?
-- >8 --
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
* semantics.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #15 from Jakub Jelinek ---
Oh, and maybe if you want for performance reasons to avoid computing
irange_bitmask unless necessary, in cases like where irange_bitmask wasn't set
before verify if it is really different from the bitmask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114350
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #14 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #13)
> And yes Jakub, as you have noticed, BIT_IOR_EXPR, BIT_XOR_EXPR, and likely
> other operators may need to be tweaked to take bitmasks into account. I
>
Summary ===
# of expected passes179065
# 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 20240315
(experimental) [remote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114350
Bug ID: 114350
Summary: missing support for SVE widening floating point
conversion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #13 from Aldy Hernandez ---
I think y'all have it all figured out. Basically,
operator_cast::op1_range() is solving num_5 in the equation:
[111,111] = (short int) num_5
Where lhs is:
(gdb) p debug(lhs)
[irange] short int [111,
Hello GCC Community,
I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
Science and Engineering. I am interested in contributing to the GCC
projects under GSoC, specifically the projects :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> Oh VN does have some knowledge of MASK_STORE and LEN_STORE. Just not
> LOAD_LANES .
>
>
> See PR 106365 for MASK_STORE and LEN_STORE implementation.
On Fri, Mar 15, 2024 at 6:20 AM Andi Kleen wrote:
>
> Andrew Pinski writes:
>
> > On Thu, Mar 14, 2024 at 9:36 PM Andi Kleen wrote:
> >>
> >>
> >> musttail support for C/C++
> >>
> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html
> >>
> >>
> >> Support constexpr for asm
On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
>
> On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
> >
> > Don't enable excess lanes when inverting vector bit-masks smaller than the
> > integer mode. This is yet another case of wrong-code due to mishandling
> > of oversized bitmasks.
Great work. The CI works well now: it blames me ;)
https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
When I add '-mstrict-align' option to MIPS,
the riscv.opt.urls, sysv4.opt.urls, xtensa.opt.urls are changed also.
(why they are effected?
So what's the best practice for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
Consolidated most patches into one for easier review and added
documentation for all missing built-in traits.
Ok for trunk?
-- >8 --
This patch arranges pre-existing built-in traits alphabetically for
better codebase consistency and easier future integration of changes.
gcc/ChangeLog:
PR c++/87343
gcc/ChangeLog:
* doc/extend.texi (Expression-yielding Type Traits): New
subsection.
(Type-yielding Type Traits): Likewise.
(C++ Concepts): Move __is_same to ...
(Expression-yielding Type Traits): ... here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Bug ID: 114349
Summary: [14 regression] ICE when building qtwebengine
(cxx_eval_call_expression, at cp/constexpr.cc:3027)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348
--- Comment #2 from Tobias Specht ---
>From my understanding, the idea of the `-fdiagnostics-format=sarif-stderr`
option is, that the SARIF file will be printed to stderr and only the SARIF
file, so that one can take the stderr output and parse
201 - 300 of 326 matches
Mail list logo
