[Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|WAITING |NEW
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #16 from Jeffrey A. Law  ---
In response to c#10 and c#11.  I suspect you're not able to trigger the
failures because of something in auto-host.h.  If I first configure & install
binutils for the target (mips-mti-linux-gnu), then configure gcc for the same
target I can trigger the failures per the instructions in this BZ.

What I'm unable to figure out is my own comment WRT FRAME_RELATED_P from last
year.  I don't see any evidence this is at all related to FRAME_RELATED_P insns
in delay slots.

AFAICT we've done shrink wrapping on this case.  ISTM there's multiple paths to
the epilogue, some save r16/r17 and adjust the stack pointer, others do not
(according to my reading of the dwarf2cfi pass RTL dump).  Thus triggering the
CFI failure due to the inconsistency (not to mention bogus code).

So of course the next thing to do is look at the prologue/epilogue dump and
everything looks fine there.  Things also look fine at the .barriers dump. 
Then reorg comes along and mucks things up horribly.


The bug here is in reorg and its legacy of trying to compensate for the lack of
a CFG.  In particular it has a function skip_consecutive_labels.  The idea (of
course) is to have jumps target the last label if there's several in a row. 
The code looks something like this:

  for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn))
if (LABEL_P (insn))
  label = insn;

THe loop termination condition allows the code to look through notes and other
random crud.

Now imagine if we have

(code_label 1)
(barrier)
(code_label 2)
(more code)

The BARRIER after a CODE_LABEL can occur due to __builtin_unreachable.

If a jump targets code_label 1, it will be redirected to code_label 2.  That's
fine from a runtime standpoint, but runs afoul of the CFI bits.  Why?

Consider if the jump which targeted label 1 did not have a prologue (we're
shrink wrapping) and "more code" section is a shrink wrapped epilogue.

The original paths to code_label 2 will have one CFI state while the new paths
to code_label 1 will have a different CFI state and we trip the check.

I'm spinning a fix overnight.

[Bug c++/89917] [8/9 Regression] ICE with lambda in variadic template hierarchy

2019-04-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89917

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Apr  3 04:48:45 2019
New Revision: 270111

URL: https://gcc.gnu.org/viewcvs?rev=270111=gcc=rev
Log:
PR c++/89917 - ICE with lambda in variadic mem-init.

A mem-initializer is not a type, and we don't want to turn autos within it
into packs.

* pt.c (make_pack_expansion): Change type_pack_expansion_p to false.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/89940] New: Template substitution causes segfault

2019-04-02 Thread jonehartnett at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89940

Bug ID: 89940
   Summary: Template substitution causes segfault
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonehartnett at yahoo dot com
  Target Milestone: ---

Created attachment 46078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46078=edit
Preprocessed source file

GCC: 8.20 and 7.3.0
System: Ubuntu 18.04
Target: x86_64-linux-gnu
Command: gcc main.cpp
Output:
main.cpp: In substitution of ‘template using C = B [with int Y =
D()]’:
main.cpp:21:13:   required from here
main.cpp:12:20: internal compiler error: Segmentation fault
 using C = B;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



The code provided has been simplified to highlight the conditions required to
trigger the error. The segfault requires the following properties:
* X must be dependent on T
* B must be used indirectly through C
* Y must be the result of a constexpr
* W must be an template parameter to D
Changing or omitting any of these conditions (perhaps through manually
inlining) does not trigger the segfault.

[Bug c++/89917] [8/9 Regression] ICE with lambda in variadic template hierarchy

2019-04-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89917

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/88419] [7/8 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #10 from Matthias Klose  ---
this causes PR89928 on the gcc-8 branch.

[Bug c++/89928] [8 Regression] errors out in c++17 mode

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89928

--- Comment #4 from Matthias Klose  ---
caused by r269512, the fix for PR88419.

[Bug c++/89906] [8 Regression] template template parameter redeclared

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906

--- Comment #2 from Matthias Klose  ---
caused by r269512, the fix for PR88419.

[Bug c++/89928] [8 Regression] errors out in c++17 mode

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89928

--- Comment #3 from Matthias Klose  ---
works on the trunk

[Bug c++/89906] [8 Regression] template template parameter redeclared

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89906

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #1 from Matthias Klose  ---
from PR89928:

$ cat main.ii
template  class> struct a;
template  class T1> struct b { a c; };
template  class F> struct d;
template  class F> struct d;

$ g++ -std=c++17 main.ii
main.ii:3:66: error: template parameter 'template
class F'
 template  class F> struct d;
  ^
main.ii:4:76: error: redeclared here as 'template
class F'
 template  class F> struct d;
^

works on the trunk.

[Bug rtl-optimization/89895] Unable to sink high half of widening multiply out of loop

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug rtl-optimization/89895] Unable to sink high half of widening multiply out of loop

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
.

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-02
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Jonathan Wakely  ---
Right, the program is using std::regex incorrectly, and has undefined
behaviour.

Compiling with -D_GLIBCXX_ASSERTIONS will cause the program to abort at
runtime:

/home/jwakely/gcc/8/include/c++/8.3.1/bits/regex_scanner.tcc:189: void
std::__detail::_Scanner<_CharT>::_M_scan_normal() [with _CharT = char]:
Assertion 'false' failed.
Aborted (core dumped)

It would be good if that assertion was more explanatory, or at least had a
comment saying it will only be reached when given bad input. I'm confirming
this bug as a reminder to improve that some time.


Adding this constructor to basic_regex turns the example into a compile-time
error:

  template
basic_regex(const value_type*, const value_type(&)[_Num],
flag_type = ECMAScript) = delete;

I don't think that's a good idea though, as it would also cause us to reject
some valid (albeit useless) code like:

  const char s[] = ".*";
  std::regex r(s, s);

[Bug fortran/89938] inconsistent wording regarding assumed shape

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-02
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Dominique d'Humieres  ---
> Which one is correct, the "assumed shape" or the "assumed-shape"?

The Fortran standard uses "assumed-shape".

Grepping for the strings I see several other places where the spelling is not
done consistently:

