From: Andrew Pinski
m32r support never made it to glibc and the support for the Linux kernel
was removed with 4.18. It does not remove much but no reason to keep
around a port which never worked or one which the support in other
projects is gone.
OK? Checked to make sure m32r-linux and m32rle-li
On Mon, Sep 13, 2021 at 02:42:10PM +0800, Kewen.Lin wrote:
> This patch follows Segher's suggestion here[1] to get rid of
> the typedef, it's pre-approved as [1].
Thanks!
Segher
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and removes the corresponding
diagnostic from the Ada frontend. The warnings are pruned from the
testsuite outpu
On 10.09.21 17:39, Andreas Schwab wrote:
This misses the m68k extended real format.
* ISO_Fortran_binding.h (CFI_type_long_double)
(CFI_type_long_double_Complex) [LDBL_MANT_DIG == 64 &&
LDBL_MIN_EXP == -16382 && LDBL_MAX_EXP == 16384]: Define.
LGTM – thanks!
Tobias
---
l
ping?
On 06/09/2021 09:23, Christophe LYON wrote:
ping?
On 26/08/2021 17:53, Christophe Lyon wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure this.
202
Dear Harald, hi all,
On 12.09.21 20:40, Harald Anlauf via Fortran wrote:
in find_substring_ref we erroneously handled given substring start and end
indices as unsigned integers. However, gives indices could be negative,
which is legal as long as end < start, leading to a string of length zero.
On Mon, 13 Sep 2021, Xionghu Luo wrote:
>
>
> On 2021/9/10 21:54, Xionghu Luo via Gcc-patches wrote:
> >
> >
> > On 2021/9/9 18:55, Richard Biener wrote:
> >> diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
> >> index 5d6845478e7..4b187c2cdaf 100644
> >> --- a/gcc/tree-ssa-loop-im
Hi all,
In the testcase we generate invalid assembly for an SVE load predicate
instruction.
The RTL for the insn is:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:DI 0 x0 [92])) [2 wo
On 07.09.21 23:44, Harald Anlauf via Fortran wrote:
When adding the initializer for an array, we need to make sure that
array bounds are properly simplified if that array is a PARAMETER.
Otherwise the generated initializer could be wrong and screw up
subsequent simplifications, see PR.
The minim
ping?
On 08/09/2021 10:49, Christophe Lyon wrote:
When running the testsuite under Windows, we noticed failures in
testcase which attempt to match compiler error messages containing the
name of the executable.
For instance, gcc.dg/analyzer/signal-4a.c tries to match 'cc1:' which
obviously fail
ping?
On 07/09/2021 11:15, Christophe Lyon wrote:
This patch series addresses PR 100757 and 101325 by representing
vectors of predicates (MVE VPR.P0 register) as vectors of booleans
rather than using HImode.
As this implies a lot of mostly mechanical changes, I have tried to
split the patches
On Fri, Sep 10, 2021 at 5:07 PM Segher Boessenkool
wrote:
>
> On Fri, Sep 10, 2021 at 12:53:37PM +0200, Richard Biener wrote:
> > On Fri, Sep 10, 2021 at 1:50 AM Segher Boessenkool
> > wrote:
> > > And many targets have strange rules for bit-strings in which modes can
> > > be used as bit-strings
On Sun, Sep 12, 2021 at 6:12 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> So right now liblto_plugin.so exports many libiberty symbols and
> simple_object file symbols but really it just needs to export onload.
>
> This fixes the problem by using "-export-symbols-regex onload"
On Sun, Sep 12, 2021 at 8:12 PM Jan-Benedict Glaw wrote:
>
> Hi!
>
> While mass-building a cross-gcc, I noticed that for
> alpha-dec-vms/alpha64-dec-vms, recent GCC versions correctly throw a warning
> due to a multi-statement define that gets rippen in an if/else case:
>
> [all 2021-09-12 15:51:5
On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
>
> On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Fri, Sep 10, 2021 at 2:58 PM liuhongt wrote:
> > >
> > > gcc/ChangeLog:
> > >
> > > * expmed.c (extract_bit_field_using_extv): validate_subreg
> > >
This adds cr16-*-* to the list of obsoleted targets in config.gcc
Approved by Jeff in another thread, pushed. cr16 has no maintainer and
it's still cc0.
2021-09-13 Richard Biener
* config.gcc: Add cr16-*-* to the list of obsoleted targets.
---
gcc/config.gcc | 1 +
1 file changed, 1
On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> Hi Richard,
>
> On Fri, 2021-09-10 08:02:00 +0200, Richard Biener via Gcc-patches
> wrote:
> > > On 9/9/2021 7:19 AM, Richard Biener via Gcc-patches wrote:
> > > > The patch also removes the PREFERRED_DEBUGGING_TYPE define from
> > > > lynx.h whic
With the last adjustment I failed to remove a stray
Pushed.
2021-09-13 Richard Biener
* config/i386/lynx.h: Remove undef of PREFERRED_DEBUGGING_TYPE
to inherit from elfos.h
---
gcc/config/i386/lynx.h | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/config/i386/lynx.
On Fri, Sep 10, 2021 at 3:47 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> Hi Richard.
>
> > On Thu, 9 Sep 2021, Kees Cook wrote:
> >
> >> On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote:
> >> > Hi, FYI
> >> >
> >> > I just committed the following patch to gcc upstream:
> >> >
> >> >
On Fri, Sep 10, 2021 at 4:48 PM Richard Earnshaw wrote:
>
>
> gen_lowpart_general handles forming a lowpart of a MEM by using
> adjust_address to rework and validate a new version of the MEM.
> Do the same for gen_highpart rather than calling simplify_gen_subreg
> for this case.
OK from my side.
Richard Earnshaw via Gcc-patches writes:
> gen_lowpart_general handles forming a lowpart of a MEM by using
> adjust_address to rework and validate a new version of the MEM.
> Do the same for gen_highpart rather than calling simplify_gen_subreg
> for this case.
Looks OK, but what went wrong with t
On 13/09/2021 10:38, Richard Sandiford via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
gen_lowpart_general handles forming a lowpart of a MEM by using
adjust_address to rework and validate a new version of the MEM.
Do the same for gen_highpart rather than calling simplify_gen
Now that the jump thread back registry has been split into the generic
copier and the custom (old) copier, it becomes trivial to remove the
FSM bits from the jump threaders.
First, there's no need for an EDGE_FSM_THREAD type. The only reason
we were looking at the threading type was to determine
Richard Earnshaw writes:
> On 13/09/2021 10:38, Richard Sandiford via Gcc-patches wrote:
>> Richard Earnshaw via Gcc-patches writes:
>>> gen_lowpart_general handles forming a lowpart of a MEM by using
>>> adjust_address to rework and validate a new version of the MEM.
>>> Do the same for gen_high
Hi Richard,
On Mon, 2021-09-13 11:24:53 +0200, Richard Biener via Gcc-patches
wrote:
> This adds cr16-*-* to the list of obsoleted targets in config.gcc
>
> Approved by Jeff in another thread, pushed. cr16 has no maintainer and
> it's still cc0.
>
> 2021-09-13 Richard Biener
>
> * c
On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> Hi Richard,
>
> On Mon, 2021-09-13 11:24:53 +0200, Richard Biener via Gcc-patches
> wrote:
> > This adds cr16-*-* to the list of obsoleted targets in config.gcc
> >
> > Approved by Jeff in another thread, pushed. cr16 has no maintainer and
> > i
Hi!
On Mon, 2021-09-13 11:11:30 +0200, Richard Biener
wrote:
> On Sun, Sep 12, 2021 at 8:12 PM Jan-Benedict Glaw wrote:
> > gcc/ChangeLog:
> >
> > * config/alpha/vms.h (INIT_CUMULATIVE_ARGS): Wrap multi-statment
> > define into a block.
> OK.
Committed, thanks!
MfG, JBG
--
Hi!
On Mon, 2021-09-13 11:58:59 +0200, Richard Biener wrote:
> On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> > contrib/ChangeLog:
> >
> > * config-list.mk (LIST): --enable-obsolete for cr16-elf.
> >
[...]
> OK.
Committed, thanks!
MfG, JBG
--
signature.asc
Description: PGP signature
If the tree expression X is a truthvalue, then X << 0 is a truthvalue.
In fact, because _Bool (truthvalue_type) has 1 bit precision, and shifts
are only well defined for bit counts less than the precision, the only
reasonable(?) left shift of a _Bool is by zero [where this reasonable
overlooks tha
On Mon, Sep 13, 2021 at 11:42:08AM +0100, Roger Sayle wrote:
> gcc/c-family/ChangeLog
> PR c/102245
> * c-common.c (c_common_truthvalue_conversion) [LSHIFT_EXPR]:
> Special case (optimize) shifts by zero.
>
> gcc/testsuite/ChangeLog
> PR c/102245
> * gcc.dg/Wint-in-bo
Kyrylo Tkachov writes:
> Hi all,
>
> In the testcase we generate invalid assembly for an SVE load predicate
> instruction.
> The RTL for the insn is:
> (insn 9 8 10 (set (reg:VNx16BI 68 p0)
> (mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
> (const_int 8 [0x8]))
>
On Mon, Sep 13, 2021 at 5:15 PM Richard Biener
wrote:
>
> On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
> >
> > On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Fri, Sep 10, 2021 at 2:58 PM liuhongt wrote:
> > > >
> > > > gcc/ChangeLog:
> > > >
> > >
We need to use the pointer equivalence tracking from evrp in the jump
threader. Instead of moving it to some *evrp.h header, it's cleaner for
it to live in its own file, since it's completely independent and not
evrp specific.
Tested on x86-64 Linux.
gcc/ChangeLog:
* Makefile.in (OBJS):
This removes m68k-openbsd as a valid configuration, according
to openbsd.org m68k-openbsd [on the mac] was discontinued after
the 5.1 release. The configuration is also not (or no longer)
supported by gas and GNU ld so I could not figure whether it is still
a.out (I suspect it is). But first and
This removes the support for vax-openbsd which has been discontinued
after the OpenBSD 5.9 release and which has no supported gas or GNU ld
configuration [anymore]. In particular this target does only support
STABS debuginfo generation.
OK for trunk?
Thanks,
Richard.
2021-09-13 Richard Biener
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> we are not going to error out. It fixes the problem by the removal
> of the function from the IR.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no r
On 13.09.21 13:14, Hongtao Liu via Gcc-patches wrote:
Yes, update patch
bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
If that patch gets approved, can you add PR bootstrap/102302 to the
commit changelog ?
cf. https://gcc.gnu.org/PR102302
Thanks,
Tobias
gcc/Chang
On Mon, Sep 13, 2021 at 1:14 PM Hongtao Liu wrote:
>
> On Mon, Sep 13, 2021 at 5:15 PM Richard Biener
> wrote:
> >
> > On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
> > >
> > > On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Fri, Sep 10, 2021
On Fri, Sep 10, 2021 at 6:32 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 9/10/2021 7:53 AM, Aldy Hernandez via Gcc-patches wrote:
> >
> >
> > On 9/10/21 3:16 PM, Michael Matz wrote:
> >> Hi,
> >>
> >> On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
> >>
> >>>
On Fri, Sep 10, 2021 at 8:47 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi!
>
> This patch implements OpenMP 5.1 atomics (with clarifications from
> upcoming 5.2).
> The most important changes are that it is now possible to write (for C/C++,
> for Fortran it was possible
Hi!
Gcc5 has implemented 'SSO'. The length of small string local buffer is 15,
which
is enough to store an integer. So we can use
'numeric_limits::digits+1' to
get the max length of int instead of dynamically obtaining the length of
the
integer through __to_chars_len. In this way, I will get a per
On Mon, Sep 13, 2021 at 1:49 PM Christophe Lyon
wrote:
> This last test now fails on aarch64:
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
> threaded: 8"
>
> Can you check?
These rather large tests checking for some random number of jump
threads are very annoying.
On 9/13/2021 5:41 AM, Richard Biener via Gcc-patches wrote:
This removes the support for vax-openbsd which has been discontinued
after the OpenBSD 5.9 release and which has no supported gas or GNU ld
configuration [anymore]. In particular this target does only support
STABS debuginfo generati
On 9/13/2021 5:36 AM, Richard Biener wrote:
This removes m68k-openbsd as a valid configuration, according
to openbsd.org m68k-openbsd [on the mac] was discontinued after
the 5.1 release. The configuration is also not (or no longer)
supported by gas and GNU ld so I could not figure whether it
On 9/13/2021 1:11 AM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
m32r support never made it to glibc and the support for the Linux kernel
was removed with 4.18. It does not remove much but no reason to keep
around a port which never worked or one which the support in other
project
On 9/13/2021 1:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and removes the corresponding
diagnostic from the Ada frontend.
PING^1
On 8/13/21 15:41, H.J. Lu wrote:
On Fri, Aug 13, 2021 at 1:10 AM Martin Liška wrote:
On 8/12/21 7:35 PM, H.J. Lu wrote:
What happens for arch=x86-64-v5?
pr101696.c:5:55: error: bad value (‘x86-64-v5’) for ‘target("arch=")’ attribute
5 | __attribute__ ((target ("arch=x86-64-v5
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86 with -Wall yields:
$ gcc -c -O2 pr55107.c -Wall
PING^1
On 9/7/21 11:42, Martin Liška wrote:
On 9/6/21 14:16, Richard Biener wrote:
On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote:
On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *o
Ping.
Message-Id:
Thanks!
Bill
On 9/1/21 11:13 AM, Bill Schmidt via Gcc-patches wrote:
Hi!
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572231.html
V3 patch series here
On 9/13/2021 3:54 AM, Aldy Hernandez wrote:
Now that the jump thread back registry has been split into the generic
copier and the custom (old) copier, it becomes trivial to remove the
FSM bits from the jump threaders.
First, there's no need for an EDGE_FSM_THREAD type. The only reason
we wer
PING^1
On 9/7/21 11:43, Martin Liška wrote:
Hi.
I'm planning some refactoring related to 'section *' and I noticed we have
quite ugly mask definitions (of form 1UL << N), where SECTION_FORGET is unused
and
#define SECTION_STYLE_MASK 0x60 /* bits used for SECTION_STYLE */
Is actually OR
On 9/11/2021 12:01 PM, Aldy Hernandez wrote:
So another thing to consider is that the threaders initially record
their paths in different directions. Forward threading records
starting at the first block, backward from the final block. At some
point (I no longer remember where) we invert
On Tue, Sep 7, 2021 at 8:01 PM H.J. Lu wrote:
>
> On Sun, Aug 22, 2021 at 8:28 AM H.J. Lu wrote:
> >
> > On Tue, Mar 23, 2021 at 09:19:38AM +0100, Richard Biener wrote:
> > > On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang
> > > wrote:
> > > >
> > > > > Hongyue, please collect code size differences
On 9/13/2021 7:29 AM, Aldy Hernandez wrote:
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86
On Mon, 13 Sep 2021, Jeff Law wrote:
>
>
> On 9/13/2021 1:31 AM, Richard Biener wrote:
> > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > is not specified by the target and NO_DEBUG if DWARF is not supported.
> >
> > It also makes us warn when STABS is enabled and remo
On 8/27/21 11:05, Richard Biener wrote:
So with ignoring darktable which seems completely insane the cases
will likely continue
to work as intended if we change from the current scheme to appending
as proposed.
All right, I'm addressing the flag_complex_method in a separate sub-thread.
There's
On 9/13/2021 7:47 AM, Richard Biener wrote:
On Mon, 13 Sep 2021, Jeff Law wrote:
On 9/13/2021 1:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn w
On 9/10/2021 1:45 AM, Thomas Schwinge wrote:
0001-Simplify-gcc-diagnostic-spec.h-nowarn_map-setup.patch
From 095c16ead5d432726f2b6de5ce12fd367600076d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 1 Sep 2021 16:48:55 +0200
Subject: [PATCH 1/3] Simplify 'gcc/diagnostic-spec.h:now
On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
optimizer wouldn't simplify if op0 has different mode with M, but that's too
restrict which will prevent below optimization, the condition can be relaxed
to op0 mus
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
> > So it looks like there's some undefined behavior going on, even before
> > my patch. I'd like to get some feedback, because this is usually the
> > type of problems I see in the presence of a smarter threader... things
> > get shuff
On Mon, Sep 13, 2021 at 4:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restric
On 9/13/2021 8:18 AM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
So it looks like there's some undefined behavior going on, even before
my patch. I'd like to get some feedback, because this is usually the
type of problems I see in the presence of a smar
On Thu, Aug 12, 2021 at 5:32 PM Martin Liška wrote:
>
> On 8/12/21 5:26 PM, H.J. Lu wrote:
> > Will it hurt if they have proper feature_priorities you added?
>
> No. They are unused, by we should use the proper priorities.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (cpu_indicator_init): Add s
This changes us to maintain and compute (mis-)alignment info for
the first element of a group only rather than for each DR when
doing interleaving and for the earliest, first, or first in the SLP
node (or any pair or all three of those) when SLP vectorizing.
For this to work out the easiest way I
> On Fri, Sep 10, 2021 at 3:47 PM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hi Richard.
>>
>> > On Thu, 9 Sep 2021, Kees Cook wrote:
>> >
>> >> On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote:
>> >> > Hi, FYI
>> >> >
>> >> > I just committed the following patch to gcc upstream
On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj 2021-09-10
> > 11:47:17.093164041 +0200
> > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > 11:52:33.428722747 +0200
> > @@ -0,0 +1,43 @@
> > +/* { dg-do compi
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 13 September 2021 12:09
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: PR target/102252 Invalid addressing mode for
> SVE load predicate
>
> Kyrylo Tkachov writes:
> > Hi all,
> >
> >
On Sun, Sep 12, 2021 at 10:29 PM Jason Merrill wrote:
>
> On 9/12/21 7:48 PM, Patrick Palka wrote:
> > On Thu, 2 Sep 2021, Jason Merrill wrote:
> >
> >> On 8/30/21 10:05 PM, Patrick Palka wrote:
> >>> Here when partially substituting into the pack expansion, substitution
> >>> into the constexpr i
On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
> > [...]
> > > > >
> > > > > + /* Handle strlen like loops. */
> > > > > + if (store_dr
On Mon, Sep 13, 2021 at 4:40 PM Jakub Jelinek wrote:
> On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj 2021-09-10
> > > 11:47:17.093164041 +0200
> > > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > > 11
On 2021-09-13 9:53 a.m., Jeff Law wrote:
>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>> DWARF (for whatever reasons).
> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a
> variant of COFF and could easily support dwarf I would think since
>
On 9/13/2021 8:58 AM, John David Anglin wrote:
On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
We used embedded stabs for SOM (the native format for 32bit PA). SOM is a
variant of COFF and could
On Mon, Sep 13, 2021 at 10:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restri
On Mon, Sep 13, 2021 at 10:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restri
On 2021-09-13 11:05 a.m., Jeff Law wrote:
>
>
> On 9/13/2021 8:58 AM, John David Anglin wrote:
>> On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
>>> We used embedded stabs for SOM (the native
On 9/13/2021 9:44 AM, John David Anglin wrote:
On 2021-09-13 11:05 a.m., Jeff Law wrote:
On 9/13/2021 8:58 AM, John David Anglin wrote:
On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
We used
On Wed, 18 Aug 2021, Sandra Loosemore wrote:
> I realized last week that having multilib-specific versions of
> ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it
> supports) was still broken outside of the test support; the directory where
> it's being installed isn't on
Hi Gerald,
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >.../GCC-HEAD/libgfortran/ISO_Fortran
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
>
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic fr
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HE
On 9/13/21 4:18 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
>
>>> So it looks like there's some undefined behavior going on, even before
>>> my patch. I'd like to get some feedback, because this is usually the
>>> type of problems I see in the presence
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /u
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is dupl
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote:
> Regarding FreeBSD: Does this output different values? – If yes, we know
> what to do, otherwise – hmm.
>
> [...]
>
> > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
> > > float.h? The header doesn't want
On Sep 13 2021, Gerald Pfeifer wrote:
> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
>
> This looks like it
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
>
> 2021-08-31
On Mon, Sep 13, 2021 at 05:56:53PM +0200, Gerald Pfeifer wrote:
> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> /usr/include/x86/float.h:#define LDBL_MAX_EXP 163
Hi,
PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you mean 'typedef'?".
This happens because the typo corrector determines that `typeof` is a
candidate for suggestion (through `cp_keyword_starts_decl_specifier_p`),
but `typedef` is not.
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This is another patch that looks bigger than it really is. Because we
> have a new namespace for the builtins, allowing us to have both the old
> and new builtin infrastructure supported at once, we need versions of
> these f
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. Previously,
>
Hi Folks
> On 10 Sep 2021, at 16:16, Jeff Law wrote:
> On 9/10/2021 1:19 AM, Richard Biener via Gcc-patches wrote:
>> This removes the always defined DARWIN_PREFER_DWARF and the code
>> guarded by it being not defined, removing the possibility to
>> default some i386 darwin configurations to STAB
On 9/13/2021 10:52 AM, Koning, Paul wrote:
On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and remove
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000-builtin
I merged trunk revision 104c05c5284b7822d770ee51a7d91946c7e56d50 to
the gccgo branch.
Ian
Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call to O::O(&_M_rest, 42) produces no side
effects that actually activates the member, so the union still appears
uninitialized after th
On Linux/x86_64,
76b75018b3d053a890ebe155e47814de14b3c9fb is the first bad commit
commit 76b75018b3d053a890ebe155e47814de14b3c9fb
Author: Jason Merrill
Date: Thu Jul 15 15:30:17 2021 -0400
c++: implement C++17 hardware interference size
caused
FAIL: 29_atomics/atomic_flag/test_and_set/ex
On 9/12/21 2:26 PM, Segher Boessenkool wrote:
>> I also removed the mma_xxsetaccz define_expand and
>> define_insn_and_split and replaced it with a simple define_insn.
>
> In the future pleaase do that in a separate patch. That makes it *much*
> easier to read and review this.
Will do.
>>
On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
> Hi,
>
> PR77565 reports that, with the code `typdef int Int;`, GCC emits
> "did you mean 'typeof'?" instead of "did you mean 'typedef'?".
>
> This happens because the typo corrector determines that `typeof` is a
> candidate
1 - 100 of 111 matches
Mail list logo
