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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511
eggert at cs dot ucla.edu changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
--- Comment #1 from H.J. Lu ---
Also:
FAIL: 29_atomics/atomic_integral/wait_notify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Bug ID: 97936
Summary: [11 Regression] 30_threads/latch/3.cc hangs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935
Bug ID: 97935
Summary: Missing subsumption in iterator category detection
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278
--- Comment #9 from Andrew Pinski ---
(In reply to danikiw542 from comment #8)
> https://kodlogs.com/blog/852/warning-control-reaches-end-non-void-function-
> wreturn-type
values not defined in enum's are still valid and well defined, that is
Snapshot gcc-10-20201121 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20201121/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934
Bug ID: 97934
Summary: Defaulting <=> breaks other equality operators
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 94695, which changed state.
Bug 94695 Summary: Implement -Wrange-loop-analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c51e31a06f2c740c55852a683aa7ffdc20417362
commit r11-5234-gc51e31a06f2c740c55852a683aa7ffdc20417362
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97846
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97846
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6f20c42cc162ac3725584547ab4933bae4c78665
commit r11-5233-g6f20c42cc162ac3725584547ab4933bae4c78665
Author: Marek Polacek
Date:
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
[ 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0999f26098598fe0a499c5b79ad23678ccfe583a
commit r11-5232-g0999f26098598fe0a499c5b79ad23678ccfe583a
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:78cd6a63ee67ed854fbe54dd7c0a500dc138459a
commit r11-5230-g78cd6a63ee67ed854fbe54dd7c0a500dc138459a
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427
--- Comment #3 from Marek Polacek ---
Fixed on trunk. I plan to backport to 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:caf17f3afa83623c0f538f6c91c7699c4fdd5674
commit r11-5228-gcaf17f3afa83623c0f538f6c91c7699c4fdd5674
Author: Marek Polacek
Date:
> > 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
On Thu, 19 Nov 2020, Florian Weimer wrote:
> > Should we have a Git commit hook to catch that (and similar variants)?
>
> It's also possible to move to a mailing list host which does not
> rewrite the From: header. The commit hook is better than nothing,
> although it's probably a bit
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278
danikiw542 at bcpfm dot com changed:
What|Removed |Added
CC||danikiw542 at bcpfm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #8 from Mikael Morin ---
(In reply to Mikael Morin from comment #7)
> Well, it doesn’t fix comment #5. :-(
Pilot error, it does fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> rough patch
>
Well, it doesn’t fix comment #5. :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #6 from Mikael Morin ---
Created attachment 49609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49609=edit
rough patch
OK, I understand better the problem.
It’s not a bug that the kind argument is not used to produce code.
It
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97818
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97818
--- Comment #1 from Dominique d'Humieres ---
Confirmed from GCC8 up to trunk (for -O1 only). The code doesN't compile with
GCC7.
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
--- Comment #7 from Dominique d'Humieres ---
>just checked with today's trunk and --enable-checking=yes,extra,rtl
> working there.
What was the failing version?
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
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
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Bug ID: 97933
Summary: [11 Regression] Bootstrap failure on s390x-linux
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
H.J. Lu changed:
What|Removed |Added
CC||dmalcolm at redhat dot com
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 >
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
Lance de la Haye changed:
What|Removed |Added
Version|8.2.0 |10.2.0
--- Comment #3 from Lance de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
--- Comment #2 from Lance de la Haye ---
Also verified with mingw64 build from winlibs.com
gcc --version
gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Hi,
*Greetings from Travelize!!*
Setting up a hassle free work environment is what makes the Company
beneficial.
So, we are delighted to introduce our product “Travelize”
Travelize helps you to,
*1.* *Get to know your field sales teamwork-status.*
*2.* *Schedule the Meetings/Task
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
Bug ID: 97932
Summary: Preprocessor, generated error dumps most of the source
file, not just one line.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
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
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__
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
77 matches
Mail list logo