gcc/fortran/array.c:gfc_error ("Bad array specification for assumed
shape "
gcc/fortran/array.c:  gfc_error ("Bad array specification for assumed
shape "
gcc/fortran/array.c:  /* If a lower bounds of an assumed shape array is blank,
put in one.  */
gcc/fortran/class.c:  /* If strides aren't allowed (not assumed shape or
CONTIGUOUS),
gcc/fortran/decl.c:  gfc_error ("Cray Pointee at %C cannot be assumed shape
array");
gcc/fortran/expr.c: gfc_error ("Assumed shape array %qs at %L is
not permitted "
gcc/fortran/gfortran.texi:in place of a value. A pointee cannot be an assumed
shape array.
gcc/fortran/interface.c:   "ASSUMED SHAPE ARRAY",
>declared_at);
gcc/fortran/invoke.texi:In some circumstances GNU Fortran may pass assumed
shape array
gcc/fortran/io.c: gfc_error ("Non-character assumed shape array element
in FORMAT"
gcc/fortran/module.c:read is an index for an assumed shape dummy array (ns
!= 1).  */
gcc/fortran/resolve.c:  /* Warn if the procedure is non-scalar and not
assumed shape.  */
gcc/fortran/resolve.c:"with assumed shape in namelist
%qs at %L",
gcc/fortran/resolve.c:  /* Assumed size arrays and assumed shape arrays must be
dummy
gcc/fortran/resolve.c:  gfc_error ("Assumed shape array at %L must be a
dummy argument",
gcc/fortran/trans-array.c:  /* This should only ever happen when passing an
assumed shape array
gcc/fortran/trans-array.c:/* For assumed shape arrays move the upper
bound by the same amount
gcc/fortran/trans-decl.c:  /* Don't try to use the unknown bound for
assumed shape arrays.  */
gcc/fortran/trans-expr.c:ALLOCATABLE or assumed shape, we do not use
g77's calling
gcc/fortran/trans-types.c:  /* Nor non-constant lower bounds in assumed shape
arrays.  */
gcc/fortran/trans-types.c:/* Assumed shape arrays have known lower
bounds.  */

[Bug translation/89939] New: messages for translation must not contain embedded macro parameters

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

Bug ID: 89939
   Summary: messages for translation must not contain embedded
macro parameters
   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 fortran/frontend-passes.c:

#define B_ERROR(n) _("Incorrect extent in argument B in MATMUL intrinsic in " \
 "dimension " #n ": is %ld, should be %ld")

#define C_ERROR(n) _("Array bound mismatch for dimension " #n " of array " \
 "(%ld/%ld)")

In the .pot file, this results in:

msgid "Array bound mismatch for dimension "
msgstr ""

This translation entry will never be used. The part after the #n doesn't make
it to the .pot file at all.

Please write a linter that prevents this kind of bug. It's not the first time
I've seen it, and I don't want to remind you every year.

[Bug fortran/89938] New: inconsistent wording regarding assumed shape

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

Bug ID: 89938
   Summary: inconsistent wording regarding assumed shape
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From fortran/expr.c:

gfc_error ("Assumed shape array %qs at %L is not permitted "
   "in an initialization expression",

gfc_error ("Assumed-shape array %qs at %L is not permitted "
   "in an initialization expression",

Which one is correct, the "assumed shape" or the "assumed-shape"?

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #14 from Iain Buclaw  ---
Created attachment 46077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46077=edit
Add libphobos_test_name var

I'll just post this before I retired.

[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is because of the way inline have different semantics between the two
langauges.

If I change TSFastDbg to be static instead of just inline, then the code
emitted is the same.
In the case of C, since TSFastDbg is not inlined, there exists an out of line
version of it in a different TU.
In the case of C++, TSFastDbg has vague linkage, there for will be emitted but
in a comdat section.

The options you have turned on for godbolt, hide this fact; turning them off
you get:

.Ltext0:
.section   
.text._Z9TSFastDbgP14TSFastDbgCntl_PKcz,"axG",@progbits,_Z9TSFastDbgP14TSFastDbgCntl_PKcz,comdat
.p2align 4,,15
.weak   _Z9TSFastDbgP14TSFastDbgCntl_PKcz
.type   _Z9TSFastDbgP14TSFastDbgCntl_PKcz, @function
_Z9TSFastDbgP14TSFastDbgCntl_PKcz:

See how that is a comdat section.

[Bug c++/89937] New: For example code, which is valid as either C or C++, optimization seems much better for C

2019-04-02 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937

Bug ID: 89937
   Summary: For example code, which is valid as either C or C++,
optimization seems much better for C
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wkaras at yahoo dot com
  Target Milestone: ---

I compiled this code with -O2, and with either -x c or -x c++ .  The
optimization seems to work much better for C than for C++.

typedef struct TSFastDbgCntl_
{
const char * const tag; // nul-terminated string
const char * const on;  // pointer to 1-byte flag
}
TSFastDbgCntl;

TSFastDbgCntl * TSCreateFastDbgCntl(const char *tag);

#include 
void TSVDebug(const char *tag, const char *fmt, va_list args);
inline void TSFastDbg(TSFastDbgCntl *fd_cntl, const char *fmt, ...)
{
if (fd_cntl->on)
{
va_list ap;
va_start(ap, fmt);
TSVDebug(fd_cntl->tag, fmt, ap);
}
}

void dummy(int i, double d)
{
TSFastDbgCntl *fd_cntl = TSCreateFastDbgCntl("pluggymcplugin");
TSFastDbg(fd_cntl, "Test %d %f", i * 5, d * 7);
TSFastDbg(fd_cntl, "Test fixed string");
}

https://godbolt.org/z/d2MzPo

Note that the difference in optimization of this code for C vs. C++ is similar
for clang/LLVM.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

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

--- Comment #5 from Roland Illig  ---
I wouldn't classify bug 89936 as trivial as it strongly recommends to write a
linter, and that might take a while. Especially since the GCC project seems to
avoid these consistency linters; at least that's my impression from the last
few years as the German translator. As I said in bug 89936, there are quite a
few inconsistencies in the messages that could easily be caught by a linter.

[Bug translation/89936] wrong punctuation in tree-profile.c

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

--- Comment #2 from Roland Illig  ---
Just as a reference, I wrote a little linter just for fun 2 years ago. Since it
was February 2017, it was most likely targeted at GCC 7.

https://github.com/rillig/translation-team-de/blob/master/proofread.lua

I'm sure there is a more robust library out there for the same job, only
better. That library could be used to implement the linter I talked about.

[Bug translation/89936] wrong punctuation in tree-profile.c

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

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/89936] wrong punctuation in tree-profile.c

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

--- Comment #1 from Roland Illig  ---
And just in case the punctuation in this particular message is fully
intentional: Please document it why it needs to be exactly this way. It looks
too much like a mistake.

[Bug translation/89936] New: wrong punctuation in tree-profile.c

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

Bug ID: 89936
   Summary: wrong punctuation in tree-profile.c
   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: ---

error ("invalid regular expression '%s' in %<%s%>",

Please implement a GCC-specific linter that prohibits single quotes in
messages. These should either be %' if they are meant as punctuation, or %q if
they enclose a placeholder.

Do not just fix this single typo. There are more to come, and they will never
end. I've seen far too many now. Just write a little linter. It's not that
difficult.

[Bug tree-optimization/79878] verify_gimple_assign_single: replace error with internal_error

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

--- Comment #1 from Roland Illig  ---
Two years later, nothing has changed.

As the German translator, I refuse to translate these messages. There is really
nothing a GCC user could take away from a message like "incorrect entry in
label_to_block_map".

[Bug c/89933] [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
cc1plus also crashes.

[Bug libstdc++/85184] Remove __glibcxx_assert uses from std::variant

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug middle-end/89921] The jump threading increases the size a lot when having an huge inline-asm

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|The dom pass does not   |The jump threading
   |respect size of an 'asm'|increases the size a lot
   |when duplicating BBs|when having an huge
   ||inline-asm
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
tree-ssa-threadupdate.c only deletes the threaded jumps when optimizing for
size:
  /* When optimizing for size, prune all thread paths where statement
 duplication is necessary.

 We walk the jump thread path looking for copied blocks.  There's
 two types of copied blocks.

   EDGE_COPY_SRC_JOINER_BLOCK is always copied and thus we will
   cancel the jump threading request when optimizing for size.

   EDGE_COPY_SRC_BLOCK which is copied, but some of its statements
   will be killed by threading.  If threading does not kill all of
   its statements, then we should cancel the jump threading request
   when optimizing for size.  */

I think there was a discussion about this similar thing on the mailing list
before.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #13 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #12)
> 
> They differ by libphobos_run_args, not by compilation flags.
> 
> Maybe I'm running these tests in a lazy way, but would appending the
> execution args to the name be sufficient?  And in which place?
> 

Actually, I'll just add a compilation flag that does nothing to the test.

[Bug middle-end/89921] The dom pass does not respect size of an 'asm' when duplicating BBs

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

--- Comment #1 from Andrew Pinski  ---
The code get the correct cost is there (in estimate_num_insns):
case GIMPLE_ASM:
  {
int count = asm_str_count (gimple_asm_string (as_a  (stmt)));
/* 1000 means infinity. This avoids overflows later
   with very long asm statements.  */
if (count > 1000)
  count = 1000;
/* If this asm is asm inline, count anything as minimum size.  */
if (gimple_asm_inline_p (as_a  (stmt)))
  count = MIN (1, count);
return MAX (1, count);
  }

/* Return the number of machine instructions likely to be generated for the
   inline-asm template. */
int
asm_str_count (const char *templ)
{
  int count = 1;

  if (!*templ)
return 0;

  for (; *templ; templ++)
if (IS_ASM_LOGICAL_LINE_SEPARATOR (*templ, templ)
|| *templ == '\n')
  count++;

  return count;
}
 CUT 
Maybe jump threading (in DOM) is not using estimate_num_insns to get that cost.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #12 from Iain Buclaw  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > --- Comment #6 from Iain Buclaw  ---
> > Created attachment 46069 [details]
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46069=edit
> > Use dg-runtest instead of dg-test
> >
> > (In reply to Iain Buclaw from comment #4)
> >> (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> >> > 
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > 
> >> > compilation is run 10 times in exactly the same way!?
> >> > 
> >> 
> >> Maybe something is missing in the part copied from 
> >> GCC_RUNTEST_PARALLELIZE. 
> >> I did see problems copying gcc_parallel_test_run_p and other procedures
> >> locally to the libphobos testsuite, it looked like it replaced itself
> >> incorrectly.
> >
> > Ahh, we're calling dg-test directly, instead of dg-runtest, so there's no
> > protection against parallelized tests.
> >
> > Looking at dejagnu/dg.exp, there's no reason to use dg-test, so switching 
> > all
> > over.
> 
> Yes, that worked fine, thanks.  However, looking at libphobos.sum now,
> there are still 3 tests that show up more than twice (once for each
> multilib):
> 
>   8 PASS: libphobos.cycles/mod1.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod1.d execution test
>   8 PASS: libphobos.cycles/mod2.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod2.d execution test
>   8 PASS: libphobos.cycles/mod3.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod3.d execution test
> 
> The different compilations/executions should be distinguished somehow in
> the test names.

They differ by libphobos_run_args, not by compilation flags.

Maybe I'm running these tests in a lazy way, but would appending the execution
args to the name be sufficient?  And in which place?


libphobos_load:
---
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate execution test
---

libphobos-dg-test:
---
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate execution test
---

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #20 from anlauf at gcc dot gnu.org ---
Patch here:

https://gcc.gnu.org/ml/fortran/2019-04/msg3.html

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

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

--- Comment #15 from Segher Boessenkool  ---
It seems to be that this happens for huge basic blocks, and the combiner
tries to combine pairs of instructions that are far apart.  This is unlikely
to work often, and the cost is quadratic in # insns, the way checking where
a register is used works.

The param to do only 2->1 (and 2->2) combinations should help a lot, make
combine not take longer than the rest of the compiler does.  Does it?

[Bug c/89798] excessive vector_size silently accepted and truncated

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

--- Comment #3 from Martin Sebor  ---
One of the reasons why big vectors don't work seems to be the assumption in
TYPE_VECTOR_SUBPARTS() that they can't be bigger than 2^31.  But fixing this
function alone doesn't seem to be sufficient.

inline poly_uint64
TYPE_VECTOR_SUBPARTS (const_tree node)
{
  STATIC_ASSERT (NUM_POLY_INT_COEFFS <= 2);
  unsigned int precision = VECTOR_TYPE_CHECK (node)->type_common.precision;
  if (NUM_POLY_INT_COEFFS == 2)
{
  poly_uint64 res = 0;
  res.coeffs[0] = 1 << (precision & 0xff);
  if (precision & 0x100)
res.coeffs[1] = 1 << (precision & 0xff);
  return res;
}
  else
return 1 << precision;
}

[Bug target/89932] ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824

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

--- Comment #2 from Andrew Pinski  ---
Most likely a dup of bug 67694.

[Bug target/89935] New: [Arm] Return from interrupt on Cortex-R52 must use eret instruction

2019-04-02 Thread alfedotov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89935

Bug ID: 89935
   Summary: [Arm] Return from interrupt on Cortex-R52 must use
eret instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alfedotov at gmail dot com
  Target Milestone: ---

Compiling following code for Arm Cortex-r52:

extern int another_func(int);
void __attribute__ ((interrupt ("IRQ"))) IRQ_Handler(void)
{
  another_func(0);
}

gcc generates epilogue respectively:
  ldmfdsp!, {r0, r1, r2, r3, r4, fp, ip, pc}^

The problem is that on Cortex-R52 virtualization is used so that when IRQ
interrupt happens in Hypervisor mode (EL2) return from interrupt must use ERET
instruction. Otherwise Undefined exception occurs (what actually corresponds to
chapter F5.1.65 LDM (exception return) in
https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf?_ga=2.927729.1146405679.1554127327-529207546.1554127327)

Probably we should introduce new ISR attribute like IRQ_el2 or IRQ_hyp.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #17)
> > So shall I resubmit my original patch, or is Steve's comment#11 better?
> 
> I'ld take Steve's conditions, but your wording for the errors!-)

Steve's patch would not reject:

subroutine f
  use, intrinsic :: iso_c_binding
  integer(c_intptr_t) :: b, c
  procedure(), pointer :: a
  c = transfer (a, b)
  c = transfer (transfer (b, a), b)
end

so this is probably what Thomas had in mind.

I'll package the patch and submit.

[Bug target/89932] ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  Not a recent regression.

[Bug c/89933] [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
The ICE was introduced in r237137:

r237137 | mpolacek | 2016-06-06 11:50:23 -0400 (Mon, 06 Jun 2016) | 8 lines

* c-typeck.c (comptypes_internal): Handle comparisons of
INTEGER_TYPE, FIXED_POINT_TYPE, and REAL_TYPE nodes.  Don't check
TYPE_REF_CAN_ALIAS_ALL.

Before then GCC failed to accept the code:

t.c:2:22: error: conflicting types for ‘a’
 typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
  ^
t.c:1:22: note: previous declaration of ‘a’ was here
 typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
  ^

[Bug middle-end/89934] [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7237

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Introduced in r255031:

r255031 | msebor | 2017-11-21 15:01:58 -0500 (Tue, 21 Nov 2017) | 29 lines

PR tree-optimization/82945 - add warning for passing non-strings to functions
that expect string arguments

gcc/ChangeLog:

PR tree-optimization/82945
* builtins.c (expand_builtin_strlen): Call maybe_warn_nonstring_arg.
* calls.h (maybe_warn_nonstring_arg): Declare new function.
* calls.c (get_attr_nonstring_decl, maybe_warn_nonstring_arg): New
functions.
(initialize_argument_information): Call maybe_warn_nonstring_arg.
* calls.h (get_attr_nonstring_decl): Declare new function.
* doc/extend.texi (attribute nonstring): Update.
* gimple-fold.c (gimple_fold_builtin_strncpy): Call
get_attr_nonstring_decl and handle it.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.  Improve
detection of nul-termination.
(strlen_to_stridx): Change to a pointer.
(handle_builtin_strlen, handle_builtin_stxncpy): Adjust.
(pass_strlen::execute): Same.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread tkoenig at netcologne dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #18 from tkoenig at netcologne dot de  ---
Am 02.04.19 um 20:48 schrieb anlauf at gcc dot gnu.org:
> I had rejected procedure arguments to TRANSFER in my initial patch, see
> 
> https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html
> 
> but Thomas persuaded me to be less strict.

I guess I had it wrong, then.

Procedure pointer arguments to functions should be OK and take
their type etc. information from the type of the pointer.
Also, functions returning pointers should be permitted.
This is what I orignally had in mind.

I agree that mysel a subroutine argument or pure function argument
makes no sense.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #17 from Dominique d'Humieres  ---
> So shall I resubmit my original patch, or is Steve's comment#11 better?

I'ld take Steve's conditions, but your wording for the errors!-)

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #16 from anlauf at gcc dot gnu.org ---
I had rejected procedure arguments to TRANSFER in my initial patch, see

https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html

but Thomas persuaded me to be less strict.

So shall I resubmit my original patch, or is Steve's comment#11 better?

Of course the testcase needs adjustments.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #15 from Dominique d'Humieres  ---
Note that the patch in comment 11 is quite close to the Harald's original patch
at

https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html

[Bug c/89934] New: [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7237

2019-04-02 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Bug ID: 89934
   Summary: [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7237
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190210 and 20190217, at -O[s123].
(gcc-8 needs -Wall, and changed behavior before 20180525)


$ cat z1.c
char *strncpy();
void foo (char *a)
{
  strncpy (a, a);
}


$ gcc-9-20190331 -c z1.c -O2
z1.c: In function 'foo':
z1.c:4:3: warning: too few arguments to built-in function 'strncpy' expecting 3
[-Wbuiltin-declaration-mismatch]
4 |   strncpy (a, a);
  |   ^~~
z1.c:1:7: note: declared here
1 | char *strncpy();
  |   ^~~
during GIMPLE pass: wrestrict
z1.c:2:6: internal compiler error: Segmentation fault
2 | void foo (char *a)
  |  ^~~
0xa748df crash_signal
../../gcc/toplev.c:326
0xca6a37 tree_fits_uhwi_p(tree_node const*)
../../gcc/tree.c:7237
0x6aecbc get_size_range(tree_node*, tree_node**, bool)
../../gcc/calls.c:1238
0x83ca3e builtin_access
../../gcc/gimple-ssa-warn-restrict.c:735
0x83d39f check_bounds_or_overlap(gimple*, tree_node*, tree_node*, tree_node*,
tree_node*, bool, bool)
../../gcc/gimple-ssa-warn-restrict.c:1933
0x83f7f0 check_call
../../gcc/gimple-ssa-warn-restrict.c:1904
0x83f7f0 before_dom_children
../../gcc/gimple-ssa-warn-restrict.c:105
0x1164c54 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0x835aa7 execute
../../gcc/gimple-ssa-warn-restrict.c:119

[Bug target/89903] [9 Regression] ICE: in convert_op, at config/i386/i386.c:2102 with -O2 -march=skylake

2019-04-02 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89903

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.0 |8.4

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug target/89902] ICE: in extract_insn, at recog.c:2310: unrecognizable insn with -mavx512bitalg

2019-04-02 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89902

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |8.4

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug c/89933] New: [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517

2019-04-02 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89933

Bug ID: 89933
   Summary: [7/8/9 Regression] ICE in merge_decls, at
c/c-decl.c:2517
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Doubled line affects versions 7 up to trunk.
gcc-6 rejects it with an error.
clang7 and icc19 accepts it without any warning/error.


$ cat z1.c
typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));


$ gcc-9-20190331 -c z1.c
z1.c:2:1: internal compiler error: Segmentation fault
2 | typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
  | ^~~
0xa748df crash_signal
../../gcc/toplev.c:326
0x5c9023 merge_decls
../../gcc/c/c-decl.c:2517
0x5c9023 duplicate_decls
../../gcc/c/c-decl.c:2886
0x5cb067 pushdecl(tree_node*)
../../gcc/c/c-decl.c:3072
0x5db56d start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc/c/c-decl.c:5016
0x61d983 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2154
0x623a53 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x624519 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x624519 c_parse_file()
../../gcc/c/c-parser.c:19854
0x66ba20 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug target/89903] [9 Regression] ICE: in convert_op, at config/i386/i386.c:2102 with -O2 -march=skylake

2019-04-02 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89903

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  2 18:37:14 2019
New Revision: 270104

URL: https://gcc.gnu.org/viewcvs?rev=270104=gcc=rev
Log:
PR target/89902
PR target/89903
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p):
Return false for variable DImode shifts.
(dimode_scalar_chain::compute_convert_gain): Do not handle
register count operand in variable DImode shifts.
(dimode_scalar_chain::make_vector_copies): Remove support to copy
count argument of a variable shift instruction to a vector register.
(dimode_scalar_chain::convert_reg): Remove support to convert
count argument of a variable shift instruction.

testsuite/ChangeLog:

PR target/89902
PR target/89903
* gcc.target/i386/pr70799-4.c: Remove.
* gcc.target/i386/pr70799-5.c: Remove.
* gcc.target/i386/pr89902.c: New test.
* gcc.target/i386/pr89903.c: Ditto.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89902.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89903.c
Removed:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr70799-4.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr70799-5.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/89902] ICE: in extract_insn, at recog.c:2310: unrecognizable insn with -mavx512bitalg

2019-04-02 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89902

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  2 18:37:14 2019
New Revision: 270104

URL: https://gcc.gnu.org/viewcvs?rev=270104=gcc=rev
Log:
PR target/89902
PR target/89903
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p):
Return false for variable DImode shifts.
(dimode_scalar_chain::compute_convert_gain): Do not handle
register count operand in variable DImode shifts.
(dimode_scalar_chain::make_vector_copies): Remove support to copy
count argument of a variable shift instruction to a vector register.
(dimode_scalar_chain::convert_reg): Remove support to convert
count argument of a variable shift instruction.

testsuite/ChangeLog:

PR target/89902
PR target/89903
* gcc.target/i386/pr70799-4.c: Remove.
* gcc.target/i386/pr70799-5.c: Remove.
* gcc.target/i386/pr89902.c: New test.
* gcc.target/i386/pr89903.c: Ditto.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89902.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89903.c
Removed:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr70799-4.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr70799-5.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c/89932] New: ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824

