On Fri, Jun 21, 2019 at 3:52 PM Martin Sebor wrote:
>
> Most of the rest seem justified to me and worth cleaning up. Let
> me know if you agree and if you'd like my help with it.
Thanks. I sent https://golang.org/cl/183437 and
https://golang.org/cl/183497 to take care of these.
Ian
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this
On 6/22/19 5:57 PM, Marek Polacek wrote:
Now that DEFAULT_ARG is used for more things than just default arguments,
let's rename it and its related entities to something more appropriate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Jason
On 6/13/19 5:03 PM, Marek Polacek wrote:
Case values are converted constant expressions, so narrowing conversion is not
permitted. This patch adds detecting narrowing to case_conversion; it's a
handy spot because we have both the value and the (adjusted) type of the
condition.
Is there a
Snapshot gcc-9-20190622 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190622/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9
On Sat, 22 Jun 2019, Richard Biener wrote:
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
Hello,
as discussed in the PR, this seems like a simple enough approach to
handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key
On Sun, Jun 23, 2019 at 3:27 AM Jonathan Wakely
wrote:
> On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
> >
> > On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> > wrote:
> >
> > > On Jun 22 2019, Akshat Garg wrote:
> > >
> > > > I believe I should be getting a warning like:
> > > > warning:
On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
>
> On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> wrote:
>
> > On Jun 22 2019, Akshat Garg wrote:
> >
> > > I believe I should be getting a warning like:
> > > warning: initialization from incompatible pointer type
> > >
Now that DEFAULT_ARG is used for more things than just default arguments,
let's rename it and its related entities to something more appropriate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-22 Marek Polacek
* call.c (convert_default_arg): Use DEFERRED_PARSE instead
On 6/22/19 12:44 PM, Segher Boessenkool wrote:
> On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
>> On 6/22/19 7:55 AM, Jason Duerstock wrote:
>>> More generally, we can rewrite
>>>
>>> if ( x > ((1 << z) -1)) { ...}
>>>
>>> as
>>>
>>> if ( x >> z ) { ... }
>>>
>>> This does not appear
The two tests use decimal floating point and therefore fail where that isn’t
available.
Fixed for Darwin by adding the relevant dg-requires lines
(I didn’t try to alter the cases for AIX, but maybe the skip lines could be
removed now).
tested on powerpc-darwin9, applied to mainline,
thanks
Iain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89782
--- Comment #6 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Jun 22 19:58:47 2019
New Revision: 272594
URL: https://gcc.gnu.org/viewcvs?rev=272594=gcc=rev
Log:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c
This test was failing because of a pedantic warning that is unrelated to the
purpose of the test. Fixed by suppressing that warning.
tested on powerpc-darwin9, applied to mainline.
thanks
Iain
2019-06-22 Iain Sandoe
* gcc.target/powerpc/darwin-bool-1.c: Suppress the pedantic
On Sat, Jun 22, 2019 at 11:49:25AM -0700, Jerry DeLisle wrote:
> On 6/22/19 11:32 AM, Steve Kargl wrote:
> > On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
> >>
> >> 2019-06-22 Jerry DeLisle
> >>
> >>PR fortran/89782
> >>* io.c (gfc_resolve_dt): Check that internal units
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing.
On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
> On 6/22/19 7:55 AM, Jason Duerstock wrote:
> > More generally, we can rewrite
> >
> > if ( x > ((1 << z) -1)) { ...}
> >
> > as
> >
> > if ( x >> z ) { ... }
> >
> > This does not appear to currently be a gcc optimization. What is
>
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
>
> 2019-06-22 Jerry DeLisle
>
> PR fortran/89782
> * io.c (gfc_resolve_dt): Check that internal units are not
> character PARAMETER.
This part of the patch is missing.
>
> *
Hi all,
The front-end is not consistently checking for errors with character parameters
as internal units. The reason is we never actually checked for this before. In
some cases an error message is triggered from other unrelated causes or
sometimes no error is given at all.
This is fixed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347
--- Comment #7 from Eric Gallager ---
(In reply to Richard Biener from comment #6)
> Reconfirmed. Note we do vectorize the loop now but we add a runtime check
> for the aliasing (and not move the invariant out either).
So wait if the
> Hello.
> I have already sent a patch for expanding roundeven for i386 with
> relevant doubts. I also was regression testing with
> make -k check
> after successful bootstrap build with reverting my patches. Turns out
> do-check fails without any patches applied, Is it ok to do anyways for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90965
Bug ID: 90965
Summary: Improve diagnostic for out-of-line constructor
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Hello.
I have already sent a patch for expanding roundeven for i386 with
relevant doubts. I also was regression testing with
make -k check
after successful bootstrap build with reverting my patches. Turns out
do-check fails without any patches applied, Is it ok to do anyways for
applied patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #48 from Kaz Kylheku ---
(In reply to Thomas Koenig from comment #47)
> I see two problems with this suggestion, one minor and one major.
>
> First, there may well be a value > 1 on the stack for a regular
> call, see comment #15.
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
>Hello,
>
>as discussed in the PR, this seems like a simple enough approach to
>handle
>FENV functionality safely, while keeping it possible to implement
>optimizations in the future.
>
>Some key missing things:
>- handle C, not just C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90455
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90455
--- Comment #2 from Marek Polacek ---
Fixed (by r272287 I suspect).
I suspect Wilco forgot commit this hunk which fixes the avr port after
the recent setjmp/longjmp changes. Tested on the avr-elf port which
builds again.
Committed to the trunk.
Jeff
commit 72f5e18d923404533b58a997735f8c09c6d12bb3
Author: law
Date: Sat Jun 22 16:31:50 2019 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58836
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65707
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89480
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
My fix for c++/60223 (ICE with T{} in non-deduced context) fixed these three
tests also. Yay!
Tested on x86_64-linux, applying to trunk.
2019-06-22 Marek Polacek
PR c++/65707
PR c++/89480
PR c++/58836
* g++.dg/cpp0x/nondeduced5.C: New test.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65707
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 16:29:06 2019
New Revision: 272589
URL: https://gcc.gnu.org/viewcvs?rev=272589=gcc=rev
Log:
PR c++/65707
PR c++/89480
PR c++/58836
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58836
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 16:29:06 2019
New Revision: 272589
URL: https://gcc.gnu.org/viewcvs?rev=272589=gcc=rev
Log:
PR c++/65707
PR c++/89480
PR c++/58836
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89480
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 16:29:06 2019
New Revision: 272589
URL: https://gcc.gnu.org/viewcvs?rev=272589=gcc=rev
Log:
PR c++/65707
PR c++/89480
PR c++/58836
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90964
--- Comment #1 from Olivier Croquette ---
Also reported in the MinGW-w64 project:
https://sourceforge.net/p/mingw-w64/bugs/800/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90964
Bug ID: 90964
Summary: SJLJ: Backtrace stopped: previous frame inner to this
frame (corrupt stack?)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
Hello,
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key missing things:
- handle C, not just C++ (I don't care, but some people probably do)
- handle vectors (for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66256
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66256
--- Comment #13 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 15:51:49 2019
New Revision: 272588
URL: https://gcc.gnu.org/viewcvs?rev=272588=gcc=rev
Log:
PR c++/66256
* g++.dg/cpp0x/noexcept54.C: New test.
Added:
Now that the parsing of noexcept-specifiers is properly delayed, this test
gives the error it should.
Tested x86_64-linux, applying ot trunk.
2019-06-22 Marek Polacek
PR c++/66256
* g++.dg/cpp0x/noexcept54.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/noexcept54.C
On 6/22/19 7:55 AM, Jason Duerstock wrote:
> I was starting at the assembly from some of the Python source, and
> came across this (simplified) comparison:
>
> if (x > 2305843009213693951) {...}
>
> This is the same as:
>
> if (x > 0x1fff) {...}
>
> This is equivalent to:
>
> if
>
> Ah, no, of course not. I guess the early out here should be a
> "ignore this match" instead.
Here is updated patch with a testcase I have re-tested on x86_64-linux
and comitted. There are still few divergences left, I will debug them
now.
Again the testcase has extra wrapper in struct d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90537
Bug 90537 depends on bug 86476, which changed state.
Bug 86476 Summary: Members declared later in a class appear to be unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90963
Bug ID: 90963
Summary: [10 Regression] FAIL:
gcc.c-torture/execute/built-in-setjmp.c execution test
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #18 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 15:14:30 2019
New Revision: 272586
URL: https://gcc.gnu.org/viewcvs?rev=272586=gcc=rev
Log:
PR c++/86476 - noexcept-specifier is a complete-class context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 15:14:30 2019
New Revision: 272586
URL: https://gcc.gnu.org/viewcvs?rev=272586=gcc=rev
Log:
PR c++/86476 - noexcept-specifier is a complete-class context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #9 from Federico Kircheis ---
Hi,
did you consider my last comment (Comment 6)?
I find it unfortunate that gcc will not warn anymore about unused variables in
some circumstances.
Maybe my example was not a good one, but I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 90881, which changed state.
Bug 90881 Summary: -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Sat Jun 22 14:43:00 2019
New Revision: 272585
URL: https://gcc.gnu.org/viewcvs?rev=272585=gcc=rev
Log:
PR c++/90881 - bogus -Wunused-value in unevaluated context.
*
I was starting at the assembly from some of the Python source, and
came across this (simplified) comparison:
if (x > 2305843009213693951) {...}
This is the same as:
if (x > 0x1fff) {...}
This is equivalent to:
if (x >> 61) {...}
More generally, we can rewrite
if ( x > ((1 << z)
On 18/06/2019 at 00:05, Jeff Law wrote:
If you're going to insist on doing this with an ASM you're likely going
to need to only use registers and constants for constraints since
otherwise you run the risk of getting a stack address.
Thanks for all your clarifications and suggestions.
To
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90962
Bug ID: 90962
Summary: Array bound over optimization
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
wrote:
> On Jun 22 2019, Akshat Garg wrote:
>
> > I believe I should be getting a warning like:
> > warning: initialization from incompatible pointer type
> > [-Wincompatible-pointer-types]
> > but in the gcc.log file, I found this:
> > error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #47 from Thomas Koenig ---
(In reply to Kaz Kylheku from comment #45)
> Hi everyone.
>
> Pardon my ignorance of C-Fortran bridging matters, but does any of the
> following make sense?
>
> The Fortran subroutine has no idea whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2
On Jun 22 2019, Akshat Garg wrote:
> I believe I should be getting a warning like:
> warning: initialization from incompatible pointer type
> [-Wincompatible-pointer-types]
> but in the gcc.log file, I found this:
> error: initialization of '_Atomic struct rcutest *' from incompatible
> pointer
On Fri, Jun 21, 2019 at 8:38 PM H.J. Lu wrote:
> > > > > > > > > >> > > +/* Register pair. */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI P4QI */
> > > > > > > > > >> > >
> > > > > > > > > >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #46 from Kaz Kylheku ---
C pseudocode in light of previous comment:
double abused_fortran_fn(double x, double y, char str[1], int len)
{
if (len != 1)
return abused_fortran_fn(x, y, str, 1); /* full call, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #45
62 matches
Mail list logo
