Mark Wielaard writes:
Hello Mark!
> gcc-patches, binutils and gdb-patches all have only one moderator
> (Jeff, Ian and Thiago). It would probably be good if there were
> more.
>
> Any volunteers? It shouldn't be more than 1 to 3 emails a week
> (sadly most of them spam).
If still needed, I
On Thu, 4 Apr 2024 at 10:12, Jan Beulich wrote:
>
> On 03.04.2024 15:11, Christophe Lyon wrote:
> > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote:
> >>
> >> On 03.04.2024 10:22, Christophe Lyon wrote:
> >>> Dear release managers and developers,
> >>>
> >>> TL;DR: For the sake of improving
Hi Mark,
On 4/4/24 23:35, Mark Wielaard wrote:
Hi Christophe,
On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote:
TL;DR: For the sake of improving precommit CI coverage and simplifying
workflows, I’d like to request a patch submission policy change, so
that we now
On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the following gimple function:
>
> int f ()
> {
> int x;
> int D.2747;
> int _2;
>
>:
> x_1 = 42;
> _2 = x_1;
>
>:
> :
> return
On Tue, Apr 2, 2024 at 1:16 PM Richard Biener
wrote:
>
> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc
> wrote:
> >
> > Forgot to CC the mailing list - mea culpa.
> >
> > -- Forwarded message -
> > From: Thor Preimesberger
> > Date: Tue, Apr 2, 2024 at 5:57 PM
> >
On 05/04/2024 14:46, Richard Biener wrote:
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>> Hi all,
>>
>> I do have a question regarding ssa_name and result_decl.
>>
>> For example on the following gimple function:
>>
>> int f ()
>> {
>> int x;
>> int D.2747;
>> int _2;
>>
>>
Hi all,
I do have a question regarding ssa_name and result_decl.
For example on the following gimple function:
int f ()
{
int x;
int D.2747;
int _2;
:
x_1 = 42;
_2 = x_1;
:
:
return _2;
}
On the above example, using the macro SSA_NAME_VAR() on _2 does not
yield anything
Hello,
On Fri, Apr 05 2024, Richard Biener via Gcc wrote:
> On Tue, Apr 2, 2024 at 1:16 PM Richard Biener
> wrote:
>>
>> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc
>> wrote:
>> >
>> > Forgot to CC the mailing list - mea culpa.
>> >
>> > -- Forwarded message -
>>
Hello,
I am a potential contributor for GSoC 2024, I made a submission for the
project Extend the Static Analysis Pass, I was wondering about the process
of ranking the proposals and the general timelines when the applicants will
be notified if their proposals will be considered potentially? Would
Hello GCC Community,
I am Pranil Dey and I had submitted a proposal for the project "Improve
nothrow detection in GCC", but as the deadline period was a holiday time I
wanted to ask you to review my proposal now.
I am already getting familiar with the code but I wanted some pointers for
now till
>
>
>
> > I think the key difference here is that Autotools allows arbitrarily
> generated code to be executed at any time. More modern build systems
> require the use of specific commands/files to run arbitrary code, e.g.
> CMake (IIRC [`execute_process()`][2] and [`ExternalProject`][3]), Meson
>
Hey all,
I just checked, and it does appear to be the case that proposals can't be
updated anymore.
I do agree with all the proposed amendments (and would pick to move JSON to
HTML), and I'll double-check to see if there's a way to push them into the
application.
I'm on JST for right now, if my
Snapshot gcc-12-20240405 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240405/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #18 from Martin Uecker ---
>
> + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> As has been discussed, this is wrong, it should have been
> TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS
> (x));
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
Hello Alex/Richard:
All review comments are incorporated.
Common infrastructure of load store pair fusion is divided into target
independent and target dependent changed code.
Target independent code is the Generic code with pure virtual function
to interface betwwen target independent and
s/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
version 14.0.1 20240405 (experimental) [master revision
gcc-14-9802-geffd947fcc2] (GCC)
Host is x86_64-pc-linux-gnu
=== g++ tests ===
Running target qemu/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
FAIL: c-c++-common/a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88371
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> Looks to be fixed in GCC 10+.
Indeed... mark this as RESOLVED FIXED perhaps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/g:12b04452b40d49bb5322653cb5716b1ebf71b73d
commit r14-9800-g12b04452b40d49bb5322653cb5716b1ebf71b73d
Author: Christophe Lyon
Date: Thu Apr 4 16:18:52 2024 +
go: Add go.install-dvi rule in go/Make-lang.in
go has a go.dvi build rule, but lacks the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #17 from Jakub Jelinek ---
Some comments:
+ else
+{
+ TYPE_CANONICAL (t) = t;
+}
The formatting here is wrong, TYPE_CANONICAL is indented too much, but we also
don't put a single statement between {}s, so just
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi!
When looking at maybe_warn_for_constant_evaluated for the trivial
infinite loops patch, I've noticed that it can emit weird diagnostics
for if constexpr in templates, first warn that std::is_constant_evaluted()
always evaluates to false (because the function template is not constexpr)
and
Hello Alex:
On 03/04/24 8:51 pm, Alex Coplan wrote:
> 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.
1
/opt/gcc/gcc-20240405/Build/./gcc/gccgo version 14.0.1 20240405 (experimental)
[master r14-9799-g4c8b3600c4856f] (GCC)
=== libgomp tests ===
Running target unix/-mabi=lp64
=== libgomp Summary ===
# of expected passes16260
# of expected
On Fri, 5 Apr 2024, Jakub Jelinek wrote:
> On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
> > This is a mostly straight port from the gcov-19.c tests from the C test
> > suite. The only notable differences from C to D are that D flips the
> > true/false outcomes for loop
==
# of expected passes166466
# of unexpected failures303
# of unexpected successes 4
# of expected failures 974
# of unresolved testcases 12
# of unsupported tests 9336
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gn
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date: Fri Apr 5 10:16:41 2024 +0200
middle-end/114599 - fix bitmap allocation for
check_ifunc_callee_symtab_nodes
There's no default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #16 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #4 from Tobias Burnus ---
> For selector construct = {teams, parallel, for}
> score1 = 29 score2 = 29
> ---
>
> The constructs[i]'s score look fine.
>
> But I wonder why score == 29 and not 28.
Answer:
https://gcc.gnu.org/g:8057f9aa1f7e70490064de796d7a8d42d446caf8
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Date: Fri Apr 5 12:14:56 2024 +0200
Revert "Fix ICE with -g and -std=c23 related to incomplete types [PR114361]"
This reverts commit
Hi!
On Tue, Mar 26, 2024 at 11:55:41AM +, Wilco Dijkstra wrote:
> * acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128.
> * configure: Regenerated.
Seems configure hasn't been regenerated properly after the last
acinclude.m4 change as e.g. noticed by the autoregen CI.
I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
---
failures 3852
# of unsupported tests 20896
/home/gccbuild/build/nightly/build-gcc-12/gcc/xg++ version 12.3.1 20240405
[remotes/origin/releases/gcc-12 r12-10313-g0611f48001] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/uninit-pred-7_a.c bogus
On 5 April 2024 03:03:05 CEST, "H.J. Lu" wrote:
>On Thu, Apr 4, 2024 at 5:34 PM wrote:
>>
>> On 3 April 2024 15:49:13 CEST, "H.J. Lu" wrote:
>
>> + /* Skip if it has been visited. */
>> + unsigned int uid = e->caller->get_uid ();
>> + if (bitmap_bit_p (ifunc_ref_map, uid))
>> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:592536eb3c0a97a55b1019ff0216ef77e6ca847e
commit r14-9801-g592536eb3c0a97a55b1019ff0216ef77e6ca847e
Author: Jakub Jelinek
Date:
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240405
[releases/gcc-13 r13-8588-g7f6792487b] (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/g:592536eb3c0a97a55b1019ff0216ef77e6ca847e
commit r14-9801-g592536eb3c0a97a55b1019ff0216ef77e6ca847e
Author: Jakub Jelinek
Date: Fri Apr 5 09:31:28 2024 +0200
c++: Fix ICE with weird copy assignment operator [PR114572]
While ctors/dtors don't return anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4
Hi!
Here is a new version of the PR114462 P2809R3 patch.
As clarified on core, for trivially empty iteration statements
(where the condition isn't empty or INTEGER_CST, because those
loops can't contain std::is_constant_evaluated() in the condition
and the middle-end handles them right even with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
--- Comment #5 from wierton <141242068 at smail dot nju.edu.cn> ---
(In reply to Xi Ruoyao from comment #4)
> I believe the second form is still incorrect and it just works by luck. To
> ensure it work you have to do:
>
> asm("mov
an/ieee128-math.f90 -O (test for excess
errors)
=== gcc Summary ===
# of expected passes179279
# 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=114596
--- Comment #3 from Tobias Burnus ---
The scoring is according to TR12:
> Each trait selector for which the corresponding trait appears
> in the construct trait set in the OpenMP context is given the
> value 2^(p−1) where p is the position of
5241
# of unsupported tests 23123
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240405
(experimental) [master r14-9801-g592536eb3c] (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=114600
--- Comment #1 from m.cencora at gmail dot com ---
gcc version info:
g++-14 (Ubuntu 14-20240330-1ubuntu2) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see
Christophe Lyon writes:
> m2 has a m2.dvi build rule, but lacks the m2.install-dvi one.
>
> 2024-04-04 Christophe Lyon
>
> gcc/m2/
> * Make-lang.in (m2.install-dvi): New rule.
> ---
> gcc/m2/Make-lang.in | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
Regressions on master at commit r14-9799 vs commit r14-9780 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
of unsupported tests 3433
=== gcc Summary ===
# of expected passes601730
# of unexpected failures401
# of unexpected successes 59
# of expected failures 4657
# of unsupported tests 10816
/export/project/git/gcc-test-master-intel64/b
uccesses 12
# of expected failures 1597
# of unsupported tests 5021
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9799-g4c8b3600c4] (GCC)
=== gfortran tests ===
On Thu, 4 Apr 2024, Tamar Christina wrote:
> Hi All,
>
> The report shows that we end up in a situation where the code has been peeled
> for gaps and we have an early break.
>
> The code for peeling for gaps assume that a scalar loop needs to perform at
> least one iteration. However this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #2 from Tobias Burnus ---
Crossref to the OpenMP spec discussions [not publicly available]
related to the scoring:
* Jakub asked about this testcase in an omp-lang in the email 2019/016447.html
(w/o getting a reply.
* He then
5241
# of unsupported tests 23123
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240405
(experimental) [master r14-9800-g12b04452b4] (GCC)
=== gcc tests ===
Running target unix/-m32
FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
PR middle-end/114599
* symtab.cc (ifunc_ref_map): Do not use auto_bitmap.
(is_caller_ifunc_resolver): Optimize
f expected failures 1550
# of unsupported tests 3992
/home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc version 13.2.1 20240405
[releases/gcc-13 r13-8588-g7f6792487b] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2
On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary
https://gcc.gnu.org/g:effd947fcc2bbe0dfbc7d470eab4bc65bd9b46c8
commit r14-9802-geffd947fcc2bbe0dfbc7d470eab4bc65bd9b46c8
Author: Jakub Jelinek
Date: Fri Apr 5 11:05:01 2024 +0200
testsuite: Fix up error on gcov1.d
On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114511
--- Comment #2 from Richard Biener ---
Confirmed.
_3 = _1 + _2;
y = _3;
_18 = b_9(D) + c_12(D);
_19 = _18 - a_8(D);
_20 = _3 + _19;
_6 = _20 - _1;
re-association doesn't associate the def of _3 because it has multiple uses
and
Hi!
The following testcase is miscompiled, because in the vectorized
epilogue the vectorizer assumes it can use aligned loads/stores
(if the base decl gets alignment increased), but it actually doesn't
increase that.
This is because r10-4203-g97c1460367 added the hunk following
patch removes.
https://gcc.gnu.org/g:9627cbbadbb935943c3d8336c057a021bbac2000
commit r14-9804-g9627cbbadbb935943c3d8336c057a021bbac2000
Author: Jakub Jelinek
Date: Fri Apr 5 12:15:06 2024 +0200
libatomic: Regenerate configure properly
Seems configure hasn't been regenerated properly after the
q[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 passes180639
# of unexpected failures313
# of expected failures 1256
# of unresolved testcases 20
# of u
Hi!
While ctors/dtors don't return anything (undeclared void or this pointer
on arm) and copy assignment operators normally return a reference to *this,
it isn't invalid to return uselessly some class object which might need
destructing, but the OpenMP clause handling code wasn't expecting that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #22 from Jakub Jelinek ---
BTW, wonder if it wouldn't be desirable to revert the PR114361 patch until this
is sorted out, or at least limit the effects of that patch to flag_isoc23 and
using multiple types with the same tag and same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|missed
A failed build has been detected on builder gcc-autoregen while building gcc.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/269/builds/4161
Build state: failed 'git diff ...' (failure)
Revision: 9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Worker: bb2-1
Build
an/ieee128-math.f90 -O (test for excess
errors)
=== gcc Summary ===
# of expected passes179279
# 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=114574
--- Comment #21 from Jakub Jelinek ---
Why? That is already set by
TYPE_CANONICAL (t) = *e;
else
{
TYPE_CANONICAL (t) = t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9800-g12b04452b40] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
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 8765e9c73ae14cfad592b8a3885fe1bcc3ff96cd (commit)
via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #23 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:8057f9aa1f7e70490064de796d7a8d42d446caf8
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|FIXED |---
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #16 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Marking for 14 as well because I believe the trunk commit just made it
> > latent there rather than fixed.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #19 from Jakub Jelinek ---
(In reply to Martin Uecker from comment #18)
> I am just looking at a version that would have changed the condition to:
>
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #20 from Martin Uecker ---
(In reply to Martin Uecker from comment #18)
> >
> > + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> > As has been discussed, this is wrong, it should have been
> > TYPE_CANONICAL (x) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Bug ID: 114600
Summary: [modules] redefinition errors when using certain std
headers in GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
uccesses 12
# of expected failures 1597
# of unsupported tests 5021
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9801-g592536eb3c] (GCC)
=== gfortran tests ===
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9803-g9ab8fdfeef5] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_
Hello,
On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford
wrote:
> I don't know if you're waiting on me, but just in case: this and patch 3
> still LGTM if Thomas is OK with them.
Thanks. Thomas asked me to resubmit with Changelog entries added (but
hasn't pointed out anything else), so this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Patrick Palka changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org,
FAIL: gcc.target/arm/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 passes158953
# of unexpected failures238
# of ex
The following makes sure to only compute upper bounds for the number
of iterations of loops from undefined behavior invoked by stmts when
those are executed in each loop iteration, in particular also in the
last one. The latter cannot be guaranteed if there's possible
infinite loops or calls with
LAST_UPDATED: Tue Apr 2 06:45:13 UTC 2024 (revision b253b4695dd)
Native configuration is powerpc64-suse-linux-gnu
=== g++ tests ===
Running target unix/-m32
FAIL: c-c++-common/analyzer/dot-output.c -std=c++14 dg-check-dot
dot-output.c.state-purge.dot
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
Jonathan Wakely changed:
What|Removed |Added
CC||zwuis at outlook dot com
--- Comment
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
>
> There's no default bitmap obstack during global CTORs, so allocate the
> bitmap locally.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> PR middle-end/114599
> * symtab.cc (ifunc_ref_map): Do
On Thu, Apr 4, 2024 at 5:54 AM Jørgen Kvalsvik wrote:
>
> On 04/04/2024 14:10, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> * builtins.cc (expand_builtin_fork_or_exec): Check
> >>condition_coverage_flag.
> >> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
> >>
uccesses 12
# of expected failures 1597
# of unsupported tests 5021
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9805-g8057f9aa1f] (GCC)
=== gfortran tests ===
ary ===
# of expected passes154074
# 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
5241
# of unsupported tests 23127
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240405
(experimental) [master r14-9811-g67cbb1c638] (GCC)
=== gcc tests ===
Running target unix/-m32
FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler
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 20240405
[remotes/origin/releases/gcc-12 r12-10313-g0611f48001] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #8 from Richard Biener ---
So in principle we'd need to adjust the bound by one only instead of not using
range info at all as the increment is executed in each loop iteration but
the loop may "stop" before it is reached.
We fail
Hi!
On 2024-04-03T14:06:45+0200, Tobias Burnus wrote:
> Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at'
> call,
> which stands out more clearly (color, bold) when enabling
>diagnostic_color_init
> which this patch does. — Additionally, the call gcc_init_libintl
On Fri, Apr 5, 2024 at 2:28 PM Manolis Tsamis wrote:
>
> If we consider code like:
>
> if (bar1 == x)
> return foo();
> if (bar2 != y)
> return foo();
> return 0;
>
> We would like the ifcombine pass to convert this to:
>
> if (bar1 == x || bar2 != y)
> return
cbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240405
(experimental) [remotes/origin/HEAD r14-9805-g8057f9aa1f7] (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=114600
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
commit r14-9809-g8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
Author: Marek Polacek
Date:
https://gcc.gnu.org/g:8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
commit r14-9809-g8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
Author: Marek Polacek
Date: Tue Apr 2 12:59:38 2024 -0400
c++: constexpr error with fn redecl in local scope [PR32]
We evaluate constexpr functions on the
1 - 100 of 305 matches
Mail list logo