2019-04-02 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89932

Bug ID: 89932
   Summary: ICE in must_pass_in_stack_var_size_or_pad, at
calls.c:5824
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-4.1 :


$ cat z1.c
enum bool a ();
unsigned a () {}


$ gcc-9-20190331 -c z1.c
z1.c: In function 'a':
z1.c:2:1: internal compiler error: Segmentation fault
2 | unsigned a () {}
  | ^~~~
0xa748df crash_signal
../../gcc/toplev.c:326
0x6b1f2e must_pass_in_stack_var_size_or_pad(machine_mode, tree_node const*)
../../gcc/calls.c:5824
0xd123bf ix86_must_pass_in_stack
../../gcc/config/i386/i386.c:7065
0xd269cc classify_argument
../../gcc/config/i386/i386.c:7668
0xd2756a examine_argument
../../gcc/config/i386/i386.c:8061
0xd359ef ix86_return_in_memory
../../gcc/config/i386/i386.c:9437
0x80769f aggregate_value_p(tree_node const*, tree_node const*)
../../gcc/function.c:2109
0x809454 allocate_struct_function(tree_node*, bool)
../../gcc/function.c:4762
0x5ddc3f store_parm_decls()
../../gcc/c/c-decl.c:9527
0x61e879 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2318
0x623a53 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x624519 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x624519 c_parse_file()
../../gcc/c/c-parser.c:19854
0x66ba20 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #14 from Dominique d'Humieres  ---
> Note that r270046 introduced the same thing into gcc 8.

