I noticed that the last bump happened on Thursday.
* * *
The error is according to
https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html
2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in message
That's the commit
---
Revert "Revert: "Enable prange suppor
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/
As that library is needed to support parallelization, it makes sense to
have the link.
Motivated by someone claiming at ISC-HPC that GCC only supports a single
image.
And also motivated by Damian's p
That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression,
caused when switching from a libgomp call to inline code and missing the
corner case of zero-size arrays ...
OK for mainline + all affected branches?
Tobias
Fortran: Fix SHAPE for zero-size arrays
PR fortran/115150
gcc
I don't see it in the tree/ChangeLog/... ?
Gerald
On Fri, 19 Aug 2022, Ondrej Kubanek via Gcc-patches wrote:
> +2022-08-18 Ondrej Kubanek
> +
> + * MAINTAINERS: add myself.
> +
> 2022-07-04 Martin Liska
>
> * MAINTAINERS: fix sorting of names
> diff --git a/MAINTAINERS b/MAINTA
I noticed this patchset did not see any comment, did not get committed,
and the PR is still open, so let me loop in Jason and Nathan as C++
maintainers.
Ed, looking at the ChangeLog something seems missing:
gcc/cp/ChangeLog:
* call.c (tourney):
(joust):
(build_user_ty
Hi,
> Just notice that this patch may result in some ICE when build libc++ for the
> riscv port, details as below. Please note not all configuration can
> reproduce this issue, feel free to ping me if you cannot reproduce this
> issue. CC more riscv port people for awareness.
Sorry for the breaka
Hi Tobias,
> That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression,
> caused when switching from a libgomp call to inline code and missing the
> corner case of zero-size arrays …
OK to push, thanks.
FX
First version was flawed, as it used the wrong type.
Here is another iteration.
Bootstrapped and regression tested on x86_64.
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
c23 specifies that the type of a redeclared enumerator is the one of the
Hi Tobias,
> OK for mainline?
Seems reasonable, OK to push in 48 hours unless someone has suggestions related
to wording.
FX
Thanks for quick response, 😉!
Pan
-Original Message-
From: Eric Botcazou
Sent: Sunday, May 19, 2024 5:40 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Robin
Dapp ; Jeff Law
Subject: Re: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR fo
Tested on i686, x86_64 Darwin, pushed to trunk, thanks
Iain
--- 8< ---
In the current Darwin implementation, we do not use .cfi_ insns
and emitted EH frames contain 'coalesced' section designations
which interfere with the scan asm.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-weakimport-3.
As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin
(and on x86_64 linux), pushed to trunk, thanks,
Iain
--- 8< ---
For Darwin, non-weak functions defined in a TU always bind locally
and so cxa_atexit-6.C is not applicable here.
PR testsuite/114982
gcc/testsuite/Cha
On 5/19/24 3:40 AM, Eric Botcazou wrote:
Hi,
Just notice that this patch may result in some ICE when build libc++ for the
riscv port, details as below. Please note not all configuration can
reproduce this issue, feel free to ping me if you cannot reproduce this
issue. CC more riscv port peop
Pushed.
Gerald
---
htdocs/gcc-14/changes.html | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dd3fea8d..6447898e 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -31,7 +31,7
On 5/2/24 7:51 PM, pan2...@intel.com wrote:
From: Pan Li
We allowed vector type for get_stored_val when read is less than or
equal to store in previous. Unfortunately, the valididate_subreg
treats the vector type's size is less than vector register as
invalid. Then we will have ICE here.
perl has some internal bitmap code. One of its implementation
properties is that if you ask it to set a bit, the bit is first cleared.
Unfortunately this is fairly hard to see in gimple/match due to type
changes in the IL. But it is easy to see in the code we get from
combine. So we just m
> Am 19.05.2024 um 01:12 schrieb Andrew Pinski :
>
> The problem here is even if last_and_only_stmt returns a statement,
> the bb might still contain a phi node which defines a ssa name
> which is used in that statement so we need to add a check to make sure
> that the phi nodes are empty for
On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote:
>
> perl has some internal bitmap code. One of its implementation
> properties is that if you ask it to set a bit, the bit is first cleared.
>
>
> Unfortunately this is fairly hard to see in gimple/match due to type
> changes in the IL. But it is
On Sun, May 19, 2024 at 6:38 AM Iain Sandoe wrote:
>
> As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin
> (and on x86_64 linux), pushed to trunk, thanks,
> Iain
Thanks for doing this.
Thanks,
Andrew
>
> --- 8< ---
>
> For Darwin, non-weak functions defined in a TU always
On 5/19/24 1:59 PM, Andrew Pinski wrote:
On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote:
perl has some internal bitmap code. One of its implementation
properties is that if you ask it to set a bit, the bit is first cleared.
Unfortunately this is fairly hard to see in gimple/match due to
On 5/19/24 02:01, Tobias Burnus wrote:
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/ >
[snip]
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 40e8e4a7cdd..78a2910b8d8 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.
Committed, thanks Jeff. Let's wait for a while before backporting.
Pan
-Original Message-
From: Jeff Law
Sent: Monday, May 20, 2024 12:23 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Liu, Hongtao
; richard.guent...@gmail.com
Subject: Re: [PA
Hi Carl,
on 2024/5/18 04:20, Carl Love wrote:
> Kewen:
>
> I am working thru the patches. I made the changes as requested for this
> patch but have a question about
> one of your comments.
>
> On 5/14/24 00:53, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:17, Carl Love wrote:
>>> rs6000, ext
On Fri, May 17, 2024 at 3:55 PM Uros Bizjak wrote:
>
> Rename _3 expander to a standard ssadd,
> usadd, sssub and ussub name to enable corresponding optab expansion.
>
> Also add named expander for MMX modes.
LGTM.
>
> PR middle-end/112600
>
> gcc/ChangeLog:
>
> * config/i386/mmx.md (3): N
On Linux/x86_64,
a9251ab3c91c8c559d0306838575a666ae62dff4 is the first bad commit
commit a9251ab3c91c8c559d0306838575a666ae62dff4
Author: Richard Biener
Date: Thu May 16 12:35:28 2024 +0200
wrong code with points-to and volatile
caused
with GCC configured with
../../gcc/configure
--pr
On Wed, May 15, 2024 at 11:30 AM Jiang, Haochen wrote:
>
> Also cc Honza and Richard since we touched generic tune.
>
> Thx,
> Haochen
>
> > -Original Message-
> > From: Haochen Jiang
> > Sent: Wednesday, May 15, 2024 11:04 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Liu, Hongtao ; ubiz...
Hi,
This patch implemented optab_isinf for SFDF and IEEE128 by test
data class instructions.
Compared with previous version, the main change is to modify
the dg-options and dg-finals of test cases according to reviewer's
advice.
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648304.html
Hi,
This patch implemented optab_isfinite for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is not to test
if pseudo can be created in expand and modify dg-options and
dg-finals of test cases according to reviewer's advice.
https://gcc.gnu.or
Hi,
This patch implemented optab_isnormal for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is not to test
if pseudo can be created in expand and modify dg-options and
dg-finals of test cases according to reviewer's advice.
https://gcc.gnu.or
On Tue, May 14, 2024 at 04:15:08PM +0200, Richard Biener wrote:
> On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote:
> >
> > - Give error messages for all causes of non sibling call generation
> > - Don't override choices of other non sibling call checks with
> > must tail. This causes ICEs. The mus
Hi,
For PR96866, when printing asm code for modifier "%a", an addressable
operand is required. While the constraint "X" allow any kind of
operand even which is hard to get the address directly. e.g. extern
symbol whose address is in TOC.
An error message would be reported to indicate the invalid
Hi Andrew,
在 2024/5/19 3:42, Andrew Pinski 写道:
> This is missing adding documentation for the new optab.
> It should be documented in md.texi under `Standard Pattern Names For
> Generation` section.
Thanks for your reminder. I will add ones for all patches.
Thanks
Gui Haochen
Hmm, there were now two daily bumps:
Date: Mon May 20 00:16:30 2024 +
Date: Sun May 19 18:15:28 2024 +
I really wonder why.
I guess, the 'ignore commit' is hence not needed – but I think the
improved diagnostic part still makes sense.
See updated patch.
On May 19, 24 Tobias Bur
33 matches
Mail list logo