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
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
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 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
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
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..
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 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
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 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
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 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.
>
>
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
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: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
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/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/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/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 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
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 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
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: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
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:
> 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
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
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
> > 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
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
[ 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: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
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 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
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 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 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 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
38 matches
Mail list logo