Yes, and r270047 into gcc 7.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

2019-04-02 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904

--- Comment #13 from seurer at gcc dot gnu.org ---
Note that r270046 introduced the same thing into gcc 8.

[Bug lto/88643] -Wl,--wrap not supported with LTO

2019-04-02 Thread dilyan.palauzov at aegee dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

--- Comment #7 from Дилян Палаузов  ---
As noted at https://sourceware.org/bugzilla/show_bug.cgi?id=24406 this does
work with clang+gold and clang+lld, but not with clang+bfd.

As this does not work with gcc+gold, the problem is not in the linker.

[Bug translation/80055] do not mark internal compiler error messages for i18n

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

--- Comment #9 from Roland Illig  ---
(In reply to Frederic Marchal from comment #8)
> Two years later, I appear to be the only active translator. I translated all
> the messages. So, cutting down the number of messages is not an issue I feel
> overly concerned with :-)

I'm still there as the second active translator.

I took a different strategy of translating the internal errors. I just prefixed
each of them with "Interner Compilerfehler: " and then took the English text
verbatim. I still think this is the best strategy since it provides a bit of
information to the compiler user in their language, and provides the GCC
developers with the original error message that can be quickly found in the
source code.

I never actually checked to see how these messages look like in practice. Is
there a hidden command line option --force-internal-compiler-error somewhere?
It should be quite hard to produce an ICE in any other way.

