[Bug target/50928] m32c ICE building RTEMS

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

--- Comment #17 from Eric Gallager  ---
*** Bug 63683 has been marked as a duplicate of this bug. ***

[Bug target/63683] m32c-rtems ICE unable to find spill register compiling libgcc

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63683

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
(In reply to Bernd Edlinger from comment #2)
> Hi,
> 
> this looks like a duplicate of pr50928

OK, closing as such

*** This bug has been marked as a duplicate of bug 50928 ***

[Bug target/50928] m32c ICE building RTEMS

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #16 from Eric Gallager  ---
(In reply to DJ Delorie from comment #15)
> The binutils team has been working a lot on patching vulnerabilities in the
> binutils tools.  The m32c, however, has a 3-byte reloc that might occur at
> the end of a section, and was implemented as three bytes of a four-byte
> "word", which would then be outside the bounds of the section.  Recent
> patches check for such bounds crossings, hence the breakage.  I've checked
> in a patch to binutils head to manually process the R_M32C_24 relocations so
> that the range checking is more appropriate to the three-byte relocation.

Which version of binutils was the patch released in?

[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #13 from Eric Gallager  ---
(In reply to Oleg Endo from comment #12)
> (In reply to Oleg Endo from comment #11)
> > 
> > seems to fix the test case of PR 34807.  However, I've not tested it any
> > further and probably the fix is incomplete and works only for mem loads and
> > not stores.
> > In fact it can be broken again quite easily by inserting another insn that
> > requires R0 (tst #imm,r0 in this case):
> > 
> > int glob, glob1;
> > 
> > static int _dl_mmap (int xx)
> >  {
> >register int __sc0 __asm__ ("r0") = glob1;
> >register int __sc1 __asm__ ("r1") = glob;
> > 
> >if (xx & 3)
> >  __asm__  ("trapa %1 " : "=z" (__sc0) : "i" (0x10), "0" (__sc0), "r"
> > (__sc1));
> > 
> >return (__sc0);
> >  }
> >  
> >  void _start(int xx)
> >  {
> >static int buf;
> >buf = _dl_mmap(xx);
> >  }
> 
> I've tried that test case with the sh-lra branch and the problems seem to be
> gone.

So is this FIXED yet then?

[Bug target/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org
   Severity|normal  |minor

--- Comment #5 from Eric Gallager  ---
Changing severity to "minor" per https://gcc.gnu.org/bugs/management.html

[Bug target/15896] Strange behaviour for inline assembler input constraint

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15896

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> I don't know Ada that well (in terms of promotions and types) but the
> following C code produces the 
> same ICE so I might assume the issue is that My_Type+constant is being
> promoted to unsigned long 
> long or something along that line:
> int f()
> {
> unsigned long long cu32 = 1;
>   asm("%0"::"a"(cu32));
> }

Does this still happen with newer versions of GCC? I can't reproduce with gcc
7, but I'm assuming that's due to target differences; I get different messages
depending on 32-bit or 64-bit, but neither of them are an ICE:

$ gcc -c -m32 15896.c
15896.c: In function 'f':
15896.c:4:3: error: inconsistent operand constraints in an 'asm'
   asm("%0"::"a"(cu32));
   ^~~
$ gcc -c -m64 15896.c
15896.c:4:Junk character 37 (%).
15896.c:4:Rest of line ignored. 1st junk character valued 114 (r).
$

[Bug rtl-optimization/84842] [7/8/9 Regression] ICE in verify_target_availability, at sel-sched.c:1569

2018-07-02 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842

--- Comment #15 from Arseny Solokha  ---
(In reply to Alexander Monakov from comment #14)
> Arseny, in the meantime if by chance you have another x86_64 variant of this
> failure that doesn't require -funroll-all-loops, please post it as well.

Finally.

float
z6 (float gg, int rv)
{
  long int v9;

  while (-v9 / (!rv + 10) < (long unsigned int) ((gg + 1) / gg))
gg = (int) ((long unsigned int) (rv * 1.1f));

  return gg;
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20180701 -O2 -ffast-math -fschedule-insns
-fsel-sched-pipelining -fselective-scheduling -fsplit-paths -fno-tree-loop-im
-c scfabdxr.c

(as of 262290).

[Bug middle-end/77357] strlen of constant strings not folded

2018-07-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
Working on a patch.

[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases

2018-07-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #20 from Eric Gallager  ---
(In reply to Eric Gallager from comment #19)
> (In reply to Manuel López-Ibáñez from comment #11)
> > (In reply to comment #10)
> > > However, with so many lines of legacy code out there using bit-filed that 
> > > have
> > > been proven to work, it doesn't make sense to revisit/modify them.  Would 
> > > it
> > > be possible for gcc to provide a -Wbitfield-conversion flag in new 
> > > releases
> > > and make 39170 an enhancement (preferably high priority)?
> > 
> > Seriously, I am not the "maintainer" of GCC diagnostics
> 
> That's David Malcolm; adding him on cc

...and since he's now made himself the assignee, changing status to ASSIGNED

[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates

2018-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||rejects-valid
   Last reconfirmed||2018-07-02
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Class member access of  |[8/9 Regression] Class
   ||using|'d field goes|member access of |using|'d
   |horribly awry in presence   |field goes horribly awry in
   |of templates|presence of templates
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Started to be rejected with r251438:

PR c++/81236 - ICE with template-id in generic lambda

[Bug c++/86379] New: Class member access of |using|'d field goes horribly awry in presence of templates

2018-07-02 Thread jwalden+ggo at mit dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379

Bug ID: 86379
   Summary: Class member access of |using|'d field goes horribly
awry in presence of templates
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwalden+ggo at mit dot edu
  Target Milestone: ---

Created attachment 44345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44345=edit
Mostly-reduced testcase

SpiderMonkey is hitting compile errors with gcc 8/8.1/trunk (per godbolt) when,
inside a member function in a template class, accessing member functions on a
field inherited from a base class.  The error messages indicate that the member
isn't being found in a type that is *entirely different* from the type of the
member being 'using'd, so it looks like a member lookup is happening on an
entirely wrongly-computed type -- no other plausible explanation.

This is a regression in gcc 8; godbolt says 7.3 compiles it just fine.  clang
also has no problems with it.

I've attached a standalone testcase just over 200 lines long; compiler output
is tacked on the end of the file in a comment.  I could reduce further, but 1)
I'm guessing it's obvious which thing is miscomputed where, and 2) I'm unsure
exactly which interlocking parts of this, if removed, won't by pure
happenstance jar it back into alignment.

This is probably a duplicate, but I don't know the search terms to find the
original.  :-(

I can work around these issues by not |using| the various fields and instead
|this->|-qualifying them, but this gets pretty wordy.  If there's a better
workaround, I'd love to know it!

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #9 from Jonathan Wakely  ---
(In reply to U.Mutlu from comment #8)
> It is possible to fix all the warnings and then use -Werror.

But only today. Tomorrow's compilers will have different warnings. And
yesterday's compilers too.

I think what you're trying to do is not something anybody really cares about
supporting.

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread um at mutluit dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #8 from U.Mutlu  ---
If one activates -Werror then it won't build as it then treats the warnings as
error. And there are many warnings currently suppressed.
That means -Werror is deactivated by default, and IMO never activated by any of
the configure scripts.

It is possible to fix all the warnings and then use -Werror.
That means then that if there were a warning, then it wouldn't build.
But if the warnings are fixed, then it will build even with -Werror. 

I just have managed to fix all warnings in libiberty (a tedious work as one has
to start a clean-build after each fix done; but is manageable).

For C & C++ there are in total 7 such configure scripts (like libiberty)
needing such fixes:

../gcc_trunk/libiberty/configure
../gcc_trunk/fixincludes/configure
../gcc_trunk/libcpp/configure
../gcc_trunk/libdecnumber/configure
../gcc_trunk/mpfr-3.1.4/configure
../gcc_trunk/mpc-1.0.3/configure
../gcc_trunk/intl/configure

If one can use the following, then the fixes can be done easily:
  #pragma GCC diagnostic push
  #pragma GCC diagnostic warning "-Wunused-value"
  ...
  #pragma GCC diagnostic pop

But I'm not sure if that can be used if the building compiler is not gcc...
So, currently just playing with it to broaden by experience...

[Bug target/86285] We don't mangle __ieee128 correctly using -mlong-double-64 -mabi=ieeelongdouble

2018-07-02 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285

--- Comment #5 from Segher Boessenkool  ---
Author: segher
Date: Mon Jul  2 21:25:10 2018
New Revision: 262320

URL: https://gcc.gnu.org/viewcvs?rev=262320=gcc=rev
Log:
rs6000: Set up ieee128_float_type_node correctly (PR86285)

We shouldn't init __ieee128 to be the same as long double if the
latter is not even a 128-bit type.

This also reorders the nearby __ibm128 code so both types use similar
logic.


Backport from trunk
2018-06-26  Segher Boessenkool  

PR target/86285
* config/rs6000/rs6000.c (rs6000_init_builtins): Do not set
ieee128_float_type_node to long_double_type_node unless
TARGET_LONG_DOUBLE_128 is set.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

2018-07-02 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Bill Schmidt  ---
So, not a gcc bug.  Closing.

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
Generally you're not supposed to use -Werror with configure scripts like that;
configure scripts are supposed to set -Werror themselves only once it's safe to
do so

[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow

2018-07-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> I think I remember someone suggesting a progress bar at one point; it
> involved hacking the pass manager... 
> 
> (confirmed)

Right, I found the thread (I think) I was thinking of:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00957.html

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread um at mutluit dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #6 from U.Mutlu  ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error, 
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:

Example for the libiberty subdir: once w/o -Werror and once with -Werror:

< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function 
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function 
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no

And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...

So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:

> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> |   /* Ultrix mips cc rejects this.  */
> |   typedef int charset[2];
> |   const charset cs;
> |   /* SunOS 4.1.1 cc rejects this.  */
> |   char const *const *pcpcc;
> |   char **ppc;
> |   /* NEC SVR4.0.2 mips cc rejects this.  */
> |   struct point {int x, y;};
> |   static struct point const zero = {0,0};
> |   /* AIX XL C 1.02.0.0 rejects this.
> |  It does not let you subtract one const X* pointer from another in
> |  an arm of an if-expression whose if-part is not a constant
> |  expression */
> |   const char *g = "string";
> |   pcpcc =  + (g ? g-g : 0);
> |   /* HPUX 7.0 cc rejects these. */
> |   ++pcpcc;
> |   ppc = (char**) pcpcc;
> |   pcpcc = (char const *const *) ppc;
> |   { /* SCO 3.2v4 cc rejects this.  */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> | 
> | *t++ = 0;
> | if (s) return 0;
> |   }
> |   { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
> | int x[] = {25, 17};
> | const int *foo = [0];
> | ++foo;
> |   }
> |   { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> |   }
> |   { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. 
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> |   }
> |   { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> |   }
> |   return !cs[0] && !zero.x;
> | #endif
> | 
> |   ;
> |   return 0;
> | }

As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.

I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread um at mutluit dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #5 from U.Mutlu  ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error, 
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:

Example for the libiberty subdir: once w/o -Werror and once with -Werror:

< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function 
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function 
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no

And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...

So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:

> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> |   /* Ultrix mips cc rejects this.  */
> |   typedef int charset[2];
> |   const charset cs;
> |   /* SunOS 4.1.1 cc rejects this.  */
> |   char const *const *pcpcc;
> |   char **ppc;
> |   /* NEC SVR4.0.2 mips cc rejects this.  */
> |   struct point {int x, y;};
> |   static struct point const zero = {0,0};
> |   /* AIX XL C 1.02.0.0 rejects this.
> |  It does not let you subtract one const X* pointer from another in
> |  an arm of an if-expression whose if-part is not a constant
> |  expression */
> |   const char *g = "string";
> |   pcpcc =  + (g ? g-g : 0);
> |   /* HPUX 7.0 cc rejects these. */
> |   ++pcpcc;
> |   ppc = (char**) pcpcc;
> |   pcpcc = (char const *const *) ppc;
> |   { /* SCO 3.2v4 cc rejects this.  */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> | 
> | *t++ = 0;
> | if (s) return 0;
> |   }
> |   { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
> | int x[] = {25, 17};
> | const int *foo = [0];
> | ++foo;
> |   }
> |   { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> |   }
> |   { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. 
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> |   }
> |   { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> |   }
> |   return !cs[0] && !zero.x;
> | #endif
> | 
> |   ;
> |   return 0;
> | }

As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.

I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.

[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17

2018-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368

--- Comment #2 from Jonathan Wakely  ---
It might be reasonable for GCC to silently ignore attributes that use an
unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or
[[acme::rocketboots]] they probably aren't expecting GCC to handle it.

This could mean silently ignoring typos like [[ngu::unused]] but it's arguably 
easier to spot a typo like "ngu" than to spot "warn_unsued_result" or
"alwasy_inlne".

[Bug fortran/45305] Array-valued calles to elementals are not simplified

2018-07-02 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Mon Jul  2 19:28:11 2018
New Revision: 262316

URL: https://gcc.gnu.org/viewcvs?rev=262316=gcc=rev
Log:
2018-07-02  Paul Thomas  

PR fortran/45305
* expr.c : Add a prototype for scalarize_intrinsic_call.
(gfc_simplify_expr): Use scalarize_intrinsic_call for elemental
intrinsic function calls.
(scalarize_intrinsic_call): Add 'init_flag' argument. Check if
the expression or any of the actual argument expressions are
NULL. Before calling gfc_check_init_expr, check 'init_flag'.
Only simplify the scalarized expressions if there are no errors
on the stack.
(gfc_check_init_expr): Set 'init_flag' true in the call to
scalarize_intrinsic_call.

2018-07-02  Paul Thomas  

PR fortran/45305
* gfortran.dg/scalarize_parameter_array_2.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-array.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier

2018-07-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r257713.

[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier

2018-07-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier

2018-07-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-02
 Ever confirmed|0   |1

[Bug c++/86378] New: [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier

2018-07-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378

Bug ID: 86378
   Summary: [7/8/9 regression] typedef breaks functional cast in
noexcept-qualifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: jason at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

From https://bugzilla.redhat.com/show_bug.cgi?id=1597104

struct Pepper {};
struct Apple { Apple(int) {} };

struct Combination : Apple, Pepper
{
  Combination(Pepper p, Apple a)
: Apple(a), Pepper(p)
  {}
};

struct MyCombination
{
  using Spice = Pepper;
  using Fruit = Apple;

  Combination combination;

  template
  constexpr MyCombination(T&& t)
  noexcept(noexcept(Combination(Spice(), Fruit(t
: combination(Spice(), Fruit(t))
  {}
};

MyCombination obj(Apple(4));

[Bug c++/86354] Address comparison not a constant expression

2018-07-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86354

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
The static_assert can be just
static_assert( (X*)  != (X*) );

It ultimately comes down to symtab_node::equal_address_to, but due to the
extern y and z are interposable so it returns -1.

[Bug bootstrap/86376] recent breakage in ubsan build ?

2018-07-02 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376

--- Comment #2 from David Binderman  ---
(In reply to Martin Liška from comment #1)
> I'll take a look.

Thanks. This configure line seems to work ok:

../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \
--with-build-config=bootstrap-ubsan \
--disable-multilib \
--disable-werror \
--enable-checking=release \
--enable-languages=c,c++

So the problem seems to be either in the fortran area (possible,
but unlikely) or the checking flags.

I'll have a deeper look.

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #4 from Andrew Pinski  ---
NEED_DECLARATION_ERRNO should not be defined for most targets/hosts.  You need
to figure out why it is being defined here.  Look at config.log to figure that
out.

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread um at mutluit dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #3 from U.Mutlu  ---
As said in the Remarks, the bug originally was triggered in this file in the
trunk:
../gcc_trunk/libiberty/pex-common.c:28

#include 
#ifdef NEED_DECLARATION_ERRNO
extern int errno;
#endif

[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

--- Comment #2 from Jonathan Wakely  ---
In fact  is required to define it as a macro in C, and a footnote
says:
"The macro errno need not be the identifier of an object. It might expand to a
modifiable lvalue resulting from a function call (for example, *errno())."

Also since 'errno' is reserved as an identifier with external linkage, the
declaration in your program has undefined behaviour even if you don't include


[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
errno is a macro and is allowed to be by the C (and C++) standard.

[Bug c/86377] New: extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]

2018-07-02 Thread um at mutluit dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377

Bug ID: 86377
   Summary: extern int errno; is treated as buggy function
declaration [-Werror=strict-prototypes]
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: um at mutluit dot com
  Target Milestone: ---

Created attachment 44344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44344=edit
The output file of -save-temps (ie. the "file.i" file)

test file extern_var_bug.c:
- 
#include 
extern int errno;

int main(int argc, char* argv[])
{
  return errno;
}


Output:
---
extern_var_bug.c:2:16: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
 extern int errno;
^
extern_var_bug.c: In function 'main':
extern_var_bug.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
 int main(int argc, char* argv[])
  ^~~~
extern_var_bug.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
 int main(int argc, char* argv[])
~~^~
cc1: all warnings being treated as errors


Compiler and compile command:
-
# gcc-latest is v9 from svn trunk on x86_64
$ gcc-latest --version
gcc-latest (GCC) 9.0.0 20180701 (experimental) [trunk revision 262287]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc-latest -c -DHAVE_CONFIG_H -fopt-info -Wall -Wextra -Werror -Wpedantic
-pedantic -g0 -DNDEBUG -Ofast \
-I. -I../../gcc_trunk/libiberty/../include  -W -Wall -Wwrite-strings \
-Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE
-fpic \
\
-Wno-error=stringop-truncation -Wno-error=unused-parameter \
\
-x c \
-fno-strict-aliasing -fwrapv \
-save-temps \
\
extern_var_bug.c \


Remarks:

- The compile error happens only if  was included, and only if
compiled as C.
- The same error originally happened in 
../../gcc_trunk/libiberty/pex-common.c:28:1: error: function declaration isn't
a prototype [-Werror=strict-prototypes]
 extern int errno;
 ^~
when building with nearly almost all warnings enabled and -g0 -DNDEBUG.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-07-02 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Ian Lance Taylor  ---
This should now be fixed.

I filed the general issue of syscall.Syscall as https://golang.org/issue/26183.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-07-02 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #13 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Jul  2 16:29:24 2018
New Revision: 262315

URL: https://gcc.gnu.org/viewcvs?rev=262315=gcc=rev
Log:
PR go/86331
os: check return value as well as error from waitid

https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it
is possible for syscall.Syscall6 to return a non-zero errno value even
if no error occurs. That is a problem in general, but this fix will
let us work around the general problem for the specific case of
calling waitid.

Reviewed-on: https://go-review.googlesource.com/121595

Modified:
branches/gcc-7-branch/libgo/go/os/wait_waitid.go

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-07-02 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Jul  2 16:28:58 2018
New Revision: 262314

URL: https://gcc.gnu.org/viewcvs?rev=262314=gcc=rev
Log:
PR go/86331
os: check return value as well as error from waitid

https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it
is possible for syscall.Syscall6 to return a non-zero errno value even
if no error occurs. That is a problem in general, but this fix will
let us work around the general problem for the specific case of
calling waitid.

Reviewed-on: https://go-review.googlesource.com/121595

Modified:
branches/gcc-8-branch/libgo/go/os/wait_waitid.go

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-07-02 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #11 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Jul  2 16:28:43 2018
New Revision: 262313

URL: https://gcc.gnu.org/viewcvs?rev=262313=gcc=rev
Log:
PR go/86331
os: check return value as well as error from waitid

https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it
is possible for syscall.Syscall6 to return a non-zero errno value even
if no error occurs. That is a problem in general, but this fix will
let us work around the general problem for the specific case of
calling waitid.

Reviewed-on: https://go-review.googlesource.com/121595

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/os/wait_waitid.go

[Bug c/81577] -ftrack-macro-expansion=0 causes spurious “this ‘else’ clause does not guard” with -Wall

2018-07-02 Thread romain.geissler at amadeus dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81577

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #2 from Romain Geissler  ---
Hi,

This is still happening on released gcc 8.

Cheers,
Romain

[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

2018-07-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

2018-07-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #13 from Martin Sebor  ---
The sprintf pass doesn't consider NaNs and infinities.  The output for the
-fdump-tree-printf-return-value option shows:

;; Function main (main, funcdef_no=0, decl_uid=1898, cgraph_uid=1,
symbol_order=1) (executed once)

__builtin_snprintf: objsize = 220, fmtstr = "%f"
  Directive 1 at offset 0: "%f"
Result: 8, 8, 317, 322 (8, 8, 317, 322)
  Directive 2 at offset 2: "", length = 1
  Setting potentially out-of-bounds return value range [8, 322].

The range should be [3, 322].  Let me handle it.

[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17

2018-07-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
There is value in diagnosing the use of attributes that GCC doesn't know about.

According to the manual -Wattributes also sounds like the right option to
control warnings about unknown attributes.  Unfortunately, the option is also
used by GCC to control warnings about known attributes using in a way GCC
either doesn't consider valid or cannot honor and where -Wignored-attributes
might be more appropriate.  For example:

warning: ‘packed’ attribute ignored for field of type ‘char’ [-Wattributes]
 struct S { __attribute__ ((packed)) char c; };

Here, packed is used correctly but is "ignored" because it is implied on
members whose alignment is 8.  (It's ignored internally within GCC but that's
an implementation detail that's opaque to the user.  In this instance, I'd say
the warning should not be issued.)

Similarly for:

__attribute__ ((always_inline)) inline void f (void);

__attribute ((noinline)) void f (void);

warning: ignoring attribute ‘noinline’ because it conflicts with attribute
‘always_inline’ [-Wattributes]
 __attribute ((noinline)) void f (void);

where there's nothing wrong with either attribute but GCC can only honor one
and has to ignore the other.  Here, the warning is useful but distinct in
nature from an unknown attribute (like the one on bug 86243).

IMO, it should be possible to control warnings about attributes unknown to GCC
independently of other warnings about uses of known attributes.  Thus
confirmed.

[Bug c++/86243] unknown attribute before throw causes hard error

2018-07-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  GCC recognizes an attribute when it applies to other statements but
gets confused when it's applied to a throw expression statement as in comment
#0.

$ cat t.C && gcc -S t.C
int f ()
{
  [[unlikely]] return 0;
  [[unlikely]] { }

  [[unlikely]] throw 0;
}

t.C: In function ‘int f()’:
t.C:3:3: warning: attributes at the beginning of statement are ignored
[-Wattributes]
   [[unlikely]] return 0;
   ^
t.C:4:3: warning: attributes at the beginning of statement are ignored
[-Wattributes]
   [[unlikely]] { }
   ^
t.C:6:4: error: expected identifier before ‘[’ token
   [[unlikely]] throw 0;
^
t.C: In lambda function:
t.C:6:16: error: expected ‘{’ before ‘throw’
   [[unlikely]] throw 0;
^
t.C: In function ‘int f()’:
t.C:6:15: error: expected ‘;’ before ‘throw’
   [[unlikely]] throw 0;
   ^~
   ;

[Bug testsuite/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug bootstrap/86376] recent breakage in ubsan build ?

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-02
 CC||marxin at gcc dot gnu.org
  Component|c   |bootstrap
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug testsuite/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Jul  2 14:54:07 2018
New Revision: 262311

URL: https://gcc.gnu.org/viewcvs?rev=262311=gcc=rev
Log:
Fix GCOV scan pattern (PR testsuite/86366).

2018-07-02  Martin Liska  

PR testsuite/86366
* gcc.dg/profile-dir-1.c: Fix scanned pattern.
* gcc.dg/profile-dir-2.c: Likewise.
* gcc.dg/profile-dir-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/profile-dir-1.c
trunk/gcc/testsuite/gcc.dg/profile-dir-2.c
trunk/gcc/testsuite/gcc.dg/profile-dir-3.c

[Bug c/86376] New: recent breakage in ubsan build ?

2018-07-02 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376

Bug ID: 86376
   Summary: recent breakage in ubsan build ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Doing a ubsan build with revision 261981 worked. 

Doing same with revision 262304 doesn't. It breaks at
the compare of stage 2 and stage 3.

Configure line is

../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \
--with-build-config=bootstrap-ubsan \
--disable-multilib \
--disable-werror \
--enable-checking=df,extra,fold,rtl,yes \
--enable-languages=c,c++,fortran

[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jul  2 13:32:26 2018
New Revision: 262307

URL: https://gcc.gnu.org/viewcvs?rev=262307=gcc=rev
Log:
2018-07-02  Richard Biener  

PR tree-optimization/86363
* tree-ssa-sccvn.c (vn_reference_lookup_3): Check the
memset argument refers to a non-variable address.

* gcc.dg/torture/pr86363.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr86363.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug c++/86375] New: Lambda call in template parameter causes compile time error

2018-07-02 Thread antoshkka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86375

Bug ID: 86375
   Summary: Lambda call in template parameter causes compile time
error
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following example fail to compile:

template  struct stuff {};
stuff< [](){ return 42; }() > a; // Calling a constexpr lambda


Error message: 

lambda-expression in template-argument
 stuff< [](){ return 42; }() > a;


Replacing the lambda with variable that holds lambda works well:

template  struct stuff {};
auto f = [](){ return 42; };
stuff< f() > b; // OK

Clang compiles the first example well.

[Bug c++/86374] New: [8 regression] template member name lookup problem

2018-07-02 Thread s...@li-snyder.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374

Bug ID: 86374
   Summary: [8 regression] template member name lookup problem
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

hi -

With gcc checked out on 2018-07-01 from gcc-8-branch (rev 262277,
tested on x86_64-pc-linux-gnu [fedora 28]), this input:

-- y.cc 
template
struct list {
  static const int index = 1;
  template struct addWithChecking {};
};

template
struct find{
  static const int result = 0;
};

template 
template
struct list::addWithChecking
{
  static const int xres = find >::result;
};


gives an error:

$ cc1plus -quiet -v -D_GNU_SOURCE y.cc -quiet -std=c++17
...
y.cc:16:43: error: ‘index’ is not a member of ‘list’
   static const int xres = find >::result;
   ^
y.cc:16:43: error: template argument 2 is invalid


This was accepted by gcc on this branch as of early June, as well as
8.1.1 20180502 and clang 6.0.0.

The error started occurring with this change:

r261460 | jason | 2018-06-11 18:01:55 -0400 (Mon, 11 Jun 2018) | 5 lines

PR c++/85815 - reference to member of enclosing template.

* search.c (lookup_base): Use currently_open_class.
(lookup_member): Use it regardless of -fconcepts.
* parser.c (cp_parser_postfix_dot_deref_expression): Check it.

thanks,
sss

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.4

--- Comment #12 from Richard Biener  ---
So after gimplification I see

  __s = __builtin_alloca (__n);
  __builtin_va_start (&__args, 0);
  __len = __convf (__s, __n, __fmt, &__args);
  __builtin_va_end (&__args);
  std::allocator::allocator ();
  try
{
  try
{
  _1 = (sizetype) __len;
  _2 = __s + _1;
  std::__cxx11::basic_string::basic_string (,
__s, _2, );
  return ;
}
  finally
{
  std::allocator::~allocator ();
}

which after SSA rewrite looks like

  std::__cxx11::basic_string::basic_string (_16(D), __s_7, _2,
);

So we're rewriting  into SSA which is expected, 
is DECL_BY_REFERENCE.  So that is a red herring.

I suppose the new printf code simply doesn't handle default-defs that
come in as DECL_BY_REFERENCE RESULT_DECL.

Note what the pass causes is simply treating

_3 = vsnprintf (__s_2, 328, "%f", &__args);

as not returning zero and thus eliding a == 0 check.  For some reason
it says _3 is [8, 322] though but obviously 'NaN' prints as 3 characters
only...

So, martin?  Reduced testcase:

volatile double x;
int main()
{
  char *s = __builtin_alloca (220);
  x = __builtin_nan("nan");
  if (__builtin_snprintf (s, 220, "%f", x) != 3)
__builtin_abort ();
  return 0;
}

[Bug driver/86030] specs file processing does not create response files for input directories

2018-07-02 Thread tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030

--- Comment #3 from Tamar Christina  ---
Hmm according to 45749 with `HAVE_GNU_LD` on it should work for the ld call. I
will give that a try.

But the environment variable one is still an issue as far as I can tell.

[Bug driver/86030] specs file processing does not create response files for input directories

2018-07-02 Thread tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030

Tamar Christina  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2018-07-02
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #2 from Tamar Christina  ---
It seems that this is not fully fixed yet.

There are a number of other issues here.

Given a simple response file

   /d/t/temp cat foo
   test.c
   -L/tmp/temp
   -L/bar/temp/rr
   -ldata_boo


and calling

   gcc @foo -save-temps -###

shows a few problems.

At first glance it looks like the correct thing was done, the options are split
into two new response files and passed along to collect2 and the commandline
for collect2 no longer has the paths expanded in them.

   /d/t/temp cat /tmp/ccIP9us9
   test.o
   -ldata_boo

   /d/t/temp cat /tmp/ccSls8Kg
   -L/tmp/temp
   -L/bar/temp/rr

However, annoyingly, they have been expanded and placed into the
`COLLECT_GCC_OPTIONS` environment variable

   COLLECT_GCC_OPTIONS='-L/tmp/temp' '-L/bar/temp/rr' '-save-temps'
'-mlittle-endian' '-mabi=lp64'

Which means they're getting passed twice..

And finally it seems that when collect2 makes the call to ld, it places
everything on one giant commandline, undoing all the work
of creating the response files and exploding the path. collect2 should honor
the response files in it's output!

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

2018-07-02 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #12 from Rainer Orth  ---
The new testcase FAILs on Solaris/SPARC on trunk, gcc-7 and gcc-8 branches:

32-bit sparc:

+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -O0  execution test
+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -O1  execution test

64-bit sparc also:

+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -O2  execution test
+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -O3 -g  execution test
+FAIL: gfortran.dg/unlimited_polymorphic_30.f03   -Os  execution test

On gcc-testresults, there are also reports on hppa2.0w-hp-hpux11.11,
spu-unknown-elf.

The tests FAIL like this:

Program received signal SIGBUS: Access to an undefined portion of a memory
object.

Backtrace for this error:

gdb shows

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00011244 in MAIN__ ()
at
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13
13x%v = ['foo','bar']
(gdb) where
#0  0x00011244 in MAIN__ ()
at
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13

1: x/i $pc
=> 0x11244 :ld  [ %g1 ], %g1
(gdb) p/x $g1
$1 = 0x22a4b

i.e. an unaligned access.

[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> With gfortran 8 and trunk there is even a segfault at runtime (on the line
> "substr = '123'"), and the warning mentioned in PR 56670 comment 5:
> 
>   substr = '123'
>  
> Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized]

I guess the varying runtime behavior is caused by the uninitialized string
length. Setting it to the proper value should fix this bug.

[Bug c++/86373] New: Destructor shall not be instantiated in C++17 mode for prvalue

2018-07-02 Thread antoshkka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86373

Bug ID: 86373
   Summary: Destructor shall not be instantiated in C++17 mode for
prvalue
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following program fails to compile in -std=c++17 mode

struct some {
some() = default;
~some() = delete;
};

some foo() {
return {};
}

More realistic example:

#include 

struct some;
std::unique_ptr f() {
return {};
}

Output:

/opt/compiler-explorer/gcc-8.1.0/include/c++/8.1.0/bits/unique_ptr.h:79:16:
error: invalid application of 'sizeof' to incomplete type 'some'
  static_assert(sizeof(_Tp)>0,


However [basic.lval] say "The result object of a prvalue is the object
initialized by the prvalue; a prvalue that is used to compute the value of an
operand of an operator or that has type (possibly cv-qualified) void has no
result object."

So looks like std::unique_ptr has no object here, so the destructor shall
not be instantiated.

Clang compiles both of the above examples.

[Bug fortran/82865] Option -fdec collides with PDT

2018-07-02 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #14 from Fritz Reese  ---
(In reply to Rainer Orth from comment #13)
> 
> It seems the backport caused a caused quite a number on testsuite failures
> on the gcc-7 branch:
> ...

I reverted the backport in r262260. Are you certain that you still see those
errors after the reversion? That testcase file should no longer exist in the
tree.

> 
> Besides, all those svn property changes are at least unrelated.
> 
>   Rainer

That is what I suspected. ‘svn merge’ added them for some reason (even from a
clean tree). I’ll make sure to keep those out of future merges.

[Bug debug/78685] -Og generates too many ""s

2018-07-02 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685

Tom de Vries  changed:

   What|Removed |Added

  Attachment #44333|0   |1
is obsolete||

--- Comment #12 from Tom de Vries  ---
Created attachment 44343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44343=edit
[debug] Add -fkeep-vars-live

(In reply to Richard Biener from comment #10)
> (In reply to Tom de Vries from comment #8)
> > Created attachment 44333 [details]
> > proof of concept patch
> > 
> > I ran into the same problem with guality test-case pr54200.c, which fails
> > for Og.
> > 
> > The relevant part of the test-case is:
> > ...
> > int __attribute__((noinline,noclone))
> > foo (int z, int x, int b)
> > {
> >   if (x == 1)
> > {
> >   bar ();
> >   return z;
> > }
> >   else
> > {
> >   int a = (x + z) + b;
> >   return a; /* { dg-final { gdb-test 20 "z" "3" } } */
> > }
> > }
> > ...
> > 
> > The problem is that the '(x + z) + b' calculation has a temporary register
> > which  gets allocated the register that holds 'z', so when we get to the
> > gdb-test line, z is no longer available.
> > 
> > Using this patch I managed to print the correct value of z at the gdb-test
> > line.
> > 
> > The patch uses clobbers in gimple to mark the out-of-scope point, purely
> > because that's similar to what was already done for local array variables,
> > and I thought that was the fastest path to getting a proof of concept
> > working. It's more accurate to model this as some sort of use in gimple, and
> > doing so may prevent gimple optimizations which wreck debug info, but
> > perhaps that's not necessary, I suppose that depends on which optimizations
> > are enabled in Og.
> > 
> > Anyway, at expand we emit a use for the clobber which seems to do the trick.
> 
> An interesting idea but I think this will cause excessive spilling and
> come at a compile-time cost.  The idea of -Og was to have performance
> closer to -O1 here and with this we approach -O0 in assigning stack slots
> to all user variables?
> 

Agreed, there will be a compile time cost. I've moved the functionality to an
orthogonal option -fkeep-vars-live (as suggested in comment 3), to keep Og as
is.  Also, I agree there will be more spilling, but I'd hope that memory usage
still would be less than for O0.

> This is a general conflict of interest of course.
> 
> Your patch shouldn't prevent any optimization at the GIMPLE level
> (like completely eliding local variables) 

I've fixed that now, in the sense that it generates uses rather than clobbers
at gimple level.

> but definitely they'll keep
> things live at RTL level.  Given for the testcase at hand the issue
> is "suboptimal" choice of register allocation I wonder if we can
> adjust the RA / DF to consider liveness to extend always up to the
> next sequence point.
> 
> That is, it is reasonable to lose track of z in
> 
>   int a = (x + z) + b;
> 
> but only after x + z is computed.

Right, that could maybe be a way to improve on Og.

But the trade-off I'm going for currently with "Og -fkeep-vars-live" is:
O0-like debug experience, slower compilation than Og, faster execution than
-O0.

> So a different approach would be
> to see this as an issue with the way debug consumers "step" now that
> we emit column debug information?
> 
> That said, starting with GCC 8 we now have # DEBUG BEGIN_STMT
> markers:
> 
>[local count: 856416479]:
>   # DEBUG BEGIN_STMT
>   _1 = x_4(D) + z_7(D);
>   a_9 = _1 + b_8(D);
>   # DEBUG a => a_9
>   # DEBUG BEGIN_STMT
> 
> they are also present on RTL as
> 
> (debug_insn 21 20 0 (debug_marker) "t.c":11 -1
>  (nil))
> 
> which means we _could_ somehow use those for code-generation (in DF analysis
> to extend lifetimes somehow).  Of course if we do we have to emit those
> always to not get code-gen differences -g vs. -g0.
> 
> Maybe the RA could also be generally changed to use a not-LRU style
> preferencing of available registers to choose from.
> 
> In the end nothing saves us from "spilling" things if we really want to
> be able to access all final values of registers up to the point they
> go out of scope...
> 
> So another idea would be instead of like -O0 assigning the main location
> to the stack we spill no longer used vars during LRA?  We'd still have to
> somehow know until when that spill slot needs to live (and afterwards can
> be re-used).

To stay in terms of the current patch, that could mean we mark artificial uses
as such, and then make the compiler handle them smarter than regular uses.

[ Also, this version of the patch adds insertion of nops to prevent empty debug
ranges, which allows me to get the value of 'a' at the 'return a'  mentioned
above. ]

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
FRE uses native_encode_real / native_interpret_int to read the NAN as integer.
I suspect that something goes wrong with native_encode_real here or in
real_to_target which is used by that function.

[Bug lto/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

2018-07-02 Thread avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org

--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Martin,

We have also seen profile-dir-1.gcda fail on aarch64-none-linux-gnu and
arm-none-linux-gnueabihf, as well as profile-dir-3.gcda, recently.

I am assuming this is all related.

Cheers,
Andre

[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.2

[Bug bootstrap/86371] building compiler tries to look in $HOME/local/include

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86371

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  gcc/brig/Make-lang.in contains

BRIGINCLUDES = -I $(srcdir)/brig -I ${HOME}/local/include \
-I $(srcdir)/brig/brigfrontend

[Bug lto/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug fortran/82865] Option -fdec collides with PDT

2018-07-02 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #13 from Rainer Orth  ---
(In reply to Fritz Reese from comment #12)
> Author: foreese
> Date: Fri Jun 29 20:29:34 2018
> New Revision: 262260
> 
> URL: https://gcc.gnu.org/viewcvs?rev=262260=gcc=rev
> Log:
> Revert r262224 (backport of r262221) as PDTs are not supported in 7-branch.
> 
> gcc/fortran/ChangeLog:
> -2018-06-28  Fritz Reese  
> -
> - PR fortran/82865
> - Backport from trunk.
> - * decl.c (gfc_match_type): Refactor and check for PDT declarations.
> -
> 
> gcc/testsuite/ChangeLog:
> -2018-06-28  Fritz Reese  
> -
> - PR fortran/82865
> - Backport from trunk.
> - * gfortran.dg/dec_type_print_2.f03: New testcase.
> -
> 
> Removed:
> branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
> Modified:
> branches/gcc-7-branch/   (props changed)
> branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb   (props changed)
> branches/gcc-7-branch/gcc/fortran/ChangeLog
> branches/gcc-7-branch/gcc/fortran/decl.c
> branches/gcc-7-branch/gcc/testsuite/ChangeLog
> branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb   (props changed)
> 
> Propchange: branches/gcc-7-branch/
> ('svn:mergeinfo' modified)
> 
> Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
> ('svn:mergeinfo' modified)
> 
> Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
> ('svn:mergeinfo' modified)

It seems the backport caused a caused quite a number on testsuite failures
on the gcc-7 branch:

+FAIL: gfortran.dg/dec_type_print_2.f03   -O0  (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -O0  compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03   -O1  (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -O1  compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03   -O2  (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -O2  compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03   -O3 -g  (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -O3 -g  compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03   -Os  (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03   -Os  compilation failed to
produce executable

Excess errors:
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:12:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:13:12:
Error: Invalid character in name at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:14:12:
Error: Invalid character in name at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:15:16:
Error: Symbol 'i' at (1) already has basic type of INTEGER
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:16:17:
Error: Symbol 'a' at (1) has no IMPLICIT type
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:18:5:
Error: Expecting END PROGRAM statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:20:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:21:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:23:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:24:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:25:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:26:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:27:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:28:2:
Error: Unclassifiable statement at (1)

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

2018-07-02 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
Bug 82173 depends on bug 82865, which changed state.

Bug 82865 Summary: Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug middle-end/85504] Bogus -Wrestrict warning with -fsanitize=undefined

2018-07-02 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85504

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bernd Edlinger  ---
.

[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> I get the warning with gcc8 and trunk (9.0), but the output is the expected
> one:
> 
>  **123*

Oh, really? That's interesting. Do you also get the correct output with earlier
gfortran versions?


Strangely, if I use a shorter string, e.g. "character(len=40) :: s", the
segfault disappears, but the output is still only stars. Puzzling.

[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-07-02
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
I get the warning with gcc8 and trunk (9.0), but the output is the expected
one:

 **123*

[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1

2018-07-02 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
looks correct until pr86363.c.032t.ealias:
  _1 = BIT_FIELD_REF ;
  # PT = null { D.1901 }
  _2 = _CONVERT_EXPR(uD.1901)[_1];
  # .MEM_11 = VDEF <.MEM_10(D)>
  # USE = nonlocal null
  # CLB = nonlocal null 
  memsetD.870 (_2, 0, 1);
  # VUSE <.MEM_11>
  _12 = BIT_FIELD_REF ;
  _4 = (unsigned intD.9) _12;
  _5 = (unsigned intD.9) _12;
  _6 = (unsigned intD.9) _12;
  _7 = (unsigned intD.9) _12;
  _3 = {_4, _5, _6, _7};
  # VUSE <.MEM_11>
  g.0_8 = gD.1899;
  _9 = _3 ^ g.0_8; 
  # .MEM_13 = VDEF <.MEM_11>
  gD.1899 = _9;



problem starts in pr86363.c.033t.fre1:
Replaced BIT_FIELD_REF  with 0 in all uses of _12 = BIT_FIELD_REF ;
...
  _1 = BIT_FIELD_REF ;
  # PT = null { D.1901 }
  _2 = _CONVERT_EXPR(uD.1901)[_1];
  # .MEM_11 = VDEF <.MEM_10(D)>
  # USE = nonlocal null
  # CLB = nonlocal null
  memsetD.870 (_2, 0, 1);
  # VUSE <.MEM_11>
  g.0_8 = gD.1899;
  # VUSE <.MEM_11>
  return g.0_8;

[Bug c++/86369] constexpr const char* comparison fails

2018-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369

--- Comment #2 from Jonathan Wakely  ---
Clang trunk also rejects it for the same reason, icc accepts it.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Allocatable-length  |Allocatable-length
   |character var causes bogus  |character var causes bogus
   |warning with -Wall  |warning with
   ||-Wuninitialized

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Related test case:

This is probably a separate problem, since it is also connected to a wrong-code
bug, see PR 86372.

[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from janus at gcc dot gnu.org ---
Test case:


program xxx

   character(len=50) :: s

   s = repeat('*', len(s))
   call sub(s)
   print *, s

contains

   subroutine sub(str)
  character(len=*), intent(inout) :: str
  associate (substr => str(3:5))
 substr = '123'
  end associate
   end subroutine

end


With gfortran version 5 to 7 it compiles ok and prints at runtime:

 **

This is already wrong, since the string should be modified is the subroutine.

With gfortran 8 and trunk there is even a segfault at runtime (on the line
"substr = '123'"), and the warning mentioned in PR 56670 comment 5:

  substr = '123'

Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized]

[Bug fortran/86372] New: [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372

Bug ID: 86372
   Summary: [8/9 Regression] Segfault on ASSOCIATE statement with
CHARACTER variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

[Bug c++/86369] constexpr const char* comparison fails

2018-07-02 Thread blitzrakete at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369

Nicolas Lesser  changed:

   What|Removed |Added

 CC||blitzrakete at gmail dot com

--- Comment #1 from Nicolas Lesser  ---
For clarity, b1 shouldn't compile.

[lex.string]p16 says: "whether successive evaluations of a string-literal yield
the same or a different object is unspecified."

[expr.const]p2 says: "An expression e is a core constant expression unless the
evaluation of e, [...], would evaluate one of the following expressions: [...];
a relational or equality operator where the result is unspecified;"

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wall

2018-07-02 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org ---
Related test case:


subroutine sub(strIn, strOut)

   character(len=10) :: strOut
   character(len=100) :: strIn

   associate (substr => strIn(1:10))

  strout = substr

   end associate

end



Compiling this with "gfortran-8 -Wall" yields:

   strout = substr

Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized]


gfortran-7 and earlier doesn't show this warning.

[Bug lto/86321] [9 Regression] ICE: in splice_child_die, at dwarf2out.c:5693 for several Fortran tests with -g -flto

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86321

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Jul  2 08:00:47 2018
New Revision: 262301

URL: https://gcc.gnu.org/viewcvs?rev=262301=gcc=rev
Log:
2018-07-02  Richard Biener  

PR lto/86321
* trans-types.c (gfc_get_array_type_bounds): Unshare TYPE_FIELDs
for the distinct type copy.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c

[Bug lto/86321] [9 Regression] ICE: in splice_child_die, at dwarf2out.c:5693 for several Fortran tests with -g -flto

2018-07-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86321

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug ipa/86279] [9 Regression] ICE in malloc_candidate_p, at ipa-pure-const.c:927

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86279

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug ipa/86323] [9 regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:85

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86323

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug fortran/45305] Array-valued calles to elementals are not simplified

2018-07-02 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Mon Jul  2 07:24:43 2018
New Revision: 262300

URL: https://gcc.gnu.org/viewcvs?rev=262300=gcc=rev
Log:
2018-07-02  Paul Thomas  

PR fortran/45305
* expr.c : Add a prototype for scalarize_intrinsic_call.
(gfc_simplify_expr): Use scalarize_intrinsic_call for elemental
intrinsic function calls.
(scalarize_intrinsic_call): Add 'init_flag' argument. Check if
the expression or any of the actual argument expressions are
NULL. Before calling gfc_check_init_expr, check 'init_flag'.
Only simplify the scalarized expressions if there are no errors
on the stack.
(gfc_check_init_expr): Set 'init_flag' true in the call to
scalarize_intrinsic_call.

2018-07-02  Paul Thomas  

PR fortran/45305
* gfortran.dg/scalarize_parameter_array_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_50.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/45305] Array-valued calles to elementals are not simplified

2018-07-02 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305

Paul Thomas  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Paul Thomas  ---
Fixed on trunk

Thanks for the report.

Paul

[Bug fortran/45305] Array-valued calles to elementals are not simplified

2018-07-02 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Mon Jul  2 07:20:27 2018
New Revision: 262299

URL: https://gcc.gnu.org/viewcvs?rev=262299=gcc=rev
Log:
2018-07-02  Paul Thomas  

PR fortran/45305
* expr.c : Add a prototype for scalarize_intrinsic_call.
(gfc_simplify_expr): Use scalarize_intrinsic_call for elemental
intrinsic function calls.
(scalarize_intrinsic_call): Add 'init_flag' argument. Check if
the expression or any of the actual argument expressions are
NULL. Before calling gfc_check_init_expr, check 'init_flag'.
Only simplify the scalarized expressions if there are no errors
on the stack.
(gfc_check_init_expr): Set 'init_flag' true in the call to
scalarize_intrinsic_call.

2018-07-02  Paul Thomas  

PR fortran/45305
* gfortran.dg/scalarize_parameter_array_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/86279] [9 Regression] ICE in malloc_candidate_p, at ipa-pure-const.c:927

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86279

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Jul  2 07:04:20 2018
New Revision: 262298

URL: https://gcc.gnu.org/viewcvs?rev=262298=gcc=rev
Log:
Revert 2 ::get to ::get_create for IPA summaries (PR ipa/86279).

2018-07-02  Martin Liska  

PR ipa/86279
* ipa-pure-const.c (malloc_candidate_p): Revert usage of ::get.
(propagate_nothrow): Likewise.
2018-07-02  Martin Liska  

PR ipa/86279
* gcc.dg/ipa/pr86279.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr86279.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/86323] [9 regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:85

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86323

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Jul  2 07:04:01 2018
New Revision: 262297

URL: https://gcc.gnu.org/viewcvs?rev=262297=gcc=rev
Log:
Revert one ipa_call_summaries::get to get_create (PR ipa/86323).

2018-07-02  Martin Liska  

PR ipa/86323
* ipa-inline.c (early_inliner): Revert wrongly added ::get call.
2018-07-02  Martin Liska  

PR ipa/86323
* g++.dg/ipa/pr86323.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr86323.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #11 from Martin Liška  ---
Thanks Martin for nice analysis. Richi can you take a look at that?

[Bug lto/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

2018-07-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-02
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug fortran/77703] [6/7/8/9 Regression] ICE on assignment to pointer function

2018-07-02 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #5 from Jürgen Reuter  ---
This is also still present in the actual trunk.

[Bug hsa/86371] New: building compiler tries to look in $HOME/local/include

2018-07-02 Thread kenta at mit dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86371

Bug ID: 86371
   Summary: building compiler tries to look in $HOME/local/include
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kenta at mit dot edu
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

When building the compiler, the makefile attempts to compile something with "-I
$HOME/local/include".  This is almost certainly a bug (did you want
/usr/local/include ?).  The compiler shouldn't depend on what the
compiler-builder user has in $HOME.  I actually make $HOME unreadable while
building the compiler, so this bug causes the compiler build to fail as it
tries to read a directory to which it does not have permissions.

The bug can be seen with following build commands:
../gcc-8.1.0/configure --enable-language=all
HOME=/THIS_IS_A_BUG_IN_BRIG_XXX make > gcc-make.log 2>&1
grep THIS_IS_A_BUG_IN_BRIG_XXX gcc-make.log