[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

2019-04-16 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|middle-end  |tree-optimization

--- Comment #8 from Jeffrey A. Law  ---
So, if we change phionlycprop to look for other const/copy initializations that
can be eliminated and run a pass between DOM and the erroneous-path isolation
pass, then the false positive is eliminated (as expected).

There's two things I don't like about that.  First, it turns phionlycprop into
a full-fledged constant propagation pass.  phionlycprop is supposed to be so
fast that we never really notice it.  It accomplishes this by only looking at
PHI nodes that are degenerates and any constants exposed by propagating way the
degenerate PHI.  Essentially it's just cleaning up painfully obvious cruft left
by jump threading.

To pick up this case we'd have to scan statements in blocks.  We could restrict
that to blocks where we eliminated  degenerate PHI.  But still.  Ugh.

Second, once phionlycprop is doing more work, I'm less inclined to want to add
another instance of the pass.

Finally, once phionlycprop is doing more work one could legitimately ask if we
should just drop the code and use the lattice copy propagator.

Just for fun I replaced all the phi-only cprop calls with calls into the
lattice propagator (including the one I added between DOM and erroneous-path
optimization).  As expected that fixes the testcase too.  It also happens to
clean up things slightly better at an earlier point in the optimizer pipeline. 
I don't know if it's a good trade-off though.

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

2019-04-16 Thread jbassett271 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368

Justin Bassett  changed:

   What|Removed |Added

 CC||jbassett271 at gmail dot com

--- Comment #7 from Justin Bassett  ---
Currently, the unknown attribute warning means that we get a warning for typos
in a whitelisted set of attributes: the standardized attributes and the
gnu::attributes. If this set of whitelisted attributes could be extended, that
would be the ideal solution, IMO, since the user would also get typo detection
for their additional attributes.

Something like -Wignore-unknown-attribute=likely
-Wignore-unknown-attribute=some_ns::some_attribute .



Jonathan Wakely's suggestion is a decent solution to this problem. However, it
won't detect typos in user attributes, and it won't extend to future
standardized attributes.

Another idea is to warn if the edit-distance from the unknown attribute to a
known attribute is small. So [[noretrun]] has a small edit distance and could
emit a warning with, "Did you mean [[noreturn]]?" And
[[some_future_std_attribute]] would emit no warning because it has a large edit
distance from all known attributes.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #78 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #77)
> (In reply to Iain Sandoe from comment #76)
> > (In reply to Jürgen Reuter from comment #75)
> 
> > > LLVM does not compile, but I
> > > guess this is unrelated to the problem here:
> > > [ 38%] Building CXX object
> > > lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o
> > > In file included from
> > > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > > IPDBSession.h:12,
> > >  from
> > > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > > PDBContext.h:13,
> > >  from
> > > /Users/reuter/local/packages/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.
> > > cpp:9:
> > > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > > PDBSymbol.h:20:37: error: invalid use of incomplete type 'const class
> > > llvm::pdb::PDBSymbolData'
> > >20 |   auto MethodName() const->decltype(RawSymbol->MethodName()) {
> > >   
> > > \
> > >   | ^
> > > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > > PDBSymbolData.h:27:3: note: in expansion of macro 'FORWARD_SYMBOL_METHOD'
> > >27 |   FORWARD_SYMBOL_METHOD(getAccess)
> > >   |   ^
> > 
> > This either a regression (since trunk GCC built LLVM ≈ 2 months ago) or it's
> > a new feature exposing some other bug in LLVM - either way, you are right,
> > it doesn't appear related to the current patch.  I will attempt to see if
> > it's repeatable on Linux,
> 
> Fails the same way on Linux - so, as noted, it's either a regression or an
> improved error detection for some other issue.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124

[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124

Iain Sandoe  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-17
  Known to work||8.3.0
   Host||x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu

--- Comment #1 from Iain Sandoe  ---
(of course, the other explanation is that GCC is now detecting some error that
was previously missed, I haven't been able to spend any time analysing).

[Bug c++/90124] New: [9 Regression] Compilation of llvm PDBContext.cpp fails.

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124

Bug ID: 90124
   Summary: [9 Regression] Compilation of llvm PDBContext.cpp
fails.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46181=edit
unreduced PDBContext.ii

trunk GCC currently fails to build LLVM (7 branch at least ) with the
following:

 /home/iains/gcc-trunk/install/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/cc1plus
-fpreprocessed PDBContext.ii -quiet -dumpbase PDBContext.cpp -mtune=generic
-march=x86-64 -auxbase-strip CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o -
Os -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -Wpedantic -Wno-long-long
-Wno-maybe-uninitialized -Wno-class-memaccess -Wdelete-non-virtual-dtor
-Wno-comment -std
=c++11 -version -fPIC -fvisibility-inlines-hidden -ffunction-sections
-fdata-sections -fno-exceptions -fno-rtti -o PDBContext.s
GNU C++11 (GCC) version 9.0.1 20190416 (experimental) [trunk revision 270376]
(x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.1 20190416 (experimental) [trunk revision
270376], GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++11 (GCC) version 9.0.1 20190416 (experimental) [trunk revision 270376]
(x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.1 20190416 (experimental) [trunk revision
270376], GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4b7aa8ad0f9dc04e51fdc48d2596248f
In file included from
/home/iains/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.cpp:15:
/home/iains/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbolData.h:32:36:
error: invalid use of incomplete type ‘const class llvm::pdb::PDBSymbolData’
   32 |   FORWARD_SYMBOL_METHOD(getAccess)
  |^
/home/iains/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbolData.h:23:7:
note: definition of ‘class llvm::pdb::PDBSymbolData’ is not complete until the
closing brace
   23 | class PDBSymbolData : public PDBSymbol {
  |   ^
/home/iains/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbolData.h:32:36:
error: invalid use of incomplete type ‘const class llvm::pdb::PDBSymbolData’
   32 |   FORWARD_SYMBOL_METHOD(getAccess)

< many more like this>

8.3 works, and AFAIR trunk worked recently (order one or two months).

[Bug testsuite/86153] [8 regression] test case g++.dg/pr83239.C fails starting with r261585

2019-04-16 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153

bin cheng  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #16 from bin cheng  ---
Should this be backported to GCC8?

[Bug translation/90119] Merge translation msgids that only differ in placeholders

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
since this requests modifying the linter, I'm going to say this is more
difficult than just "trivial" and thus leave the importance as "normal"
(likewise with other translation bugs that request modifying the linter)

[Bug target/79869] i18n: document placeholders for translators

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 CC||amylaar at gcc dot gnu.org,
   ||andrew.burgess at embecosm dot 
com
   ||, claziss at gmail dot com,
   ||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Roland Illig from comment #1)
> ping? Two years later, and I still don't know how to translate this string
> into proper German.

cc-ing arc maintainers/reviewers

[Bug translation/90120] inconsistent punctuation in translation messages

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||egallager at gcc dot gnu.org
 Blocks||40883
   Severity|normal  |trivial


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug translation/90121] extra space in error message

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||egallager at gcc dot gnu.org
 Blocks||40883
   Severity|normal  |trivial


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug c/90123] "/usr/include/string.h", line 44: syntax error at token '__dest'

2019-04-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
/usr/include/stdio.h comes from glibc.

cproto is the issue report it to them.  I noticed cproto is no longer
maintained too.

[Bug c/90123] New: "/usr/include/string.h", line 44: syntax error at token '__dest'

2019-04-16 Thread iris.041619 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123

Bug ID: 90123
   Summary: "/usr/include/string.h", line 44: syntax error at
token '__dest'
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iris.041619 at gmail dot com
  Target Milestone: ---

I am compiling a C program on CentOS 6.8 and I see a lot of syntax errors in
gcc include header files at token '__???__', but it can generate the binary
eventually. I am confused what went wrong with my /usr/include/*.h. Here is
part of the log file. The cproto version I am using is 4.6 and I tried gcc
4.4.7 and gcc 5.4. I would really appreciate if you could please shed light on
this. Thank you very much for your help in advance.

/*==*/
cproto -D__extension__=" "  -DCPROTO -S -f 2 -I. -I/home/XXX/include -o test.pl
test.c
"/usr/include/stdarg.h", line 40: syntax error at token '__builtin_va_list'
"/usr/include/libio.h", line 491: syntax error at token '__gnuc_va_list'
"/usr/include/stdio.h", line 197: syntax error at token '__asm__'
"/usr/include/stdio.h", line 282: syntax error at token '__filename'
..
"/usr/include/stdio.h", line 734: syntax error at token '__ptr'
"/usr/include/stdio.h", line 779: syntax error at token '__asm__'
"/usr/include/stdio.h", line 801: syntax error at token '__stream'
"/usr/include/stdio.h", line 803: syntax error at token '__asm__'
"/usr/include/stdlib.h", line 165: syntax error at token '__nptr'
..
"/usr/include/stdlib.h", line 210: syntax error at token '__nptr'
"/usr/include/stdlib.h", line 215: syntax error at token '__nptr'
"/usr/include/sys/select.h", line 109: syntax error at token '__readfds'
"/usr/include/stdlib.h", line 360: syntax error at token '__buf'
"/usr/include/stdlib.h", line 366: syntax error at token '__statebuf'
"/usr/include/stdlib.h", line 371: syntax error at token '__statebuf'
..
"/usr/include/string.h", line 44: syntax error at token '__dest'
"/usr/include/string.h", line 57: syntax error at token '__dest'
..
"/usr/include/fcntl.h", line 209: syntax error at token '__asm__'
"/usr/include/sys/stat.h", line 219: syntax error at token '__file'
"/usr/include/sys/stat.h", line 222: syntax error at token '__asm__'
"/usr/include/sys/stat.h", line 269: syntax error at token '__file'
"/usr/include/sys/stat.h", line 412: syntax error at token '__asm__'
"/usr/include/sys/stat.h", line 415: syntax error at token '__asm__'
"/usr/include/sys/stat.h", line 418: syntax error at token '__asm__'
"/usr/include/sys/stat.h", line 421: syntax error at token '__asm__'
gcc -g -c -m64 -gdwarf-2 -g -D__USE_XOPEN2K8 -std=gnu89 -DTPI_DEBUG -c -I.
-I/home/XXX/include ./test.c
..
/*==*/

[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-04-16 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from John David Anglin  ---
Fixed.

[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-04-16 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #28 from John David Anglin  ---
Author: danglin
Date: Wed Apr 17 00:22:23 2019
New Revision: 270402

URL: https://gcc.gnu.org/viewcvs?rev=270402=gcc=rev
Log:
PR libgfortran/79540
* io/write_float.def (build_float_string): Don't copy digits when
ndigits is negative.


Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/write_float.def

[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-04-16 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #27 from John David Anglin  ---
Author: danglin
Date: Tue Apr 16 23:21:13 2019
New Revision: 270398

URL: https://gcc.gnu.org/viewcvs?rev=270398=gcc=rev
Log:
PR libgfortran/79540
* io/write_float.def (build_float_string): Don't copy digits when
ndigits is negative.


Modified:
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/io/write_float.def

[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3

2019-04-16 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Somewhat trimmed down testcase...  Certainly easier to analyze...

typedef __SIZE_TYPE__ size_t;
typedef unsigned long int uintmax_t;

struct group
{
  char *gr_name;
  char *gr_passwd;
  unsigned gr_gid;
  char **gr_mem;
};

struct passwd
{
  char *pw_name;
  char *pw_passwd;

  unsigned pw_uid;
  unsigned pw_gid;
  char *pw_gecos;
  char *pw_dir;
  char *pw_shell;
};

extern struct group *getgrnam (const char *);
extern struct group *getgrgid (unsigned);
extern void endgrent (void);
extern struct passwd *getpwnam (const char *);
extern void endpwent (void);
extern unsigned long int strtoul (const char *__restrict,
  char **__restrict, int);

char const *
parse_with_separator (char const *spec, char const *separator,
  unsigned *uid, unsigned *gid,
  char **username, char **groupname)
{
  static const char *E_bad_spec = "invalid spec";
  const char *error_msg;
  char *u;
  char const *g;
  struct group *grp;
  unsigned unum = *uid;

  error_msg = 0;

  u = 0;
  if (separator == 0)
u = __builtin_strdup (spec);
  size_t ulen = separator - spec;
  u = __builtin_malloc (ulen + 1);

  g = (separator == 0 || *(separator + 1) == '\0' ? 0 : separator + 1);

  if (u != 0)
{
  _Bool use_login_group = (separator != 0 && g == 0);
  if (use_login_group)
error_msg = E_bad_spec;

  endpwent ();
}

  if (g != 0 && error_msg == 0)
grp = (*g == '+' ? 0 : getgrnam (g));

  if (error_msg == 0)
*uid = unum;

  return 0;
}

[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302

2019-04-16 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

--- Comment #7 from Jeffrey A. Law  ---
Making some progress here.  Working with a reduced testcase we have the
following key blocks as we enter DOM:


;;   basic block 3, loop depth 0
;;pred:   2
  __builtin_strdup (spec_22(D));
  _56 = separator_21(D) - spec_22(D);
  ulen_57 = (size_t) _56;
  _58 = ulen_57 + 1;
  u_60 = __builtin_malloc (_58);
  goto ; [100.00%]
;;succ:   14

;;   basic block 4, loop depth 0
;;pred:   15
  iftmp.0_27 = separator_21(D) + 1;
  goto ; [100.00%]
;;succ:   14

;;   basic block 5, loop depth 0
;;pred:   14
  # error_msg_40 = PHI <0B(14)>
  # iftmp.0_50 = PHI 
  endpwent ();
  _51 = iftmp.0_50 != 0B;
  _52 = error_msg_40 == 0B;
  _53 = _51 & _52;
  if (_53 != 0)
goto ; [49.98%]
  else
goto ; [50.02%]
;;succ:   7
;;10

;;   basic block 6, loop depth 0
;;pred:   13
  # error_msg_11 = PHI <"invalid spec"(13)>
  # iftmp.0_67 = PHI <0B(13)>
  endpwent ();
  _7 = iftmp.0_67 != 0B;
  _8 = error_msg_11 == 0B;
  _9 = _7 & _8;
  if (_9 != 0)
goto ; [49.98%]
  else
goto ; [50.02%]
;;succ:   7
;;9

;;   basic block 7, loop depth 0
;;pred:   6
;;12
;;5
  # iftmp.0_68 = PHI 
  _10 = *iftmp.0_68;
  if (_10 != 43)
goto ; [48.88%]
  else
goto ; [51.12%]
;;succ:   8
;;10

[ ... ]

;;   basic block 12, loop depth 0
;;pred:   14
;;13
  # iftmp.0_69 = PHI 
  _44 = iftmp.0_69 != 0B;
  _45 = 1;
  _46 = _44 & _45;
  if (_46 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
;;succ:   7
;;10


[ ... ]

;;   basic block 14, loop depth 0
;;pred:   3
;;4
  # iftmp.0_54 = PHI <0B(3), iftmp.0_27(4)>
  # u_74 = PHI 
  if (u_74 != 0B)
goto ; [76.89%]
  else
goto ; [23.11%]
;;succ:   5
;;12

We find some jump threading opportunities.  What's most interesting to note is
the thread of control bb3->bb14->bb5->bb7.

This is an infeasible path -- it can't happen at runtime.  But we also can't
simplify it in DOM.  We need jump threading & cleanup_cfg to simplify the CFG. 
After DOM's jump threading pass is complete, the CFG is cleaned up and we've
incrementally updated the SSA form we'll have:

;;   basic block 3, loop depth 0
;;pred:   2
  __builtin_strdup (spec_22(D));
  _41 = (long int) spec_22(D);
  _56 = -_41;
  ulen_57 = (size_t) _56;
  _58 = ulen_57 + 1;
  u_60 = __builtin_malloc (_58);
  if (u_60 != 0B)
goto ; [100.00%]
  else
goto ; [0.00%]
;;succ:   5
;;16

[ First note that the test originally from bb14 has been moved up into bb3 ]

;;   basic block 5, loop depth 0
;;pred:   3
  # error_msg_40 = PHI <0B(3)>
  # iftmp.0_50 = PHI <0B(3)>
  endpwent ();
  _51 = 0;
  _52 = 1;
  _53 = _51;
  if (_51 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]
;;succ:   7
;;9

The combination of threading and cfgcleanup has exposed the constants.   But
DOM is complete at this point and thus we don't get another change to optimize
the block.

And bb7 will look like:

;;   basic block 7, loop depth 0
;;pred:   15
;;11
;;5
  # iftmp.0_68 = PHI 
  _10 = *iftmp.0_68;
  if (_10 != 43)
goto ; [48.88%]
  else
goto ; [51.12%]
;;succ:   8
;;9

Notice how the value 0 flows in from bb5 for iftmp.0_68 which we then
dereference.  It's still an infeasible path, but without another DOM pass,
predicate analysis or something similar, we're going to issue the false
positive.

So we already know that iterated DOM/jump threading is too expensive.  We could
move the path isolation bits later -- like after dom3 which would fix this
regression, but probably introduce others.

Ultimately it's the usual phase ordering problem.

As I've noted in other BZs, I've never come up with an algorithm that would
allow us to do some kind of worklist approach to replicate iterated
dom+threading.


But I have speculated that we could get most of the benefit by identifying a
subset of blocks and running a local (block only) simplifier.  On my whiteboard
one of the filters to identify the subset of blocks would be blocks with
degenerate PHIs.  bb5 in this case would qualify and we'd see that bb5's
conditional is always false and thus the edge bb5->bb7 can be deleted which
would in turn eliminate the false positive.

One of the questions that came up for me was whether or not phi-only cprop
would help here.  It doesn't.  It only looks at degenerate PHIs to build its
worklist of SSA_NAMEs to try and propagate away.  Look at bb5.  While there are
degenerate PHIs, they do not feed anything useful.  We'd actually have to run a
more thorough constant propagation.  Something to ponder.

Anyway, wanted to get my thoughts recorded so I don't forget anything.

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105

--- Comment #3 from Jonathan Wakely  ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00669.html

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

--- Comment #13 from Martin Sebor  ---
As noted in the duplicate pr90122, the test case below shows that GCC already
relies on different extern declarations denoting distinct objects.  It just
doesn't fold the address equality expression for some reason.

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-fno-common x.c
extern int a, b;

void foo ();
void bar ();

void f (void)
{
  if ( == )   // not folded
foo ();

  int i = a;
  b = 0;
  if (i != a) // folded to false
bar ();
}

;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=2)

Removing basic block 5
f ()
{
   [local count: 1073741824]:
  if ( == )
goto ; [17.43%]
  else
goto ; [82.57%]

   [local count: 187153200]:
  foo ();

   [local count: 1073741824]:
  b = 0;
  return;

}

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

--- Comment #12 from Martin Sebor  ---
*** Bug 90122 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/90122] inequality of addresses of distinct objects not folded

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
Thanks for the pointer!  I forgot about that ancient bug.  It looks like an
exact duplicate of pr43565.

A and b's addresses must be different because they are distinct declarations of
different objects.  There's no way (in standard C) to make them refer to the
same object.  That GCC itself relies on different declarations denoting
distinct objects is evident from the second if being eliminated.

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

[Bug tree-optimization/90122] inequality of addresses of distinct objects not folded

2019-04-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122

--- Comment #1 from H.J. Lu  ---
(In reply to Martin Sebor from comment #0)
> In the test case below GCC folds the second test (as expected, on the
> assumption that distinct declarations refer to distinct objects) but fails
> to fold the first.
> 
> Clang folds both (into false and true, respectively).  GCC will only do that
> if a and b are static or local.
> 
> Same with extern arrays of known size.
> 
> $ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
> -fno-common x.c
> extern int a, b;

Why can't a and b point to the same address?

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

2019-04-16 Thread pthaugen at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369

Pat Haugen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Pat Haugen  ---
Fixed.

[Bug tree-optimization/90122] New: inequality of addresses of distinct objects not folded

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122

Bug ID: 90122
   Summary: inequality of addresses of distinct objects not folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below GCC folds the second test (as expected, on the
assumption that distinct declarations refer to distinct objects) but fails to
fold the first.

Clang folds both (into false and true, respectively).  GCC will only do that if
a and b are static or local.

Same with extern arrays of known size.

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-fno-common x.c
extern int a, b;

void foo ();
void bar ();

void f (void)
{
  if ( == )
foo ();

  int i = a;
  b = 0;
  if (i != a)
bar ();
}

;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=2)

Removing basic block 5
f ()
{
   [local count: 1073741824]:
  if ( == )
goto ; [17.43%]
  else
goto ; [82.57%]

   [local count: 187153200]:
  foo ();

   [local count: 1073741824]:
  b = 0;
  return;

}

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-16 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

--- Comment #53 from Jeffrey A. Law  ---
Realistically the register allocation issues are not going to get addressed
this cycle nor are improvements to the overall handling of RMW insns in
combine.  So we're going to be stuck with bandaids.

I've got an updated backend pattern that should address the remainder of the
insv_1 and insv_2 regressions and Steve has a backend pattern to address the
other regression in this BZ.

[Bug translation/90121] extra space in error message

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121

--- Comment #1 from Roland Illig  ---
Same for:

error ("unknown CRIS cpu version specification in %<-mtune=%> : %s",
   cris_tune_str);

[Bug translation/90121] New: extra space in error message

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121

Bug ID: 90121
   Summary: extra space in error message
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From cris.c:

error ("unknown CRIS version specification in %<-march=%> or "
   "%<-mcpu=%> : %s", cris_cpu_str);

The space before the colon is too much.

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

2019-04-16 Thread stoyanovmk at ornl dot gov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105

--- Comment #2 from stoyanovmk at ornl dot gov ---
Tested the fix provided by Jonathan Wakely, I can confirm the fix.

Ran several tests with the included small example and the code where I found
the issue in the first place.(In reply to Jonathan Wakely from comment #1)
> I think this is the fix:
> 
> --- a/libstdc++-v3/include/bits/forward_list.tcc
> +++ b/libstdc++-v3/include/bits/forward_list.tcc
> @@ -469,9 +469,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> __p = static_cast<_Node*>(__p->_M_next);
> --__psize;
>   }
> -   else if (__comp(*__p->_M_valptr(), *__q->_M_valptr()))
> +   else if (!__comp(*__q->_M_valptr(), *__p->_M_valptr()))
>   {
> -   // First node of p is lower; e must come from p.
> +   // First node of q is not lower; e must come from p.
> __e = __p;
> __p = static_cast<_Node*>(__p->_M_next);
> --__psize;

Tested the fix, I can confirm it works.

Ran several tests with the included small example and the code where I found
the issue in the first place.

[Bug translation/90119] Merge translation msgids that only differ in placeholders

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119

--- Comment #1 from Roland Illig  ---
Next example from avr.c:

%<-fpic%> is not supported
%<-fPIC%> is not supported
%<-fpie%> is not supported
%<-fPIE%> is not supported

[Bug translation/90120] New: inconsistent punctuation in translation messages

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120

Bug ID: 90120
   Summary: inconsistent punctuation in translation messages
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From arc.c:

  error ("Option %s=%s is not available for %s CPU.",   \
 DOC0, DOC1, arc_selected_cpu->name);   \

  warning (0, "Option %s is ignored, the default value %s"  \
   " is considered for %s CPU.", DOC0, DOC1,\
   arc_selected_cpu->name); \

  error ("Option %s is not available for %s CPU",   \
 DOC, arc_selected_cpu->name);  \

  warning (0, "Unset option %s is ignored, it is always"\
   " enabled for %s CPU.", DOC, \

The second error does not end in a period. All these diagnostics should use
consistent grammar since they all are full sentences.

[Bug target/79869] i18n: document placeholders for translators

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869

--- Comment #1 from Roland Illig  ---
ping? Two years later, and I still don't know how to translate this string into
proper German.

[Bug c++/86953] [7/8 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

2019-04-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 16 19:06:41 2019
New Revision: 270396

URL: https://gcc.gnu.org/viewcvs?rev=270396=gcc=rev
Log:
PR c++/86953
* g++.dg/cpp0x/constexpr-86953.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-86953.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug translation/90119] New: Merge translation msgids that only differ in placeholders

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119

Bug ID: 90119
   Summary: Merge translation msgids that only differ in
placeholders
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

There are the following msgids:

bad value %qs for %<-mtrap-precision%> switch
bad value %qs for %<-mfp-rounding-mode%> switch
bad value %qs for %<-mfp-trap-mode%> switch
bad value %qs for %<-mcpu%> switch

These are boring to translate and increase the likelyhood of copy-and-paste
translation errors. It would be better if there were only a single msgid to be
translated:

bad value %qs for %qs switch

This means less work for the translators, and less chances of introducing
translation errors.

The translation linter should find msgids that only differ in plain text
enclosed by %< and %>. The following msgid should not be merged since it is
more complicated to fix:

bad value %qs for %<-mcpu=%s%> switch

That is, only msgids that are the same after s,%<[^%]+%>,%<%>,g should be
suggestted to be merged. There might be other special characters that I forgot.

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105

--- Comment #1 from Jonathan Wakely  ---
I think this is the fix:

--- a/libstdc++-v3/include/bits/forward_list.tcc
+++ b/libstdc++-v3/include/bits/forward_list.tcc
@@ -469,9 +469,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
__p = static_cast<_Node*>(__p->_M_next);
--__psize;
  }
-   else if (__comp(*__p->_M_valptr(), *__q->_M_valptr()))
+   else if (!__comp(*__q->_M_valptr(), *__p->_M_valptr()))
  {
-   // First node of p is lower; e must come from p.
+   // First node of q is not lower; e must come from p.
__e = __p;
__p = static_cast<_Node*>(__p->_M_next);
--__psize;

[Bug translation/90118] New: Missing space between words

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118

Bug ID: 90118
   Summary: Missing space between words
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

  error ("incompatible options %<-mstack-protector-guard=global%> and"
 "%<-mstack-protector-guard-offset=%s%>",
 aarch64_stack_protector_guard_offset_str);

There should be a space between "and" and the opening "%<".

The linter should be extended to flag all places where %< appears without a
leading space. This rule could prevent further bugs like this. The rule might
need some adjustments, of course, which the first test run will show.

[Bug translation/90117] New: Replace %<%s%> with %qs

2019-04-16 Thread roland.illig at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117

Bug ID: 90117
   Summary: Replace %<%s%> with %qs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

In most cases %<%s%> is equivalent to the simpler %qs, therefore the latter
should be used consistently.

Surprisingly there is one exception in error.c, which is already well
documented:

  /* We have to use "%<%s%>" rather than "%qs" here in order to avoid
 quoting colorization bytes within the results.  */
  pp_printf (_pp, "%<%s%>", content);

The 17 other occurrences of %<%s%> look like the respective author just didn't
know about %qs. These should be changed to the simpler %qs.

A linter check should be added so that future code doesn't introduce the same
inconsistency. I had already reported some similar issues in 2017, and I don't
want to do that again in 2020.

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

--- Comment #15 from Marek Polacek  ---
(In reply to Marek Polacek from comment #14)
> The problem is that here
> 24072   /* Instantiate a dynamic exception-specification.  noexcept will
> be
> 24073  handled below.  */
> 24074   if (tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE
> (code_pattern)))
> 24075 if (TREE_VALUE (raises))
> 24076   {
> 24077 specs = tsubst_exception_specification (TREE_TYPE
> (code_pattern),
> 24078 args, tf_error,
> NULL_TREE,
> 24079 /*defer_ok*/false);
> 
> raises is NOEXCEPT_EXPR<{}>, but its TREE_VALUE is null, so we don't
> substitute.

...which is fine, we should have handled this in maybe_instantiate_noexcept, it
seems.

[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64

2019-04-16 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109

--- Comment #2 from Jim Wilson  ---
long long and long double did not exist when stabs was invented.  Also, 64-bit
machines and C++ did not exist at the time.  Also, unfortunately, stabs wasn't
designed to be extensible.  So there is no way to describe anything that
doesn't exist in K C without using incompatible extensions, such as those
enabled by the the gdb stabs extensions.

So yes, invalid, though I'd add an extra caution that stabs should only be used
if you need compatibility with old obsolete systems.  Otherwise, it is a waste
of time, as we stopped actively maintaining it about a decade ago, and probably
should just drop the support from gcc.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #77 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #76)
> (In reply to Jürgen Reuter from comment #75)

> > LLVM does not compile, but I
> > guess this is unrelated to the problem here:
> > [ 38%] Building CXX object
> > lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o
> > In file included from
> > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > IPDBSession.h:12,
> >  from
> > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > PDBContext.h:13,
> >  from
> > /Users/reuter/local/packages/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.
> > cpp:9:
> > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > PDBSymbol.h:20:37: error: invalid use of incomplete type 'const class
> > llvm::pdb::PDBSymbolData'
> >20 |   auto MethodName() const->decltype(RawSymbol->MethodName()) {  
> > \
> >   | ^
> > /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> > PDBSymbolData.h:27:3: note: in expansion of macro 'FORWARD_SYMBOL_METHOD'
> >27 |   FORWARD_SYMBOL_METHOD(getAccess)
> >   |   ^
> 
> This either a regression (since trunk GCC built LLVM ≈ 2 months ago) or it's
> a new feature exposing some other bug in LLVM - either way, you are right,
> it doesn't appear related to the current patch.  I will attempt to see if
> it's repeatable on Linux,

Fails the same way on Linux - so, as noted, it's either a regression or an
improved error detection for some other issue.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #76 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #75)
> (In reply to Iain Sandoe from comment #74)
> 
> > Thanks, does that include a test suite run and/or building something
> > substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted,
> > very limited access to Darwin test resources.
> 
> Well, our own code compiles and tests correctly, but that is Fortran2018
> with some C++ interfaces to external libraries.

Good

> LLVM does not compile, but I
> guess this is unrelated to the problem here:
> [ 38%] Building CXX object
> lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o
> In file included from
> /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> IPDBSession.h:12,
>  from
> /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> PDBContext.h:13,
>  from
> /Users/reuter/local/packages/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.
> cpp:9:
> /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> PDBSymbol.h:20:37: error: invalid use of incomplete type 'const class
> llvm::pdb::PDBSymbolData'
>20 |   auto MethodName() const->decltype(RawSymbol->MethodName()) {  
> \
>   | ^
> /Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/
> PDBSymbolData.h:27:3: note: in expansion of macro 'FORWARD_SYMBOL_METHOD'
>27 |   FORWARD_SYMBOL_METHOD(getAccess)
>   |   ^

This either a regression (since trunk GCC built LLVM ≈ 2 months ago) or it's a
new feature exposing some other bug in LLVM - either way, you are right, it
doesn't appear related to the current patch.  I will attempt to see if it's
repeatable on Linux,

[Bug go/90116] Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)

2019-04-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
I can recreate the compiler crash with GCC 8 branch, but it is fixed on trunk. 
On trunk I get

foo.go:3:7: error: array bound is not constant
3 | var A[A] A
  |   ^
foo.go:3:7: error: expected type

Your second case is not a bug.  The Go language specification expresses
constraints in the text that are not expressed in the formal grammar.  In the
discussion of constant declaration, the spec says "Within a parenthesized const
declaration list the expression list may be omitted from any but the first
ConstSpec."  In your example the expression list is omitted from the first
ConstSpec, so the compiler is correct in reporting a parse error.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

2019-04-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871

--- Comment #29 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #27)
> > Note: I'm assuming we're missing a \n after p116's empty conflicts above?
> 
> The code is

Right.  I already whipped up a patch that gives me:

;; a5(r116,l0) conflicts:
;; total conflict hard regs:
;; conflict hard regs:


  cp0:a0(r111)<->a4(r117)@330:move
  ...

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #75 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #74)

> Thanks, does that include a test suite run and/or building something
> substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted,
> very limited access to Darwin test resources.

Well, our own code compiles and tests correctly, but that is Fortran2018 with
some C++ interfaces to external libraries. LLVM does not compile, but I guess
this is unrelated to the problem here:
[ 38%] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/PDBContext.cpp.o
In file included from
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/IPDBSession.h:12,
 from
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBContext.h:13,
 from
/Users/reuter/local/packages/llvm-project/llvm/lib/DebugInfo/PDB/PDBContext.cpp:9:
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbol.h:20:37:
error: invalid use of incomplete type 'const class llvm::pdb::PDBSymbolData'
   20 |   auto MethodName() const->decltype(RawSymbol->MethodName()) { 
   \
  | ^
/Users/reuter/local/packages/llvm-project/llvm/include/llvm/DebugInfo/PDB/PDBSymbolData.h:27:3:
note: in expansion of macro 'FORWARD_SYMBOL_METHOD'
   27 |   FORWARD_SYMBOL_METHOD(getAccess)
  |   ^

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

2019-04-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871

--- Comment #28 from Peter Bergner  ---
Vlad, in looking at add_insn_allocno_copies(), it looks like it relies on
seeing REG_DEAD notes on whether to record a copy/shuffle that should be
handled.  Shouldn't we instead be looking at whether the source and destination
regs conflict or not?  Ie, there might not be a REG_DEAD note, but that doesn't
mean the two regs/pseudos conflict.  And conversely, if there is a REG_DEAD
note on the copy/shuffle, the two regs/pseudos still could conflict.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

2019-04-16 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871

--- Comment #27 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #26)
> ;; a4(r117,l0) conflicts: a3(r112,l0)
> ;; total conflict hard regs:
> ;; conflict hard regs:
> 
> ;; a5(r116,l0) conflicts:  cp0:a0(r111)<->a4(r117)@330:move
>   cp1:a2(r114)<->a3(r112)@41:shuffle
>   cp2:a3(r112)<->a5(r116)@125:shuffle
>   pref0:a0(r111)<-hr0@2000
>   pref1:a4(r117)<-hr0@660
>   pref2:a5(r116)<-hr0@1000
>   regions=1, blocks=6, points=10
> allocnos=6 (big 0), copies=3, conflicts=0, ranges=6
> 
> Note: I'm assuming we're missing a \n after p116's empty conflicts above?

The code is

  fputs (" conflicts:", file);
  n = ALLOCNO_NUM_OBJECTS (a);
  for (i = 0; i < n; i++)
{
  ira_object_t obj = ALLOCNO_OBJECT (a, i);
  ira_object_t conflict_obj;
  ira_object_conflict_iterator oci;

  if (OBJECT_CONFLICT_ARRAY (obj) == NULL)
continue;
  [...]
}

and the

;; total conflict hard regs:

etc. prints are in that [...].

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-16
 Ever confirmed|0   |1

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

2019-04-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093

--- Comment #50 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #49)
> (In reply to Bernd Edlinger from comment #48)
> > (In reply to Florian Weimer from comment #47)
> > > (In reply to Bernd Edlinger from comment #43)
> > > > does anybody know what is the Ada and/or D syntax for that?
> > > 
> > > Syntax for what?
> > 
> > I mean the Ada and D equivalent of
> > #pragma GCC target ("general-regs-only")
> > and/or
> > __attribute__((target("general-regs-only")))
> 
> I don't think the target pragma/attribute is supported in Ada.
> 
>pragma Machine_Attribute (Subprogram, "target", "general-regs-only");
> 
> appears to be ignored (even if I use a string which would be accepted by the
> C/C++ pragma for that target, and not "general-regs-only".  But it's been
> years since I did much Ada programming.

I don't understand why we are discussing Ada, because gcc/ada/raise_gcc.c, the
TU containing the Ada personality routine, is written in C.
The only problem is the D personality routine, which is written in D.  And in
that case IMHO we can just use -mgeneral-regs-only on the command line for arm
in the Makefiles or something similar.

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

2019-04-16 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369

--- Comment #5 from pthaugen at gcc dot gnu.org ---
Author: pthaugen
Date: Tue Apr 16 15:58:02 2019
New Revision: 270394

URL: https://gcc.gnu.org/viewcvs?rev=270394=gcc=rev
Log:
PR target/84369
* config/rs6000/power9.md: Add store forwarding bypass.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/power9.md

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

--- Comment #14 from Marek Polacek  ---
The problem is that here
24072   /* Instantiate a dynamic exception-specification.  noexcept will be
24073  handled below.  */
24074   if (tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE
(code_pattern)))
24075 if (TREE_VALUE (raises))
24076   {
24077 specs = tsubst_exception_specification (TREE_TYPE
(code_pattern),
24078 args, tf_error,
NULL_TREE,
24079 /*defer_ok*/false);

raises is NOEXCEPT_EXPR<{}>, but its TREE_VALUE is null, so we don't
substitute.

[Bug go/90116] Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)

2019-04-16 Thread 22374604 at sun dot ac.za
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116

--- Comment #1 from Moeketsi Raselimo <22374604 at sun dot ac.za> ---
Created attachment 46180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46180=edit
gccgo-8.2 throws syntax error on this one

[Bug go/90116] New: Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)

2019-04-16 Thread 22374604 at sun dot ac.za
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116

Bug ID: 90116
   Summary: Segmentation fault and what appears to be an
implementation error in gofrontend (parse.cc)
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: 22374604 at sun dot ac.za
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 46179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46179=edit
Program that causes segmentation fault

My research entails systematic generation of test cases from grammars. We
picked the golang from the antlr v4 grammar repository, avilable at
https://github.com/antlr/grammars-v4,which is a translation from the golang
language specification available at https://golang.org/ref/spec . Here I
present two issues I uncovered.

1. The following generated programs causes internalcompiler error:

package A; var A[A] A;

Compilation of the above program:
gccgo-8.2 -c -Wall -Wextra
/home/max/experiments/go/pos/pair/4730a8a0-603a-11e9-b473-8f102747f394.go

output:
gccgo-8.2: internal compiler error: Segmentation fault signal terminated
program go1

2. Implementation error of the parser in gcc/go/gofrontend/parse.cc

ggc-go  also throws a syntax error on one of the generated programs below:

package A; const(B; C;);

Antlr v4 consumes the program correctly without throwing out any parse errors
and gccgo-8.2 compalins that '=' is expected.

One rule is of interest 
ConstSpec = IdentifierList [ [ CompleteType ] "=" ExpressionList ] .

The above rule is from golang language specification and also included
commented in file parse.cc at line 1440 the method that implements the rule
follows at 1442. And it shows that '=' is optional. The go compiler implements
the hand written recursive descent parser. I came to think that the parser in
the gccgo does not implement the grammar (language spec) .

Rules involving that program to show its syntax is valid:
ConstDecl  = "const" ( ConstSpec | "(" { ConstSpec ";" } ")" ) .
ConstSpec = IdentifierList [ [ CompleteType ] "=" ExpressionList ] .
IdentifierList = identifier { "," identifier } .

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

2019-04-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871

--- Comment #26 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #25)
> (In reply to Peter Bergner from comment #24)
>> I don't know why r0 isn't in profitable_regs for pseudo 116.
>  
> Profitable regs there contain also conflict regs.  R0 is conflicting with
> p106. If R0 usage (in call insn) were in the same BB, your new conflict
> calculation found that there is no actual conflict.  But IRA uses
> df-infrastructure which tells IRA that R0 lives at the BB end where p106
> occurs.

I'm sorry, but I don't see where p116 conflicts with r0.  Can you show me
where/how?  Looking at my IRA dump, I see:


+++Allocating 40 bytes for conflict table (uncompressed size 48)
;; a0(r111,l0) conflicts: a2(r114,l0) a1(r113,l0) a3(r112,l0)
;; total conflict hard regs:
;; conflict hard regs:

;; a1(r113,l0) conflicts: a0(r111,l0) a2(r114,l0) a3(r112,l0)
;; total conflict hard regs:
;; conflict hard regs:

;; a2(r114,l0) conflicts: a0(r111,l0) a1(r113,l0)
;; total conflict hard regs:
;; conflict hard regs:

;; a3(r112,l0) conflicts: a0(r111,l0) a1(r113,l0) a4(r117,l0)
;; total conflict hard regs: 0 12 14
;; conflict hard regs: 0 12 14

;; a4(r117,l0) conflicts: a3(r112,l0)
;; total conflict hard regs:
;; conflict hard regs:

;; a5(r116,l0) conflicts:  cp0:a0(r111)<->a4(r117)@330:move
  cp1:a2(r114)<->a3(r112)@41:shuffle
  cp2:a3(r112)<->a5(r116)@125:shuffle
  pref0:a0(r111)<-hr0@2000
  pref1:a4(r117)<-hr0@660
  pref2:a5(r116)<-hr0@1000
  regions=1, blocks=6, points=10
allocnos=6 (big 0), copies=3, conflicts=0, ranges=6

Note: I'm assuming we're missing a \n after p116's empty conflicts above?

So I don't see p116 conflict with r0, but I do see we register a shuffle
between p112 and p116 and p112 does (correctly) conflict with r0.  Is it really
the shuffle between p112 and p116 that is preventing us from putting r0 into
p116's profitable regs in the hope the p112 and p116 may get assigned the same
reg allowing the removal of the copy?  If so, that shuffle, since it's attached
to the setting of the CC reg cannot actually be removed even if p112 and p116
are assigned the same register.  Should we just ignore those types of
shuffles/copies that have other side effects?

[Bug target/88809] do not use rep-scasb for inline strlen/memchr

2019-04-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809

Martin Liška  changed:

   What|Removed |Added

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

[Bug target/88809] do not use rep-scasb for inline strlen/memchr

2019-04-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-16
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
I would like working on this problem. I've read the Peters very detail analysis
on Stack overflow and I have first couple of questions and observations I've
did:

1) I would suggest to remove usage of 'rep scasb' at all; even for -Os the
price paid is quite huge
2) I've made strlen instrumentation for -fprofile-{generate,use} and collected
SPEC2016 statistics for train runs:

Benchmark  strlen calls executed strlen calls total
executions   avg. strlen
400.perlbench102   39   2358804
10.97
401.bzip2  00 0 
403.gcc  144   21  4081
  9.3
410.bwaves 00 0 
416.gamess 00 0 
429.mcf00 0 
433.milc   30 0 
434.zeusmp 00 0 
435.gromacs   86792
12.46
436.cactusADM110   46 61788
10.61
437.leslie3d   00 0 
444.namd   00 0 
445.gobmk 417 75196
 2.01
447.dealII 30 0 
450.soplex 86   1161517
25.59
453.povray67   25 54584
33.25
454.calculix  540 0 
456.hmmer 93   1052
 15.1
458.sjeng  00 0 
459.GemsFDTD   00 0 
462.libquantum 00 0 
464.h264ref   121 1
  14274.0
465.tonto  00 0 
470.lbm00 0 
471.omnetpp   50   15  24291732
 9.79
473.astar  00 0 
481.wrf   42   15 20490
 9.41
482.sphinx3   23   11402963
 1.61
483.xalancbmk 273   160
13.04

Columns: Benchmark name, # of strlen calls in the benchmarks, # of strlen calls
that were called
during train run, total number of strlen execution, average strlen

Note: 14274.0 value for 464.h264ref is correct:

  content_76 = GetConfigFileContent (filename_53);
  _7 = strlen (content_76);

Based on the numbers an average string for which a strlen is called is quite
short (<32B).

3) The assumption that most strlen arguments have a known 16B alignment is
quite optimistic.
As mentioned, {c,}alloc returns a memory aligned to that, but strlen is most
commonly called
for a generic character pointer for which we can't prove the alignment.

4) Peter's suggested ASM expansion assumes such alignment. I expect a bit more
complex
code for a general alignment situation?

5) strlen call has the advantage then even though being compiled with -O2
-march=x86-64 (a distribution options),
the glibc can use ifunc to dispatch to an optimized implementation

6) The decision code in ix86_expand_strlen looks strange to me:

bool
ix86_expand_strlen (rtx out, rtx src, rtx eoschar, rtx align)
{
  rtx addr, scratch1, scratch2, scratch3, scratch4;

  /* The generic case of strlen expander is long.  Avoid it's
 expanding unless TARGET_INLINE_ALL_STRINGOPS.  */

  if (TARGET_UNROLL_STRLEN && eoschar == const0_rtx && optimize > 1
  && !TARGET_INLINE_ALL_STRINGOPS
  && !optimize_insn_for_size_p ()
  && (!CONST_INT_P (align) || INTVAL (align) < 4))
return false;

That explains why we generate 'rep scasb' for -O1.

My 

[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Tony E Lewis from comment #4)
> Are these arguments unpersuasive?

IMHO yes.

Comparison that only work with non-const objects are just bad comparison
functions. They are unusable with maps and sets, because in a const-qualified
member function they might be passed const arguments. They risk modifying their
arguments, which leads to undefined behaviour. In your specific example, taking
the arguments by reference might be less efficient than taking ints by value,
so pessimizes the code.

Requiring comparison objects to be usable as-const and with-const (i.e. when
the comparison function object itself is const, and when the arguments are
const) leads to fewer surprises, and is not especially difficult.

The C++ working draft has been changed to make this program undefined, and I'm
not inclined to make it Just Work.

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102

--- Comment #5 from Jonathan Wakely  ---
I'll come back to this for GCC 10.

Slightly better (and not broken) patch:

--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -220,11 +220,11 @@ namespace __debug
   ~vector() = default;
 #endif

+#if __cplusplus < 201103L
   /// Construction from a normal-mode vector
   vector(const _Base& __x)
   : _Base(__x) { }

-#if __cplusplus < 201103L
   vector&
   operator=(const vector& __x)
   {
@@ -234,6 +234,12 @@ namespace __debug
return *this;
   }
 #else
+  /// Construction from a normal-mode vector
+  template, _Base>>>
+   vector(const _Up& __x)
+   : _Base(std::forward<_Base>(__x)) { }
+
   vector&
   operator=(const vector&) = default;

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #4 from Jonathan Wakely  ---
Possible fix:

--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -220,11 +220,11 @@ namespace __debug
   ~vector() = default;
 #endif

+#if __cplusplus < 201103L
   /// Construction from a normal-mode vector
   vector(const _Base& __x)
   : _Base(__x) { }

-#if __cplusplus < 201103L
   vector&
   operator=(const vector& __x)
   {
@@ -234,6 +234,11 @@ namespace __debug
return *this;
   }
 #else
+  /// Construction from a normal-mode vector
+  template>>
+vector(const _Up& __x)
+: _Base(__x) { }
+
   vector&
   operator=(const vector&) = default;


We'd want to do the same for all the other debug mode containers too.

[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-10-25 00:00:00 |2019-4-16
  Known to fail|9.0 |

--- Comment #6 from Jonathan Wakely  ---
Another reproducer from PR 90080:

struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
template T&& declval();

template
struct is_static_castable : false_type
{};

template
struct is_static_castable(declval()))> :
true_type
{};

template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return static_cast(from);
}

template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return dynamic_cast(from);
}

struct BarBase{ virtual ~BarBase() = default;};
struct Bar : virtual BarBase{};

Bar* foo(BarBase* b){
return safePtrCast(b);
}


90080.cc: In instantiation of ‘struct is_static_castable’:
90080.cc:21:57:   required by substitution of ‘template::value), int>::type
 > To* safePtrCast(From*) [with To = Bar; From = BarBase; typename
enable_if<(! is_static_castable::value), int>::type  =
]’
90080.cc:31:30:   required from here
90080.cc:12:42: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
   12 | struct is_static_castable(declval()))>
: true_type
  |  ^~~~
90080.cc:12:42: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
90080.cc: In instantiation of ‘To* safePtrCast(From*) [with To = Bar; From =
BarBase; typename enable_if::value, int>::type
 = 0]’:
90080.cc:31:30:   required from here
90080.cc:18:12: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
   18 | return static_cast(from);
  |^~

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

--- Comment #13 from Marek Polacek  ---
Adjusted testcase that is compiled with GCC 8.3 without errors:

namespace a {
template  struct d { static constexpr int f = c; };
template  struct g;
template  h i(int);
template  auto ab() -> decltype(i(0));
} // namespace a
namespace aa {
template  using ae = a::d;
struct af {
  template  using ag = ac;
};
template  using ah = af;
template  using aj = typename ah::template ag;
} // namespace aa
namespace a {
template  class ak {
public:
  ak(b);
};
} // namespace a
namespace al {
template  struct am;
template  using an = am;
template  struct v { template  using ap = ao; };
template 
using aq = typename v::template ap;
struct as {
  template  void at();
};

bool e();
namespace ar {
template  concept bool au = requires { as::at; };
template  concept bool j = requires { e(); };
template  struct k;
template  struct k : aa::ae> {};
template  struct l : k> {};
template  struct m { using aw = aq::f, const
int, av>; };
template  using n = m>;
} // namespace ar
template  struct am : ar::n {
  using ax = ar::n;
  using typename ax::aw;
  auto operator*() -> aw;
  auto operator++() -> am;
};
template  auto operator!=(av, ay) -> bool;
template  concept bool az = a::g::f;
struct {
  template  struct o {};
  template  using bb = o>;
  template  auto operator()(ba) noexcept(noexcept(bb{})) {}
} end;
template  using p = decltype(a::ab);
template  concept bool w = requires(ac q) { end(q); };
template  concept bool r = w;
template  concept bool bc = r;
struct x {
  template 
  friend auto operator|(bd, be) -> decltype(be ::bf(a::ab, a::ab()));
};
namespace bg {
template  struct y : x {
  bh s;
  template  static auto bf(u z, bi bj) {
return bj.s(z);
  }
};
} // namespace bg
struct bk {
  template  auto begin() -> an>>;
  int end();
};
namespace bg {
struct bm {
  template  auto operator()(u) -> bk requires bc;
};
y bn;
} // namespace bg
} // namespace al
void b() {
  a::ak t{4};
  for (auto e : t | al::bg::bn)
;
}

[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alex at grundis dot de

--- Comment #5 from Jonathan Wakely  ---
*** Bug 90080 has been marked as a duplicate of this bug. ***

[Bug c++/90080] [8 Regression] SFINAE failure with static_cast

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Reduced:

struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
template T&& declval();

template
struct is_static_castable : false_type
{};

template
struct is_static_castable(declval()))> :
true_type
{};

template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return static_cast(from);
}

template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return dynamic_cast(from);
}

struct BarBase{ virtual ~BarBase() = default;};
struct Bar : virtual BarBase{};

Bar* foo(BarBase* b){
return safePtrCast(b);
}

This started to fail with r258824:

PR c++/78489 - wrong SFINAE behavior.

PR c++/84489
* pt.c (type_unification_real): Don't defer substitution failure.

And was fixed on trunk by r269921:

PR c++/87748 - substitution failure error with decltype.

This issue is similar to PR 87480; in both cases we were doing
non-dependent
substitution with processing_template_decl set, leading to member access
expressions seeming still instantiation-dependent, and therefore decltype
not being simplified to its actual type.  And as in that PR, the fix is to
clear processing_template_decl while substituting a default template
argument.

* pt.c (most_specialized_partial_spec): Clear
processing_template_decl.

So this looks like a dup of that PR, which is still present on gcc-8-branch.

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

[Bug c++/90080] [8 Regression] SFINAE failure with static_cast

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-16
  Known to work||4.7.1, 7.4.0, 9.0
Summary|SFINAE failure with |[8 Regression] SFINAE
   |static_cast |failure with static_cast
 Ever confirmed|0   |1
  Known to fail||8.1.0, 8.2.0, 8.3.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to Alex from comment #0)
> This looks like a regression as a similar error is described here
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44267

Agreed. It works with GCC 7 and with trunk, but not GCC 8.

[Bug c++/65799] Allows constexpr conversion from cv void * to other type

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Eric, could you open a new PR and CC Martin please?

[Bug c++/55004] [meta-bug] constexpr issues

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 65799, which changed state.

Bug 65799 Summary: Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799

   What|Removed |Added

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

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

--- Comment #11 from Marek Polacek  ---
*** Bug 90003 has been marked as a duplicate of this bug. ***

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #12 from Marek Polacek  ---
Another test: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003#c3

[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783

2019-04-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #5 from Marek Polacek  ---
This is actually a duplicate of 89953.

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

[Bug c++/65799] Allows constexpr conversion from cv void * to other type

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799

Martin Sebor  changed:

   What|Removed |Added

 Blocks||55004

--- Comment #6 from Martin Sebor  ---
Sure, I can look into it sometime in stage 1.  But I'm not sure these bugs are
related.  The test case in comment #0 and those in pr60760 and pr71091 are
about invalid uses of null pointers in constexpr contexts.  The test cases here
don't involve bull pointers.  Rejecting invalid casts was the subject of
pr49171 (fixed in r259629).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection,|ice-on-valid-code
   |needs-reduction |
 CC||jason at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
Started with r269746.

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Martin Liška  changed:

   What|Removed |Added

  Attachment #46092|0   |1
is obsolete||

--- Comment #9 from Martin Liška  ---
Created attachment 46178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46178=edit
Reduced test-case

[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs

2019-04-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088

--- Comment #5 from H.J. Lu  ---
We should first add an LEA microbenchmark to

https://gitlab.com/x86-benchmarks/microbenchmark

[Bug c++/86953] [7/8 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

2019-04-16 Thread remi.ducceschi at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953

--- Comment #8 from Rémi Ducceschi  ---
It seems to be fixed on the last version available on wandbox.org (gcc HEAD
9.0.1 201904): https://wandbox.org/permlink/Tu4T8jEXDDtDw0OS

Though it doesn't work on any other versions (8.3.0...).
Any chance to see the fix in the 8 branch?

Anyway, thanks a lot :)

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #74 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #73)
> (In reply to Iain Sandoe from comment #68)
> > Created attachment 46176 [details]
> > revised fixincludes patch.
> 
> > 
> > The patch attached include the generated files, and I'd be grateful if folks
> > would test it (right now I have limited access to Darwin test boxen, but it
> > seems to DTRT for me) - I will post to @patches, but leave commit until it's
> > confirmed that it's working.
> 
> This fix works for me on Darwin 10.14.4, XCode 10.2, with r270377.

Thanks, does that include a test suite run and/or building something
substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted, very
limited access to Darwin test resources.

[Bug libstdc++/90050] std::filesystem::path segfault in destructor

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050

--- Comment #7 from Jonathan Wakely  ---
See https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/1824721 where I said:

"for now the short answer is "C++17 support in GCC 8 is experimental, the onus
is on you to link correctly"

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-16 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #73 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.

> 
> The patch attached include the generated files, and I'd be grateful if folks
> would test it (right now I have limited access to Darwin test boxen, but it
> seems to DTRT for me) - I will post to @patches, but leave commit until it's
> confirmed that it's working.

This fix works for me on Darwin 10.14.4, XCode 10.2, with r270377.

[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result

2019-04-16 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106

Alexander Monakov  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2019-04-16
 CC||amonakov at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #6 from Alexander Monakov  ---
Reopening and confirming, GCC's code looks less efficient than possible for no
good reason.

CDCE does

y = sqrt (x);
 ==>
y = IFN_SQRT (x);
if (__builtin_isless (x, 0))
sqrt (x);

but it could do

y = IFN_SQRT (x);
if (__builtin_isless (x, 0))
y = sqrt (x);

(note two assignments to y)

or to mimic LLVM's approach:

if (__builtin_isless (x, 0))
y = sqrt (x);
else
y = IFN_SQRT (x);

[Bug debug/89983] Missing debug info for final loop IV value

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89983

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Alexandre Oliva  ---
It appears to me that a debugger with support for location views will address
the problems you reported; I'm not so sure about the first issue (inside the
loop), but certainly the second one (at the asm).

[Bug libstdc++/90050] std::filesystem::path segfault in destructor

2019-04-16 Thread mpreda at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050

--- Comment #6 from Mihai Preda  ---
OK, thanks.

So if on Ubuntu 19.04, the default compiler produces without errors/warnings,
from valid source code, an executable that crashes, that's programmer error?!

I understand the explanation, but there is a problem. Maybe the bug is not with
gcc but with Ubuntu, but a bug there is.

[Bug other/88790] No warning for misleading indentation

2019-04-16 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790

--- Comment #4 from Segher Boessenkool  ---
(Yup, worked).

[Bug other/88790] No warning for misleading indentation

2019-04-16 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790

Segher Boessenkool  changed:

   What|Removed |Added

 CC||daniel.marjamaki at gmail dot 
com

--- Comment #3 from Segher Boessenkool  ---
Let's try that...

[Bug debug/82738] [meta-bug] issues with the -Og optimization level

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 89528, which changed state.

Bug 89528 Summary: Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528

   What|Removed |Added

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

[Bug debug/90017] gcc generates wrong debug information at -O3

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017

--- Comment #5 from Alexandre Oliva  ---
I think it's more of a missing feature than a bug.  I believe GDB folks already
know about this, though maybe not about this specific manifestation thereof.

[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Fixed

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #1 from Ian Lance Taylor  ---
The pathnames suggest that this is the -m32 build.

Can you attach the file TARGET/32/libgo/math.gox?

[Bug rtl-optimization/86438] [8 Regression] wrong code at -Os

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438

--- Comment #12 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Apr 16 12:44:46 2019
New Revision: 270388

URL: https://gcc.gnu.org/viewcvs?rev=270388=gcc=rev
Log:
[PR86438] avoid too-long shift in test

The test fell back to long long and long when __int128 is not
available, but it assumed sizeof(long) < sizeof(long long) because of
a shift count that would be out of range for a long long if their
widths are the same.  Fixed by splitting it up into two shifts.


for  gcc/testsuite/ChangeLog

PR rtl-optimization/86438
* gcc.dg/torture/pr86438.c: Split up too-wide shift.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr86438.c

[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]

2019-04-16 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Apr 16 12:44:57 2019
New Revision: 270389

URL: https://gcc.gnu.org/viewcvs?rev=270389=gcc=rev
Log:
[PR89528] reset debug uses of return value when dropping dead RTL call

When we remove an RTL call, we wouldn't clean up references to the
return value of the call in debug insns.  Make it so that we do.


for  gcc/ChangeLog

PR debug/89528
* valtrack.c (dead_debug_insert_temp): Reset debug references
to the return value of a call being removed.

for  gcc/testsuite/ChangeLog

PR debug/89528
* gcc.dg/guality/pr89528.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr89528.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/valtrack.c

[Bug middle-end/90115] New: OpenACC: predetermined private levels for variables declared in blocks

2019-04-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115

Bug ID: 90115
   Summary: OpenACC: predetermined private levels for variables
declared in blocks
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data
Attributes" mandates that "Variables declared in a C block that is executed in
'vector-partitioned' mode are private to the thread associated with each vector
lane. Variables declared in a C block that is executed in 'worker-partitioned'
'vector-single' mode are private to the worker and shared across the threads
associated with the vector lanes of that worker. Variables declared in a C
block that is executed in 'worker-single' mode are private to the gang and
shared across the threads associated with the workers and vector lanes of that
gang".

[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result

2019-04-16 Thread fredericopissarra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106

--- Comment #5 from Frederico Lamberti Pissarra  ---
CLANG 6 creates a similar code:

  f:
xorps %xmm1,%xmm1
ucomiss %xmm1,%xmm0
jb .L8   # more intutive test...
sqrtss
ret
  .L8:
jmp sqrtf@PLT

[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result

2019-04-16 Thread fredericopissarra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106

--- Comment #4 from Frederico Lamberti Pissarra  ---
My suggestion is to do a simple jmp after .L8 label and test the condition
before sqrtss (or fsqrt, or sqrtsd...):

  f:
pxor %xmm2,%xmm2
ucomiss %xmm0,%xmm2
ja .L8
sqrtss %xmm0,%xmm0
ret
  .L8:
jmp sqrtf@PLT

[Bug middle-end/90114] New: Predetermined private levels for variables declared in OpenACC accelerator routines

2019-04-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114

Bug ID: 90114
   Summary: Predetermined private levels for variables declared in
OpenACC accelerator routines
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data
Attributes" mandates that "Variables declared in 'seq' routine are private to
the thread that made the call. Variables declared in 'vector' routine are
private to the worker that made the call and shared across the threads
associated with the vector lanes of that worker. Variables declared in 'worker'
or 'gang' routine are private to the gang that made the call and shared across
the threads associated with the workers and vector lanes of that gang".

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102

--- Comment #3 from Jonathan Wakely  ---
I'm not sure if the original testcase is actually required to compile.
Implementations are allowed to add additional constructors, and they could take
an arbitrary type with a .clear() member.

But as a QoI matter we do want the same code to compile with debug mode as for
normal mode.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

2019-04-16 Thread fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093

--- Comment #49 from Florian Weimer  ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to Florian Weimer from comment #47)
> > (In reply to Bernd Edlinger from comment #43)
> > > does anybody know what is the Ada and/or D syntax for that?
> > 
> > Syntax for what?
> 
> I mean the Ada and D equivalent of
> #pragma GCC target ("general-regs-only")
> and/or
> __attribute__((target("general-regs-only")))

I don't think the target pragma/attribute is supported in Ada.

   pragma Machine_Attribute (Subprogram, "target", "general-regs-only");

appears to be ignored (even if I use a string which would be accepted by the
C/C++ pragma for that target, and not "general-regs-only".  But it's been years
since I did much Ada programming.

[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets

2019-04-16 Thread zhroma at ispras dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #12 from Roman Zhuykov  ---
Not sure if I have to reopen it, but fix wasn’t correct.  In this example we
don’t have -fmodulo-sched-allow-regmoves enabled and we should not create any
register moves at all.

More discussion and proper fix:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00632.html

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> A DEBUG::debug vector

s/DEBUG::debug vector/DEBUG::vector/

[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783

2019-04-16 Thread rene.r...@fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003

--- Comment #4 from rene.r...@fu-berlin.de ---
Hi gcc-team,

is there any news about this issue? 

Let me know, if you need more information.

Kind regards

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

2019-04-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It's definitely a library bug. The problem is shown by the diagnostic messages.

A DEBUG::debug vector can be constructed from a NORMAL::vector, because it has
an extra constructor. Your conversion operator allows your type to convert to
either DEBUG::vector or NORMAL::vector. Both of those types can convert to
DEBUG::vector, so there are two equally good conversion sequences, which is
ambiguous.

[Bug testsuite/90113] New: Useless torture mode for gfortran.dg tests

2019-04-16 Thread zhroma at ispras dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113

Bug ID: 90113
   Summary: Useless torture mode for gfortran.dg tests
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at ispras dot ru
  Target Milestone: ---

I’ve recently found that tests, which are placed in gcc/testsuite/gfortran.dg
folder are running in “torture” mode with different optimization options.

While working with PR90001 I’ve looked into sms-2.f90 and forall_10.f90 tests
from gfortran.dg.  I analyzed only compilation time in that PR, but also was
wondered with that these tests were compiled several times with lines like:
sms-2.f90:
“-O0 -O2 -fmodulo-sched”
“-O1 -O2 -fmodulo-sched”
...
“-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O2 -fmodulo-sched”

forall_10.f90
“-O0 -O”
“-O1 -O”
...
“-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O”

I’ve found a discussion when gfortran.dg/dg.exp was added in 2004, and there 
Joseph mentioned “torture” ideas:
https://gcc.gnu.org/ml/gcc-patches/2004-07/msg01131.html
“gcc.c-torture: multiple optimization options, built with -w to disable all
warnings.
gcc.dg: no looping over multiple options, defaults to -ansi -pedantic if
no options given.
gcc.dg/torture: like gcc.dg (so no -w) but loops over multiple options.  
Much of gcc.dg that uses some optimization options belongs in there.”

I’ve started working with gcc a bit later, but I always thought, that same
logic can be applied to other languages.  And now I know that in fortran tests
it is broken since that old time.

Looking into recent commits (which add new fortran tests) shows that people
also wrongly suppose that difference between gfortran.fortran-torture and
gfortran.dg is same as in C language test folders (gcc.c-torture and gcc.dg).

So, a lot of tests in gfortran.dg contain optimization level option, and this
leads to many useless torture runs.  In most torture option lines only
optimization level is set, and an option inside test overrides that level.

Maybe this broken logic should be fixed and we have to disable torture runs in
gfortran.dg and run them like gcc.dg tests?

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
 Status|WAITING |NEW
  Known to work||8.2.0, 8.3.0
  Known to fail||8.1.0, 9.0

--- Comment #8 from Martin Liška  ---
Confirmed, thanks for test-case. I'm both reducing and bisecting that..

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

2019-04-16 Thread zhroma at ispras dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90001

--- Comment #5 from Roman Zhuykov  ---
Retested patch separately, everything works.
Have found 2 more slow Fortran examples on (obsolete) spu platform and with
additional options like -O1/O2 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions

gfortran.dg/sms-2.f90 
gfortran.dg/forall_10.f90

Compilation|
time, sec  |unpatched vs patched| sms options
forall_10  |  35.02   0.66  | -fmodulo-sched
forall_10  |  87.44   0.52  | -fmodulo-sched -fmodulo-sched-allow-regmoves
sms-2  |  34.58   0.44  | -fmodulo-sched
sms-2  |  86.77   0.27  | -fmodulo-sched -fmodulo-sched-allow-regmoves

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

2019-04-16 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164

--- Comment #3 from David Binderman  ---
I'd be happy to help out with any testing of any speculative patch
for this bug.

I am surprised that more than 64 bits of precision are required.

Would a data type like float or double do the job ? Less precision,
more range.

  1   2   >