If the prefix would now be doubled, I could as well remove it from all the
"translated" German messages.

[Bug c++/89931] New: Incorrect compiler error with temporary object used as function arguments

2019-04-02 Thread dchneric at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89931

Bug ID: 89931
   Summary: Incorrect compiler error with temporary object used as
function arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dchneric at gmail dot com
  Target Milestone: ---

Created attachment 46076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46076=edit
zip package including source and temp files

The following code

---
#include 

void foo(const char**) { std::cout << "do something"; }

int main() {
using argT = const char*[];
foo(argT{"a", "b"});

return 0;
}
---

errors out due to following error:

---
main.cpp:7:9: error: taking address of temporary array
 foo(argT{"a", "b"});
---

However, at line 7, adding std::move before invoking foo(), i.e.:

---
foo(std::move(argT{"a", "b"}));
---

suppresses the error.

Other compilers like MSVC, ICC, Clang does not have this issue.

---

VERSION & SYSTEM:

gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
Target: x86_64-linux-gnu
Thread model: posix


INSTALL CMD:

apt-get install


COMPILATION FAILURE DETAIL:

% gcc -Wall -Wextra main.cpp -o a.out
main.cpp: In function  int main() :
main.cpp:7:9: error: taking address of temporary array
 foo(argT{"a", "b"});
 ^~

MORE INFO:

https://stackoverflow.com/questions/55463861/why-does-passing-a-temporary-object-as-an-argument-need-stdmove

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

2019-04-02 Thread timshen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #1 from Tim Shen  ---
In the example, by
  std::regex(match_name_regex_string, "i");
did you mean
  std::regex_match(
  "i",
  std::regex(match_name_regex_string));
?

The former is UB because match_name_regex_string and "i" form an invalid range
of two const char*.

[Bug lto/89930] - -Wl,--wrap= incompatible with -flto

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug lto/88643] -Wl,--wrap not supported with LTO

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

--- Comment #6 from Andrew Pinski  ---
*** Bug 89930 has been marked as a duplicate of this bug. ***

[Bug target/89903] [9 Regression] ICE: in convert_op, at config/i386/i386.c:2102 with -O2 -march=skylake

2019-04-02 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89903

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  2 17:05:59 2019
New Revision: 270102

URL: https://gcc.gnu.org/viewcvs?rev=270102=gcc=rev
Log:
PR target/89902
PR target/89903
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p):
Return false for variable DImode shifts.
(dimode_scalar_chain::compute_convert_gain): Do not handle
register count operand in variable DImode shifts.
(dimode_scalar_chain::make_vector_copies): Remove support to copy
count argument of a variable shift instruction to a vector register.
(dimode_scalar_chain::convert_reg): Remove support to convert
count argument of a variable shift instruction.

testsuite/ChangeLog:

PR target/89902
PR target/89903
* gcc.target/i386/pr70799-4.c: Remove.
* gcc.target/i386/pr70799-5.c: Remove.
* gcc.target/i386/pr89902.c: New test.
* gcc.target/i386/pr89903.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr89902.c
trunk/gcc/testsuite/gcc.target/i386/pr89903.c
Removed:
trunk/gcc/testsuite/gcc.target/i386/pr70799-4.c
trunk/gcc/testsuite/gcc.target/i386/pr70799-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89902] ICE: in extract_insn, at recog.c:2310: unrecognizable insn with -mavx512bitalg

2019-04-02 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89902

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  2 17:05:59 2019
New Revision: 270102

URL: https://gcc.gnu.org/viewcvs?rev=270102=gcc=rev
Log:
PR target/89902
PR target/89903
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p):
Return false for variable DImode shifts.
(dimode_scalar_chain::compute_convert_gain): Do not handle
register count operand in variable DImode shifts.
(dimode_scalar_chain::make_vector_copies): Remove support to copy
count argument of a variable shift instruction to a vector register.
(dimode_scalar_chain::convert_reg): Remove support to convert
count argument of a variable shift instruction.

testsuite/ChangeLog:

PR target/89902
PR target/89903
* gcc.target/i386/pr70799-4.c: Remove.
* gcc.target/i386/pr70799-5.c: Remove.
* gcc.target/i386/pr89902.c: New test.
* gcc.target/i386/pr89903.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr89902.c
trunk/gcc/testsuite/gcc.target/i386/pr89903.c
Removed:
trunk/gcc/testsuite/gcc.target/i386/pr70799-4.c
trunk/gcc/testsuite/gcc.target/i386/pr70799-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/89930] New: - -Wl,--wrap= incompatible with -flto

2019-04-02 Thread dilyan.palauzov at aegee dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89930

Bug ID: 89930
   Summary: - -Wl,--wrap= incompatible with -flto
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This is t.c:

#include 
#include 

ssize_t __wrap_read(int fd, void *buffer, size_t count) {
  printf("%s\n", (char*)buffer);
  return fd + count; 
}


int main() {
  int i = read(1, "abc", 5);
  printf("%i\n", i);
}


I have gcc 8.3.1 20190311, ld.bfd 2.32.51.20190319, ld.gold 1.16
2.32.51.20190319 and clang 8.0.0.

This works
clang -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc -fuse-ld=bfd  -Wl,--wrap=read t.c
gcc -fuse-ld=gold -Wl,--wrap=read t.c
clang   -fuse-ld=bfd  -Wl,--wrap=read t.c
clang   -fuse-ld=gold -Wl,--wrap=read t.c

