On Sat, Nov 21, 2020 at 10:46:45AM -0500, David Edelsohn wrote:
> On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
> wrote:
> >
> > PowerPC: require IBM long double for pr70117.
> >
> > Since the test is explicitly checking for IBM extended double, do not try to
> > run it when long double is IEE
On 11/20/20 12:00 PM, Martin Sebor via Gcc-patches wrote:
> To detect a subset of VLA misuses, the C front associates the bounds
> of VLAs in function argument lists with the corresponding variables
> by implicitly adding an instance of attribute access to each function
> declared to take VLAs w
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> In the VAX ISA INSV bitfield insert instruction is the only computational
> operation that keeps the condition codes, held in the PSL or Processor
> Status Longword register, intact. The instruction is flexible enough it
> could potentially be use
On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
wrote:
>
> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
> fixes. And a few c++ failures with similar symptoms. I'm not certain
> that it is due to this patch, but it's the likely suspect.
Yes, it's that patch.
Thi
On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
wrote:
>
> On 21/11/20 17:04 +, Jonathan Wakely wrote:
> >On 21/11/20 16:16 +0100, Andreas Schwab wrote:
> >>In file included from
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/in
I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes. And a few c++ failures with similar symptoms. I'm not certain
that it is due to this patch, but it's the likely suspect.
FAIL: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++
On Fri, Nov 20, 2020 at 05:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
> On 11/16/20 9:58 PM, Marek Polacek wrote:
> > [dcl.constexpr]/3 says that the function-body of a constexpr function
> > shall not contain an identifier label, but we aren't enforcing that.
> >
> > This patch implement
[ cc'd to the fortran mailing list to hopely get some more knowledgeable
input ... ]
On 11/20/20 4:38 AM, Maciej W. Rozycki wrote:
2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
floating-point arithmetic (possibly a porting problem too).
gcc/libgfortran/config.h.in
On Fri, Nov 20, 2020 at 05:23:56PM -0500, Jason Merrill wrote:
> On 11/17/20 2:32 PM, Marek Polacek wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/warn/Wvexing-parse9.C
> > @@ -0,0 +1,8 @@
> > +// PR c++/97881
> > +// { dg-do compile }
> > +
> > +void
> > +cb ()
> > +{
> > + volatile _Ato
> > I tested this by building and running a bunch of workloads for SVE,
> > with three options:
> >
> > (1) -O2
> > (2) -O2 -ftree-vectorize -fvect-cost-model=very-cheap
> > (3) -O2 -ftree-vectorize [-fvect-cost-model=cheap]
> >
> > All three builds used the default -msve-vector-bits=scalable
Hi!
On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> >is explicitly set (or reset) on the command line, this should override
> >any implicit change due to -f(n
On 21/11/20 17:04 +, Jonathan Wakely wrote:
On 21/11/20 16:16 +0100, Andreas Schwab wrote:
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> The use of a constant double zero is required for post-reload compare
> elimination to be able to discard redundant floating-point comparisons,
> for example with a VAX RTL instruction stream like:
>
> (insn 34 4 3 2 (parallel [
> (set
Maybe this last patch that has been out for a while.
Here it is again rebased as some symbols have been added since my last
proposal.
François
On 14/10/20 6:10 pm, François Dumont wrote:
After further testing this version was bugged because ld considered
that __create_backtrace/__render_back
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> It makes no sense for insn operand predicates, as long as they accept a
> register operand, to be more restrictive than the set of the associated
> constraints, because expand will choose the insn based on the relevant
> operand being a pseudo regi
On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> We have matching insns defined for `sign_extract' and `zero_extract'
> expressions, so make the three named patterns for bitfield operations
> consistent and make `extv' an expander rather than an insn taking a
> SImode, a QImode, and a SImode gene
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> The INSV machine instruction is the only computational operation in the
> VAX ISA that keeps condition codes intact. In preparation to MODE_CC
> transition keep patterns apart then that make or do not make use of said
> instruction. For consisten
Hi,
We now determine depnedencies across union fields correctly so 2 instead
of 1 loops are vectorized.
regtsted x86_64-linux, comitted.
* gcc.dg/vect/vect-35-big-array.c: Excpect 2 loops to be vectorized.
* gcc.dg/vect/vect-35.c: Excpect 2 loops to be vectorized.
diff --git a/gc
On 21/11/20 16:16 +0100, Andreas Schwab wrote:
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> With the `*insv_aligned', `*extzv_aligned' and `*extv_aligned' insns we
> are going to adjust the bitfield location if it is in memory, so only
> allow such location addresses that can be offset, excluding external
> symbol references in the PIC mo
On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> It makes no sense for insn operand predicates, as long as they accept a
> register operand, to be more restrictive than the set of the associated
> constraints, because expand will choose the insn based on the relevant
> operand being a pseudo regi
On 11/3/20 2:14 PM, Nathan Sidwell wrote:
> The 'included from ...' chain that one gets at the start of a
> diagnostic needs extending to include importing. There are a few
> combinations to handle, but nothing particularly exciting.
>
>
> 09-core-diag.diff
>
OK with a ChangeLog
jeff
On 11/3/20 1:03 PM, Nathan Sidwell wrote:
> Here are the changes for gcc/configure.ac (config.h.in and configure
> get rebuilt). This is adding smarts to check for networking features,
> so that a network-aware module mapper can be built.
>
>
>
> 10-core-config.diff
>
OK with a ChangeLog.
jeff
On 11/15/20 3:06 PM, Jozef Lawrynowicz wrote:
> The "persistent" attribute is used for variables that are initialized
> by the program loader, but are not initialized by the runtime startup
> code. "persistent" variables are placed in a non-volatile area of
> memory, which allows their value to
Ping?
I was able to pass glibc's complete ifunc tests with no problem.
Samuel
Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
>
> 2020-11-08 Samuel Thibault
>
> gcc/
> * config.gcc: Enable default_gnu_indirect_function
On 11/15/20 3:05 PM, Jozef Lawrynowicz wrote:
> Attribute handlers may want to examine DECL_INITIAL for a decl, to
> validate the attribute being applied. For C++, DECL_INITIAL is currently
> not set until cp_finish_decl, by which time attribute validation has
> already been performed.
>
> For m
On 11/15/20 3:03 PM, Jozef Lawrynowicz wrote:
> Variables with the "noinit" attribute are ignored at -O0 because they
> are treated like a regular bss variable and placed in the .bss section.
>
> With -fdata-sections they are ignored because they are not handled in
> resolve_unique_section.
>
>
Hi, Thomas
I see
"during GIMPLE pass: omplower"
message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c
explicitly prunes that output, but kernels-decompose-ice-2.c does not.
Is there a reason that the second testcase does not prune that output
or can we add it?
Thanks, David
On Tue,
On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
wrote:
>
> PowerPC: require IBM long double for pr70117.
>
> Since the test is explicitly checking for IBM extended double, do not try to
> run it when long double is IEEE 128-bit.
>
> I have tested this patch and the first patch in the series on a
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux
On November 21, 2020 8:21:42 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following patch recognizes some further forms of additions with
>overflow
>checks as shown in the testcase, in particular where the unsigned
>addition is
>performed in a wider mode just to catch overflow with a >
>narrowe
On 11/21/20 12:07 AM, Jeff Law wrote:
On 11/9/20 9:00 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes. I'm open to giving
it a try i
On 2020-11-19 06:55, Jeff Law wrote:
>
>
> On 11/15/20 6:04 AM, J.W. Jagersma via Gcc-patches wrote:
>> On 2020-11-13 09:41, Richard Biener wrote:
>>> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches
>>> wrote:
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 2a409dcaffe..
Hi
The sanitizer is supported for at least x86_64 and Darwin20.
tested on a bunch of darwin platforms (including x86_64-darwin20) and
on x86_64-linux,
pushed to master
thanks
Iain
libsanitizer/ChangeLog:
* configure.tgt: Allow x86_64 Darwin2x.
---
libsanitizer/configure.tgt | 2 +-
1
Hi Thomas,
Thomas Koenig via Fortran wrote:
tested on a number of Darwin platforms old and new, and on
x86_64/powerpc64-linux,
OK for master?
… and backports to open branches?
One question...
+# ifdef __APPLE__
+# include
+# define environ (*_NSGetEnviron ())
Is it guaranteed that crt
this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
This is a step in our voyage to stop lying to the middle end :-)
Regression-tested. OK for trunk?
Ping?
(I am not 100% sure this mail ever made it to
Hi Iain,
tested on a number of Darwin platforms old and new, and on
x86_64/powerpc64-linux,
OK for master?
… and backports to open branches?
One question...
+# ifdef __APPLE__
+# include
+# define environ (*_NSGetEnviron ())
Is it guaranteed that crt_externs.h is present if __APPLE__
i
On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote:
> > So that likely means you are doing it too early.
>
> The bounds are added to attribute "arg spec" for each param in
> push_parm_decl. I think that's both as early and (except maybe
> in function definitions) as late
38 matches
Mail list logo
