https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
--- Comment #1 from Andrew Pinski ---
Created attachment 57004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57004=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264
Bug ID: 113264
Summary: ICE：tree check: expected tree that contains 'common'
structure, have 'integer_cst' in copy_list, at
tree.cc:1427
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Bug ID: 113263
Summary: ICE for invalid code for compound literal and type
definition in return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
Hi,
This is the patch to add cortex-m52 in the Arm-related options
sections of the gcc invoke.texi documentation.
Is it OK for trunk?
Regards,
jasonwucjFrom b7ce3d499d4bf087ec54a5f834876c9108d46c3d Mon Sep 17 00:00:00 2001
From: Chung-Ju Wu
Date: Thu, 7 Dec 2023 11:26:25 +0800
Subject: [PATCH
Hi,
Recently, Arm announced the Cortex-M52, delivering increased performance
in DSP and ML along with a range of other features and benefits.
For the completeness of Arm ecosystem, we hope that cortex-m52 support
could be available in gcc-14.
Attached is the patch to support cortex-m52 cpu with
Don't use assert, it not work well with multilib testing.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/single_rgroup-3.h: Use
check + abort rather than assert.
---
.../riscv/rvv/autovec/partial/single_rgroup-3.h | 8 ++--
1 file changed, 6
On 07/01/2024 21:53, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
On 07/01/2024 17:34, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
Hi
While working on the patch to use the cxx11 abi in gnu version namespace
mode I got a small
Ping
On 28/11/23 6:24 pm, Surya Kumari Jangala wrote:
> Ping
>
> On 10/11/23 12:27 pm, Surya Kumari Jangala wrote:
>> Ping
>>
>> On 03/11/23 1:14 pm, Surya Kumari Jangala wrote:
>>> Hi Segher,
>>> I have incorporated changes in the code as per the review comments provided
>>> by you
>>> for
On Mon, Jan 8, 2024 at 11:09 AM Hongyu Wang wrote:
>
> Hi,
>
> The supported sub-features for APX was missing in option document and
> target attribute section. Add those missing ones.
>
> Ok for trunk?
Ok.
>
> gcc/ChangeLog:
>
> * config/i386/i386.opt: Add supported sub-features.
>
On 1/5/24 10:35, Richard Sandiford wrote:
Jeff Law writes:
On 10/24/23 12:49, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
So have you done any investigation on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #16 from Andrew Pinski ---
Note multiple copies of the libstdc++ will not fix the issue here since
libtcmalloc provides a free which does not work with aligned_alloc. In fact it
would just fall over the same way. As I mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #7 from g.peterh...@t-online.de ---
Thank you. That was my question whether these two functions could be added.
At the moment I'm using boost.charconv https://github.com/cppalliance/charconv
https://develop.charconv.cpp.al (not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Nicholas Miell changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.1.0
Last reconfirmed|
I am on vacation today. I will back tomorrow or late tonight. I think we can land theadvector before spring festival as long as it is not invasive to RVV1.0 Replied Message FromjoshuaDate01/08/2024 11:17 ToKito Cheng Ccjuzhe.zh...@rivai.ai,jeffreyalaw,gcc-patches,Jim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #6 from Andrew Pinski ---
(In reply to g.peterhoff from comment #5)
> ??? I asked for std::from_chars/std::to_chars - which of course doesn't work:
> https://godbolt.org/z/n34dTajoc
std::from_chars/std::to_chars for extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #5 from g.peterh...@t-online.de ---
??? I asked for std::from_chars/std::to_chars - which of course doesn't work:
https://godbolt.org/z/n34dTajoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Bug ID: 113262
Summary: ICE when using [[gnu::copy("")]] attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
ack, I am fixing this, and running a few more tests, thanks for reporting this!
On Sat, Jan 6, 2024 at 10:06 AM 钟居哲 wrote:
>
> Hi, kito.
>
> This patch causes these following regression FAILs:
>
> FAIL: gcc.target/riscv/rvv/autovec/partial/single_rgroup_run-3.c (test for
> excess errors)
>
It depends on the timing when you send out the v1 patch to the mailing
list, not the timing of when to merge, but of course it's case by
case, I would say no IF it's still not ready when time is the end of
Feb for this kind of big patch set.
On Mon, Jan 8, 2024 at 11:17 AM joshua wrote:
>
> Hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111480
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-01-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
--- Comment #1 from Hongtao Liu ---
For foo1,
_99 = .REDUC_PLUS (vect_patt_79.51_97);
_90 = .REDUC_PLUS (vect_patt_28.43_88);
_19 = _90 + _99;
can be optimized to
_tmp = vect_patt_79.51_97 + vect_patt_28.43_88;
_19 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
Bug ID: 113261
Summary: missing vectorization for dot_prod chain.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Hi Kito,
Thank you for your support.
So even during stage 4, we can merge this for GCC 14?
--
发件人：Kito Cheng
发送时间：2024年1月8日(星期一) 11:06
收件人：joshua
抄 送："juzhe.zh...@rivai.ai";
jeffreyalaw; "gcc-patches"; Jim
Wilson; palmer;
Hi,
The supported sub-features for APX was missing in option document and
target attribute section. Add those missing ones.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.opt: Add supported sub-features.
* doc/extend.texi: Add description for target attribute.
---
On Thu, Dec 14, 2023 at 12:03 AM Jan Hubicka wrote:
>
> > > The diffrerence is that Cores understand the fact that fmadd does not need
> > > all three parameters to start computation, while Zen cores doesn't.
> > >
> > > Since this seems noticeable win on zen and not loss on Core it seems like
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
--- Comment #2 from g.peterh...@t-online.de ---
I'm currently fiddling around with a library for/with boost. I don't need this
kind of incompatibility.
I am ok with merging this for GCC 14, as we discussed several times in
the RISC-V GCC sync up meeting, I think at least we reach consensus
among Jeff Law, Palmer Dabbelt and me.
But please be careful: don't break anything for standard vector stuff.
On Mon, Jan 8, 2024 at 10:11 AM joshua wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #4 from Andrew Pinski ---
_Float128 is supported in older c++ standards for gcc. That is it does not
error out for -std=gnu++11 even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #3 from g.peterh...@t-online.de ---
My problem is that I need from_chars/to_chars for __float128 also for older C++
standards that do not yet support _Float128/std::float128_t.
Hi,
I noticed that commit r14-6192 can't help PR112606 #c3 as
it only takes care of SF/DF but TF/KF can still suffer the
issue. Similar to commit r14-6192, this patch is to take
care of copysign3 with IEEE128 as well.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9
and
Hi,
As PR111480 shows, commit r14-4079 only optimizes the case
of vctzlsbb but not for the similar vclzlsbb. This patch
is to consider vclzlsbb as well and avoid the failure on
the reported test case. It also simplifies the patterns
with iterator and attribute.
Bootstrapped and regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
Hi,
As PR112751 shows, commit r14-5628 caused pcrel-sibcall-1.c
to fail as it enables ipa-vrp which makes return values of
functions {x,y,xx} as known and propagated. This patch is
to adjust it with noipa to make it not fragile.
Tested well on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu
Hi,
As PR113100 shows, the unbiasing introduced by r14-6737 can
cause the scrubbing to overrun and screw some critical data
on stack like saved toc base consequently cause segfault on
Power.
By checking PR112917, IMHO we should keep this unbiasing
guarded under SPARC_STACK_BOUNDARY_HACK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #1 from Andrew Pinski ---
There is support for _Float128 for from_chars/to_chars in GCC 14 already ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #12 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Nicholas Miell from comment #8)
> > What appears to actually be happening is that the libstdc++ operator
> > new(std::size_t size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Bug ID: 113260
Summary: missing from_chars/to_chars for __float128
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Hi Juzhe,
Stage 3 will close today and there are still some patches that
haven't been reviewed left.
So is it possible to get xtheadvector merged in GCC-14?
We emailed Kito regarding this, but haven't got any reply yet.
Joshua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
Bug ID: 113259
Summary: quadmath::nanq not support payload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #11 from Andrew Pinski ---
https://github.com/gperftools/gperftools/commit/d406f2285390c402e824dd28e6992f7f890dcdf9
was the commit which fixed tcmalloc .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110966
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
On 01/07/24 at 10:21am, Andrew Morton wrote:
> On Sun, 7 Jan 2024 17:16:41 +0800 Baoquan He wrote:
>
> > with GCC 13.2.1 and W=1, there's compiling warning like this:
> >
> > kernel/panic.c: In function ‘__warn’:
> > kernel/panic.c:676:17: warning: function ‘__warn’ might be a candidate for
>
On Sun, Jan 7, 2024 at 6:53 AM Roger Sayle wrote:
>
> Hi Hongtao,
>
> Many thanks for the review. This revised patch implements several
> of your suggestions, specifically to use pshufd for V4SImode and
> punpcklqdq for V2DImode. These changes are demonstrated by the
> examples below:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #9 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #8)
> What appears to actually be happening is that the libstdc++ operator
> new(std::size_t size, std::align_val_t alignment) is calling glibc's
> aligned_alloc,
On Mon, 8 Jan 2024 at 01:22, Jonathan Wakely wrote:
>
> On Mon, 8 Jan 2024 at 01:13, Jonathan Wakely wrote:
> >
> > This V2 patch failed CI:
> > https://patchwork.sourceware.org/project/gcc/patch/20240106151802.3356059-1-jwak...@redhat.com/
> >
> > But that's because the UTF-8 characters in the
This patchset performs some code cleanup, and is bootstrapped and regtested
on loongarch64-linux-gnu.
Changes from v1 -> v2:
* Replaced all TARGET_ macros from .opt.
* Fixed definition of ISA_HAS_LAMCAS.
Yang Yujie (4):
LoongArch: Handle ISA evolution switches along with other options
LoongArch ISA manual v1.10 suggests that software should not depend on
the ISA version number for marking processor features. The ISA version
number is now defined as a collective name of individual ISA evolutions.
Since there is a independent ISA evolution mask now, we can drop the
version
gcc/ChangeLog:
* config/loongarch/genopts/genstr.sh: Prepend the isa_evolution
variable with the common la_ prefix.
* config/loongarch/genopts/loongarch.opt.in: Mark ISA evolution
flags as saved using TargetVariable.
* config/loongarch/loongarch.opt: Same.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change makes std::make_format_args refuse to create dangling
references to temporaries. This makes the std::vformat API safer. This
was approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.
Since we do not need printing or manual parsing of this option,
(whether in the driver or for target attributes to be supported later)
it can be handled in the .opt file framework.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch-strings: Remove explicit-reloc
argument string
Target features constants from loongarch-def.h are currently defined as macros.
Switch to enums for better look in the debugger.
gcc/ChangeLog:
* config/loongarch/loongarch-def.h: Define constants with
enums instead of Macros.
---
gcc/config/loongarch/loongarch-def.h | 115
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This adds std::runtime_format for C++26. These new overloaded functions
enhance the std::format API so that it isn't necessary to use the less
ergonomic std::vformat and std::make_format_args (which are meant to be
implementation
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change ensures that char and wchar_t arguments are formatted
consistently when using integer presentation types. This avoids
non-portable std::format output that depends on whether char and wchar_t
happen to be signed or
Hi, I found __atomic_float constructor does not clear padding,
while __compare_exchange assumes it as zeroed padding. So it is easy to
reproducing a infinite loop in X86-64 with long double type like:
---
-O0 -std=c++23 -mlong-double-80
#include
#include
#define T long double
int main() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #8 from Nicholas Miell ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Nicholas Miell from comment #0)
> > This is typically the result of the libstdc++ version of operator
> > delete(void* ptr, std::align_val_t
This patch fix the rtl-checking error for crypto vector. The root
cause is the avl-type index of zvbc ins is error,it should be operand[8]
not operand[5].
gcc/ChangeLog:
* config/riscv/vector.md: Modify avl_type operand index of zvbc ins.
---
gcc/config/riscv/vector.md | 4 ++--
1 file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #7 from Jonathan Wakely ---
(In reply to Nicholas Miell from comment #0)
> This is typically the result of the libstdc++ version of operator
> delete(void* ptr, std::align_val_t alignment) calling the
> application-supplied version
Complement commit c1e8cb3d9f94 ("RISC-V: Rework branch costing model for
if-conversion") and also handle extraneous sign extend operations that
are sometimes produced by `noce_try_cmove_arith' instead of zero extend
operations, making branch costing consistent. It is unclear what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #6 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #4)
> No, the problem is that a pre-C++17 application is using a post-C++17 GPU
> driver (well, the GPU driver is using a post-C++17 libLLVM), and the
> post-C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #5 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #3)
> GCC has dealt with similar issues before, cf. bug 68210.
That was a defect to the C++11 standard unlike this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #4 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #2)
> So the situtation here is you have a pre-C++17 application using a C++17
> library.
>
> If the application was C++17 and using a C++11 library, it would just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #3 from Nicholas Miell ---
Windows and macOS (and Solaris) have sensible dynamic linker semantics where
the pre-C++17 code and the post-C++17 code uses two different C++ runtimes and
furthermore the application can use tcmalloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #2 from Andrew Pinski ---
So the situtation here is you have a pre-C++17 application using a C++17
library.
If the application was C++17 and using a C++11 library, it would just work.
So the ABI is broken in the C++17 library
On Sunday, January 7th, 2024 at 3:22 PM, Jakub Jelinek wrote:
>
>
> On Sun, Jan 07, 2024 at 03:12:32PM -0700, Jeff Law via Gcc wrote:
>
> > On 1/7/24 08:48, waffl3x via Gcc wrote:
> >
> > > https://gcc.gnu.org/develop.html#timeline
> > > The date for stage 4 is listed as the 8th on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #1 from Andrew Pinski ---
This is a C++ standard issue I suspect which cannot be fixed just in libstdc++.
I suspect libc++ and MSVC's C++ library all have a similar issue too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Bug ID: 113258
Summary: Pre-C++17 code that supplies operator new/delete
crashes when mixed with post-C+17 code that uses the
align_val_t variants of new/delete
Product:
On 1/3/24 05:07, Richard Sandiford wrote:
+
+ if (GET_CODE (x) == ZERO_EXTRACT)
+ {
+ /* If either the size or the start position is unknown,
+then assume we know nothing about what is overwritten.
+This is overly conservative,
Bootstrapped and tested on x86_64-linux with no regressions.
Not as hard as I thought it would be! As noted in the commit message, I believe
this makes explicit object member functions feature complete.From a5f947d411b5e19ce7efbb4d766a2792b02c9626 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date:
Since in the previous review from Robin, he have ever asked me change std::max
into MAX,
I thought the policy is preferring MAX instead of std::max.
I change the codes to make them consistent but it seems I am wrong.
So is it reasonable that I change all RVV-related codes back to use
Snapshot gcc-14-20240107 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20240107/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Sun, Jan 07, 2024 at 03:12:32PM -0700, Jeff Law via Gcc wrote:
> On 1/7/24 08:48, waffl3x via Gcc wrote:
> > https://gcc.gnu.org/develop.html#timeline
> > The date for stage 4 is listed as the 8th on here, is that date final?
> > There is at least 1 patch pending (mine) that is complete but
On 1/7/24 08:48, waffl3x via Gcc wrote:
https://gcc.gnu.org/develop.html#timeline
The date for stage 4 is listed as the 8th on here, is that date final?
There is at least 1 patch pending (mine) that is complete but Jason
Merril hasn't been active for a few days. He had expressed to me that
he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-01-07
Dear all,
the attached, actually rather obvious patch fixes an issue when
an optional dummy with the value attribute was passed as DIM
argument to the SIZE intrinsic. Instead of some hand-crafted,
incomplete presence check for the argument, it makes more sense
to rely on gfc_conv_expr_present().
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
>
>
> On 07/01/2024 17:34, Jonathan Wakely wrote:
> > On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
> >> Hi
> >>
> >> While working on the patch to use the cxx11 abi in gnu version namespace
> >> mode I got a small problem with this
On Sun, 7 Jan 2024, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> The recursively defined constraints on _Variadic_union's user-defined
> destructor (necessary for maintaining trivial destructibility of the
> variant iff all of its
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The recursively defined constraints on _Variadic_union's user-defined
destructor (necessary for maintaining trivial destructibility of the
variant iff all of its alternatives are) effectively require a template
instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following probably rather obvious patch fixes the issue:
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index d973c49380c..748cc74de89 100644
---
The patch below fixes some obvious problems in gcc.target/avr:
* Remove duplicate -mmcu=
* Skip tests with address spaces on Reduced Tiny which does not support
address spaces at all.
* Address spaces are GNU-C, but some tests were missing -std=gnu*
* Don't test address-space __flash1 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #3 from Uroš Bizjak ---
_.dse1 pass is removing the store for some reason, -fno-dse "fixes" the
testcase.
Before _.dse1 pass, we have:
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36
Hi Jerry!
On 1/7/24 19:40, Jerry D wrote:
Committed as simple and obvious. Initial patch thanks to Steve.
When using git gcc-commit-mklog how does one add in the coauthor?
% git help gcc-commit-mklog
...
--co CO Add Co-Authored-By trailer (comma separated)
However, I usually
ROCm meanwhile supports also some consumer cards; besides the semi-new
gfx1030, support for gfx1100 was added more recently (in ROCm 5.7.1 for
"Ubuntu 22.04 only" and without parenthesis since ROCm 6.0.0).
GCC has already very limited support for gfx1030 - whose multlib support
is - on
On 1/6/24 17:36, Juzhe-Zhong wrote:
Obvious fix, Committed.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: replace std::max by MAX.
Curious why you made this change -- in general we're moving to
std::{min,max,swap} and away from macro-ized min/max/swap.
Jeff
On 1/7/24 18:29, Tamar Christina wrote:
gcc/ChangeLog:
PR tree-optimization/113237
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg): Use
existing LCSSA variable for exit when all exits are early break.
Might that be the same error as I got here when
On 1/7/24 10:17, Georg-Johann Lay wrote:
Am 07.01.24 um 17:45 schrieb Jeff Law:
On 1/7/24 08:53, Georg-Johann Lay wrote:
Made some tests more generic so they can pass on more targets.
Johann
--
testsuite/52641: Fix fallout from sloppy tests.
gcc/testsuite/
PR testsuite/52641
On 07/01/2024 17:34, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
Hi
While working on the patch to use the cxx11 abi in gnu version namespace
mode I got a small problem with this missing constructor. I'm not sure
that the main patch will be integrated in gcc 14
Committed as simple and obvious. Initial patch thanks to Steve.
When using git gcc-commit-mklog how does one add in the coauthor?
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9
commit r14-6986-gadd995ec117d756e61d207041cd32f937c1a1cd9
Author: Jerry DeLisle
Date:
On Sun, 7 Jan 2024 17:16:41 +0800 Baoquan He wrote:
> with GCC 13.2.1 and W=1, there's compiling warning like this:
>
> kernel/panic.c: In function ‘__warn’:
> kernel/panic.c:676:17: warning: function ‘__warn’ might be a candidate for
> ‘gnu_printf’ format attribute
1 - 100 of 137 matches
Mail list logo