This fails
clang -flto -fuse-ld=bfd  -Wl,--wrap=read t.c
gcc   -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc   -flto -fuse-ld=bfd  -Wl,--wrap=read t.c

Since clang+gold works, gcc+gold should also work.

See also https://sourceware.org/bugzilla/show_bug.cgi?id=24406.

[Bug c++/89929] New: __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

2019-04-02 Thread nheart at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929

Bug ID: 89929
   Summary: __attribute__((target("avx512bw"))) doesn't work on
non avx512bw systems
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheart at gmail dot com
  Target Milestone: ---

Created attachment 46075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46075=edit
testcase for attribute avx512bw

Hey,

I was trying to use function multi-versioning and it turns out that if I
specify the attribute to __attribute__((target("avx512bw"))), I get a
compilation error on non-avx512bw systems that reads:

g++ test.cpp:(
test.cpp: In function ‘_Z3fooi.resolver’:
test.cpp:1:41: error: No dispatcher found for avx512bw
 __attribute__((target("avx512bw"))) int foo(int i) {

This works fine if I specify -mavx512f in a sense that it compiles, but
dispatches to the wrong function at runtime (as it probably ignores the avx2
target in the compilation)

I change avx512bw to avx512f the program compiles correctly and at runtime
dispatches to the correct function version for my processor (avx2). The problem
doesn't occur in clang v8, not that it is relevant.

In addition, it seems that gcc recognizes this as valid syntax:

__attribute__((target("avx512bw", "avx512f")))

But actually ignores everything after the comma in target's arguments. Not sure
if I should open another bug for that. Please find a small testcase attached.

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

2019-04-02 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

--- Comment #21 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #20)
> Sometimes life can be easy.
> 
> We need to make -fzero-initialized-in-bss the default for
> gfortran.

Actually, no.  I checked with a wrong version of the compiler :-(

[Bug fortran/89646] [7/8/9 Regression] Spurious actual argument might interfere warning

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646

--- Comment #4 from Dominique d'Humieres  ---
> The warning is unconditional, but it should be easy to replace the 9 
> with some suitable option.

I meant "replace the 0".

[Bug fortran/47660] Retain warning text of -Wconversion messages when -Wconversion-extra is in effect

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
> Note that the warning
>
> i = 0._8
> 1
> Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at 
> (1)
>
> is no longer issued with 5.0.

I meant with -Wconversion.

From the manual

> -Wconversion
> Warn about implicit conversions that are likely to change the value 
> of the expression after conversion. Implied by -Wall.
>
> -Wconversion-extra
> Warn about implicit conversions between different types and kinds.
> This option does not imply -Wconversion.

IMO the different warnings for the two options make sense. Without feedback
I'll close the PR as WONTFIX.

[Bug fortran/68649] [7/8/9 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #27 from Dominique d'Humieres  ---
See pr68717 comment 11, closing.

[Bug libfortran/77278] Use LTO for libgfortran

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
Bug 77278 depends on bug 68649, which changed state.

Bug 68649 Summary: [7/8/9 Regression] note: code may be misoptimized unless 
-fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649

   What|Removed |Added

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

[Bug fortran/68717] [7/8/9 Regression] New (bogus?) warnings when compiling some gfortran.dg tests with -flto after r231239

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #11 from Dominique d'Humieres  ---
The warnings are gone on trunk (9.0) and nobody care to answer my question in
comment 10, closing.

[Bug fortran/80174] [meta-bug] Fortran lto issues

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80174
Bug 80174 depends on bug 68717, which changed state.

Bug 68717 Summary: [7/8/9 Regression] New (bogus?) warnings when compiling some 
gfortran.dg tests with -flto after r231239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717

   What|Removed |Added

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

[Bug libfortran/77278] Use LTO for libgfortran

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
Bug 77278 depends on bug 68717, which changed state.

Bug 68717 Summary: [7/8/9 Regression] New (bogus?) warnings when compiling some 
gfortran.dg tests with -flto after r231239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717

   What|Removed |Added

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

[Bug rtl-optimization/84206] ICE in get_all_loop_exits, at sel-sched-ir.h:1138

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
Fixed.

[Bug rtl-optimization/85876] ICE in move_op_ascend, at sel-sched.c:6164

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

--- Comment #3 from Alexander Monakov  ---
Fixed.

[Bug rtl-optimization/84206] ICE in get_all_loop_exits, at sel-sched-ir.h:1138

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

--- Comment #2 from Alexander Monakov  ---
Author: amonakov
Date: Tue Apr  2 15:45:57 2019
New Revision: 270096

URL: https://gcc.gnu.org/viewcvs?rev=270096=gcc=rev
Log:
sel-sched: skip outer loop in get_all_loop_exits (PR 84206)

2019-04-02  Andrey Belevantsev  

PR rtl-optimization/84206
* sel-sched-ir.h (get_all_loop_exits): Avoid the outer loop when
iterating over loop headers.

* gcc.dg/pr84206.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr84206.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.h
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85876] ICE in move_op_ascend, at sel-sched.c:6164

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

--- Comment #2 from Alexander Monakov  ---
Author: amonakov
Date: Tue Apr  2 15:39:22 2019
New Revision: 270095

URL: https://gcc.gnu.org/viewcvs?rev=270095=gcc=rev
Log:
sel-sched: fixup reset of first_insn (PR 85876)

2019-04-02  Andrey Belevantsev  

PR rtl-optimization/85876
* sel-sched.c (code_motion_path_driver): Avoid unwinding first_insn
beyond the original fence.

* gcc.dg/pr85876.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr85876.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug translation/80055] do not mark internal compiler error messages for i18n

2019-04-02 Thread fmarchal at perso dot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055

--- Comment #8 from Frederic Marchal  ---
Two years later, I appear to be the only active translator. I translated all
the messages. So, cutting down the number of messages is not an issue I feel
overly concerned with :-)

Removing the internal error translations means more work for you. Will it
benefit gcc and attract more translators? I doubt it. 13k messages is pretty
daunting. Shortening it by several hundred messages will not help much. You can
certainly spend your time on a more productive task.

Unless fellow translators show up and challenge my opinion, I believe you can
close this bug or postpone it.

As the one doing the job, the decision is entirely up to you :-)

[Bug c++/89928] [8 Regression] errors out in c++17 mode

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

--- Comment #2 from Jonathan Wakely  ---
dup of PR 89906?

[Bug c++/89919] internal compiler error when building MKL-DNN

2019-04-02 Thread roman.s.dubtsov at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89919

--- Comment #4 from Roman Dubtsov  ---
@Martin: I'm not sure how useful this info after bisection has been done, but
FWIW 8.1.0 ICEs and and 7.4.0 does not.

