https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
--- Comment #3 from Patrick Palka ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555465.html
cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957. In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
cache (which
Please excuse a comment from the gallery:
On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> wrote:
> > 2020-08-13 Raoni Fassina Firmino
> >
> > gcc/ChangeLog:
> > * config/rs6000/rs6000.md
Snapshot gcc-11-20201004 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20201004/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Sat, 3 Oct 2020 at 01:14, Jonathan Wakely wrote:
> OK for trunk with those leading spaces switched to tab.
The patch is borked, doesn't pass tests, fixing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #5 from Bill Long ---
The original intent of adding the KIND argument was because some
implementations used a 32-bit integer for the result, and it is possible for
the answer to be larger than 2**31-1. Just checking to be sure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97288
--- Comment #1 from Amir Kirsh ---
For user defined type this behavior might be ok, as the order of evaluation of
parameters is not defined, however this behavior is reflected also for
primitive types:
int main() {
int a {5};
(a += 1)
In general yes.
Of course 64k would be the optimal value for buffer size for both windows and
linux. However, I think iostream is an old thing. Setting it as optimal value
might create compatibility issues.
Yes. This patch is good.
Sent from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97288
Bug ID: 97288
Summary: Assignment sequence before order - evaluating
reference to value of right side not in order
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote:
> This breaks ia64:
>
> In file included from ./tm.h:23,
> from ../../gcc/gencheck.c:23:
> ./options.h:7816:40: error: ISO C++ forbids zero-size array 'explicit_mask'
> [-Werror=pedantic]
> 7816 | unsigned
Hi FX,
> While this is fresh in your memory, could I suggest you have a look at this
> FINDLOC issue, which seems possibly related:
> https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html
> and further messages from Thomas Koenig?
I briefly checked this, but the issue with FINDLOC
> > >
> > > A number of people routinely send emails similar to these to this
> > > list to point out regressions on their targets. I find both kinds
> > > of emails very useful and don't mind the additional traffic.
> > >
> > > What would be an improvement is sending just one email for all
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:35d2c6b6e8a7448a84abbf967feeb78a29117014
commit r11-3646-g35d2c6b6e8a7448a84abbf967feeb78a29117014
Author: Harald Anlauf
Date:
On Sun, Oct 4, 2020 at 10:41 AM H.J. Lu via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor wrote:
> >
> > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > > wrote:
> > >>
> > >> On Sat,
On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor wrote:
>
> On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > wrote:
> >>
> >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> >> wrote:
> >>> On Linux/x86_64,
>
On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
wrote:
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
On Linux/x86_64,
c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97287
Bug ID: 97287
Summary: Warn for expanding range of an arithmetic type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On Sun, Oct 4, 2020 at 10:03 AM Iain Sandoe wrote:
>
> H.J. Lu via Gcc-patches wrote:
>
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > wrote:
> >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> >> wrote:
> >>> On Linux/x86_64,
> >>>
> >>>
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> I have a templated class C that required its type T to have operator
> bool() defined in order to work properly.
Never mind, I think there was some local error where things were not
being recompiled when they should be. I don't know why that
H.J. Lu via Gcc-patches wrote:
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
wrote:
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
wrote:
On Linux/x86_64,
c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97275
--- Comment #1 from Duncan Simpson ---
Further information: if I use the same compiler version but a x86_64-linux-gnu
version then I get a message from the assembler telling me than the strlr
instruction is not supported but no ICE.
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
wrote:
>
> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> wrote:
> > On Linux/x86_64,
> >
> > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > commit c34db4b6f8a5d80367c709309f9b00cb32630054
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Bug ID: 97286
Summary: GCC sometimes uses an extra xmm register for the
destination of _mm_blend_ps
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97070
--- Comment #4 from Ioannis E. Venetis ---
It seems that the problem was indeed some kind of confusion due to multiple gcc
installs. I removed the nvptx related packages of gcc-9.3.0 from my Ubuntu
16.04.7 LTS system (packages
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> But!! When I nm the individual cxx.o files none of these operator
> symbols appear, at all!
As you might have expected, this turns out to be wrong: the symbols
were just in a set of object files that I did not expect. I'll see if there's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96809
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-10-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
--- Comment #10 from Ev Drikos ---
(In reply to Dominique d'Humieres from comment #9)
> I think the two attached patches are not pertinent...
Possibly, you are right. I have no access to the
particular source code.
> I get
>
> 8 | call
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> I made it static inline like this:
>
> static inline bool operator!(T t) { return t != T::EMPTY; }
Obviously in my real code I used t == T::EMPTY here... :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97285
Bug ID: 97285
Summary: Interaction between no_unique_address and
has_unique_object_representations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
--- Comment #9 from Dominique d'Humieres ---
I think the two attached patches are not pertinent: both tests use independent
translation units, so they should compile.
If I couple the TUs as in
SUBROUTINE
Hi Segher,
On Fri, Oct 02, 2020 at 01:50:24PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 02, 2020 at 04:41:05PM +0930, Alan Modra wrote:
> > This moves an #ifdef block of code from calls.c to
> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> > define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
Bug ID: 97284
Summary: internal compiler error: 'global_options' are modified
in local context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
--- Comment #2 from Thomas Koenig ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282#c1 for one
example how this could be done for small integers (base 10 in that
case). The solution with the precomputed tables is probably not feasible
Hello Harald,
Slightly rewritten version of the patch, with the removal of the KIND
argument from the argument list factored out:
OK for master. I think it is also OK for backport as far as you want
to.
Best regards
Thomas
Hi Mark,
This is a follow up to PR95586 which fixed only the ICE that occurred
when using derived types in an implicit statement. The ICE occurred
because an attempt was made to determine kind for types that do not have
kinds.
This patch ensures that kind is only determined for types that
Hi Paul,
Regtests on FC31/x86_64 - OK for master?
OK.
You're quite right that trans-* is chock full of special-case
handling (which I also found out, again, working together
with Nicolas on the shared memory coarrays).
Cleaning that up would be a worthwile job, although probably
quite big
Hi FX,
While this is fresh in your memory, could I suggest you have a look at this
FINDLOC issue, which seems possibly related:
https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html
and further messages from Thomas Koenig?
I am actually working on this again, having returned from
Hi Harald,
While this is fresh in your memory, could I suggest you have a look at this
FINDLOC issue, which seems possibly related:
https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html
and further messages from Thomas Koenig?
Thanks,
FX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97283
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
I'm using GCC 8.1.0 / binutils 2.30 (I plan to upgrade to latest stuff
in the next few weeks or so...), on GNU/Linux Intel 64bit.
I have a templated class C that required its type T to have operator
bool() defined in order to work properly.
I want to use that with a enum class so clearly that
cl_target_option'
7812 | struct GTY(()) cl_target_option
|^~~~
$ diff -u gcc-2020100[34]/Build/gcc/options.h
--- gcc-20201003/Build/gcc/options.h2020-10-03 04:50:58.0 +0200
+++ gcc-20201004/Build/gcc/options.h2020-10-04 04:25:18.0 +0200
43 matches
Mail list logo