[Bug fortran/89925] [9 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.4.1, 8.3.1
   Keywords||wrong-code
   Last reconfirmed||2019-04-02
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[8,9 Regression] Wrong  |[9 Regression] Wrong array
   |array bounds from ALLOCATE  |bounds from ALLOCATE with
   |with MOLD   |SOURCE or MOLD
  Known to fail||9.0

--- Comment #1 from Dominique d'Humieres  ---
I don't see the problem in my latest GCC8 (r270042) and my bisection points to
r265212 (pr67125).

I also see the problem with SOURCE.

[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm

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

--- Comment #34 from Segher Boessenkool  ---
(In reply to rguent...@suse.de from comment #33)
> On Sat, 30 Mar 2019, segher at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
> > 
> > --- Comment #32 from Segher Boessenkool  ---
> > Historically, a local register asm variable *does* live in that variable
> > for its entire scope.  This stopped working correctly, even with the many
> > caveats there were for it, and many years ago the manual added language
> > saying that only using such a var in an extended asm in or out is supported,
> > and there was language warning you to keep the life time short, etc.
> > 
> > This did *not* change the implementation.  Any other use still is explicitly
> > unsupported, and all such testcases are invalid code.
> 
> Hmm, but that means the only effect of a local reg var would be
> implicit input/output constraints, right?

Explicit.  Yes.  That is the documented only supported use.  But it is not
currently the only thing it *does*.

> Of course there's also
> calls(?) that would need to remat all local register vars.
> 
> The asm part could be easily represented on GIMPLE by making those
> constraints explicit.  The call issue would need explicit save/restore
> code which is then exposed to optimization passes.
> 
> But then...
> 
> > It would be nice if GCC was changed such that such vars were expanded to a
> > pseudo like any other var, and copies to/from a hard reg just around the 
> > asm.
> > Gimple doesn't need to do *anything* for that, just keep track that the var
> > is declared as local register var, and the gimple it had now at expand is
> > just fine:
> 
> ... all this could be done at RTL expansion time as well.

Yes, exactly.  Gimple could treat local register cars just like any other
pseudo.  Then at expand time, you copy it into its hard reg right before an
asm, and back out after it (maybe skip either if the var is not an input resp.
an output of the asm), and everything remat and lifetime etc. will work out
automatically.  Unless I am missing something.

But this is *not* what we currently do, and it is not what is documented, and
as far as I can see the testcase here is invalid code.

> Still in GIMPLE we'd have to treat calls at modifying/using
> local reg vars?  That leaves us with forcing of virtual operands
> on all calls eventually using those vars.

I think it will all work out fine without treating local register var any
different from any other local variable.

[Bug c++/89928] [8 Regression] errors out in c++17 mode

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89928

--- Comment #1 from Matthias Klose  ---
$ cat main.ii
template  class> struct a;
template  class T1> struct b { a c; };
template  class F> struct d;
template  class F> struct d;

$ g++ -std=c++17 main.ii
main.ii:3:66: error: template parameter 'template
class F'
 template  class F> struct d;
  ^
main.ii:4:76: error: redeclared here as 'template
class F'
 template  class F> struct d;
^

[Bug c++/89928] New: [8 Regression] errors out in c++17 mode

2019-04-02 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89928

Bug ID: 89928
   Summary: [8 Regression] errors out in c++17 mode
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

Created attachment 46074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46074=edit
preprocessed source

[forwarded from https://bugs.debian.org/926234]

fails with r269936 on the gcc-8-branch, succeeds with the 8.3.0 release.

g++ -std=c++17 main.cpp

but works with

g++ -std=c++14 main.cpp

currently reducing ...

[Bug libstdc++/89927] New: Inconsistent behavior in std::regex when optimized

2019-04-02 Thread xonar.leroux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

Bug ID: 89927
   Summary: Inconsistent behavior in std::regex when optimized
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xonar.leroux at gmail dot com
  Target Milestone: ---

Created attachment 46073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46073=edit
Minimal case that triggers the bug

Compiling with: `g++ test.cpp` and running results in no exception as expected.

Compiling with `g++ -O3 test.cpp` and running  results in

terminate called after throwing an instance of 'std::regex_error'
  what():  Unexpected token in brace expression.

Compiling with `clang++ -fsanitize=undefined test.cpp` and running 

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/regex_compiler.h:200:40:
runtime error: addition of unsigned offset to 0x5581d2265f61 overflowed to
0x5581d2264b15
terminate called after throwing an instance of 'std::regex_error'
  what():  Unexpected token in brace expression.

I am using the latest g++, libstdc++11 and clang++ versions from Arch Linux
(2019 April 2).

GCC Version:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)

[Bug c/89926] New: -Wmain warning about return type doesn't show location of the return type

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

Bug ID: 89926
   Summary: -Wmain warning about return type doesn't show location
of the return type
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As I observed in bug 83797 comment 4, this location looks wrong:

vm.c:1:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
 void main() { }
  ^~~~

I would expect:

vm.cc:1:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
 void main() { }
 ^~~~

[Bug c++/83797] Inconsistent error messages for main

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> FWIW the C front-end highlights the function name not the return type:
> 
> vm.c:1:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
>  void main() { }
>   ^~~~

Which is now PR 89926

[Bug c++/69289] Compiling without --profile-generate causes longer execution time (-O3)

2019-04-02 Thread xonar.leroux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69289

--- Comment #5 from Paul le roux  ---
On the GCC trunk version on godbolt.org there is still a difference between the
two cases, but it seems to have turned around. The noprofile case has
vector::resize partially inlined and in the profile case, it is not inlined.

This makes more sense (to me at least) since I expect that certain functions
won't be inlined so that one can gather better profile information. If it is
the case that `--profile-generate` should be less aggressive when inlining then
this bug report can be closed.

[Bug fortran/89925] New: [8,9 Regression] Wrong array bounds from ALLOCATE with MOLD

2019-04-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925

Bug ID: 89925
   Summary: [8,9 Regression] Wrong array bounds from ALLOCATE with
MOLD
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

My colleague passed this example on to me to report. This runs correctly with a
8.2.1 and 9 from Sept, but fails with the current 8 and 9 versions. I believe
it may be a result of the same bad commit(s) that caused PR89174 which I
reported. This example and the one from the other PR originate from the same
code.

module arraytest
  use, intrinsic :: iso_fortran_env
contains
  subroutine allocarray(moldarray)
real(real64), contiguous, intent(in) :: moldarray(0:,0:,0:)
real(real64), allocatable :: array(:,:,:)
integer :: lb1(3),lb2(3)

allocate(array,mold=moldarray)
lb1 = lbound(moldarray)
lb2 = lbound(array)
if (lb1(1).ne.lb2(1)) write(*,*) "ERROR"
  end subroutine
end module

program test
  use arraytest

  real(real64), allocatable, target :: array(:,:,:)
  allocate(array(5,5,5))
  call allocarray(array)
end program

[Bug c++/81171] Segfault with auto template deduction

2019-04-02 Thread xonar.leroux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81171

Paul le roux  changed:

   What|Removed |Added

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

--- Comment #2 from Paul le roux  ---
This has been fixed somewhere between when this was reported and 8.2.1 which I
am currently using.

[Bug tree-optimization/89924] New: [missed-optimization] Function not de-virtualized within the same TU

2019-04-02 Thread eyalroz at technion dot ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924

Bug ID: 89924
   Summary: [missed-optimization] Function not de-virtualized
within the same TU
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Related StackOverflow question: https://stackoverflow.com/q/55464578/1593077
GodBolt example: https://godbolt.org/z/l0vdFG

In the following code:

  struct A {
  virtual A& operator+=(const A& other) noexcept = 0;
  };

  void foo_inner(int *p) noexcept { *p += *p; }
  void foo_virtual_inner(A *p) noexcept { *p += *p; }

  void foo(int *p) noexcept
  {
  return foo_inner(p);
  } 

  struct Aint : public A {
  int i;
  A& operator+=(const A& other) noexcept override final
  { 
  i += dynamic_cast(other).i; 
  //  i += reinterpret_cast(other).i; 
  return *this;
  }
  };

   void foo_virtual(Aint *p) noexcept
   {
   return foo_virtual_inner(p);
   }

Both functions, `foo()` and `foo_virtual()`, should compile to the same thing.
But g++ 8.3 (on x86_64) with -O3 produces:
```
foo(int*):
sal DWORD PTR [rdi]
ret
foo_virtual(Aint*):
mov rax, QWORD PTR [rdi]
mov rax, QWORD PTR [rax]
cmp rax, OFFSET FLAT:Aint::operator+=(A const&)
jne .L19
pushrbx
xor ecx, ecx
mov edx, OFFSET FLAT:typeinfo for Aint
mov esi, OFFSET FLAT:typeinfo for A
mov rbx, rdi
call__dynamic_cast
testrax, rax
je  .L20
mov eax, DWORD PTR [rax+8]
add DWORD PTR [rbx+8], eax
pop rbx
ret
.L19:
mov rsi, rdi
jmp rax
foo_virtual(Aint*) [clone .cold.1]:
.L20:
call__cxa_bad_cast
```
i.e. it doesn't manage to de-virtualize `Aint::operator+=` - although it really
should. It has all the necessary information, as far as I can tell.

As a side note, even regardless of de-virtualization, there's a whole lot of
code there, while with with clang 8, we only get:
```
foo_virtual(Aint*):  # @foo_virtual(Aint*)
mov rax, qword ptr [rdi]
mov rax, qword ptr [rax]
mov rsi, rdi
jmp rax 
```
which at least doesn't need the type info.

[Bug c++/89914] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

2019-04-02 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89914

--- Comment #3 from Paolo Carlini  ---
This is what I meant in code. Passes testing.

Index: semantics.c
===
--- semantics.c (revision 270062)
+++ semantics.c (working copy)
@@ -9548,8 +9548,8 @@ classtype_has_nothrow_assign_or_copy_p (tree type,
   if (copy_fn_p (fn) > 0)
{
  saw_copy = true;
- maybe_instantiate_noexcept (fn);
- if (!TYPE_NOTHROW_P (TREE_TYPE (fn)))
+ if (maybe_instantiate_noexcept (fn)
+ && !TYPE_NOTHROW_P (TREE_TYPE (fn)))
return false;
}
 }
@@ -9591,8 +9591,8 @@ trait_expr_value (cp_trait_kind kind, tree type1,
   return (trait_expr_value (CPTK_HAS_TRIVIAL_CONSTRUCTOR, type1, type2) 
  || (CLASS_TYPE_P (type1)
  && (t = locate_ctor (type1))
- && (maybe_instantiate_noexcept (t),
- TYPE_NOTHROW_P (TREE_TYPE (t);
+ && maybe_instantiate_noexcept (t)
+ && TYPE_NOTHROW_P (TREE_TYPE (t;

 case CPTK_HAS_TRIVIAL_CONSTRUCTOR:
   type1 = strip_array_types (type1);

[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Valentine from comment #3)
> I'm experiencing a very similar problem. Is that a problem with gcc 8 and
> later?

Yes, as stated in the summary and comment 0.

[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error

2019-04-02 Thread v at vsamko dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89596

Valentine  changed:

   What|Removed |Added

 CC||v at vsamko dot com

--- Comment #3 from Valentine  ---
I'm experiencing a very similar problem. Is that a problem with gcc 8 and
later?

[Bug other/55930] [7/8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking

2019-04-02 Thread richard.purdie at linuxfoundation dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930

--- Comment #9 from Richard Purdie  
---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Richard Purdie from comment #6)
> > Its part of a Yocto Project build and we would only ever build it once so we
> > don't need/want the overhead of the dependency tracking information.
> 
> But is there any noticeable overhead when using GCC to bootstrap?
> 
> Automake documents the option as:
> 
>   Some compilers do not offer any practical way to derive the list of
>   dependencies as a side-effect of the compilation, requiring a separate
>   run (maybe of another tool) to compute these dependencies. The performance
>   penalty implied by these methods is important enough to disable them by
>   default.
> 
> That doesn't apply here though, because GCC is generating the dependencies
> via -MD as a side effect of compilation. So there should be no need to use
> the option (other than saving a bit of disk space during the build).

We pass this option in globally to anything using automake so whilst for one
piece of software it might not be a huge gain, over a complete Linux stack
built from source the disk space (lack of IO) speed wins are useful alone.

[Bug fortran/89890] Memory leak from a function returning a subtype

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89890

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from GCC6 up to trunk (9.0) for the test in comment 3. The culprit
seems to be

   ALLOCATE(w, SOURCE=z%new())

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9 Regression] G++ gives  |[8 Regression] G++ gives
   |cryptic error instead of|cryptic error instead of
   |incomplete type |incomplete type

--- Comment #7 from Jonathan Wakely  ---
This is fixed on trunk now, but still needs to be backported to gcc-8-branch.

[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

2019-04-02 Thread kangshan0910 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893

--- Comment #9 from 康 珊  ---
That's great! Thank you very much for your support :)

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
Here's a silly example which works with GCC 8 but fails with current trunk:

#include 

struct S {
  S(int) : a() { }
  char a[8192 * 1024];
};

int main() {
  auto& v = *new std::variant;
  v.emplace(1);
  S  = std::get<1>(v);
  return s.a[0];
}

This blows my shell's default 8kb stack limit, because of the temporary that
gets created on the stack.

We could revert to having never-valueless depend on (is_scalar_v<_Types>&&...)
or keep depending on is_trivially_copyable but also check that all the
alternative types are smaller than some limit like 512 bytes.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #7 from Iain Buclaw  ---
>> Ignoring the test results, multilib handling seems to be working well for you
>> then?
>
> It does indeed, thanks.  Not having tested Solaris/SPARC yet doesn't
> matter: I don't expect any fundamental issues there, given that things
> work fine on Solaris/x86 and Linux/x86_64.

Ah, I forgot: there's one cosmetic issue left: currently the unittests
are called something like

PASS: ../libdruntime/core/atomic.d -fversion=Shared -shared-libphobos (test for
excess errors)

or

PASS: ../src/std/algorithm/comparison.d -fversion=Shared -shared-libphobos
(test for excess errors)

while they are supposed to be called starting with the directory they
live in: e.g.

libphobos.druntime/core/atomic.d (or libphobos.druntime/core.atomic.d or
some such)

and

libphobos.phobos/src/std/algorithm/comparison.d (or maybe
libphobos.phobos/std.algorithm.comparison.d)

instead.

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

2019-04-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567

--- Comment #7 from Dominique d'Humieres  ---
For the record, the tests in comment 1 compile without ICE since GCC6.

Unless someone beats me, I am planning to package the patch in comment 4 and
submit it to the mailing lists.

[Bug c++/89923] printf format check and char8_t

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

--- Comment #1 from Jonathan Wakely  ---
Especially as the C++2a change breaks previously valid code:

printf("%s\n", u8"");

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Iain Buclaw  ---
> Ignoring the test results, multilib handling seems to be working well for you
> then?

It does indeed, thanks.  Not having tested Solaris/SPARC yet doesn't
matter: I don't expect any fundamental issues there, given that things
work fine on Solaris/x86 and Linux/x86_64.

> I can create individual PRs for each failure later.

That would be nice: certainly easier to track than within one large PR
with many unrelated issues.

  1   2   >