[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

2017-03-25 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670

--- Comment #3 from Jerry DeLisle  ---
With latest patches on trunk, I get this:

$ ./a.out 
Got ' '
Got '='
At line 72 of file pr78670.f03
Fortran runtime error: End of file

A minor problem with the test case is

IF (ch /= '') THEN

should be

IF (ch /= ' ') THEN

Still investigating.

[Bug c++/80194] New: ICE with local constant referenced by a lambda expression

2017-03-25 Thread curlypaul924 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80194

Bug ID: 80194
   Summary: ICE with local constant referenced by a lambda
expression
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: curlypaul924 at gmail dot com
  Target Milestone: ---

The following causes an ICE on g++ 5.4.0 and on the latest gcc-5-branch.  It
does not ICE on 6.0 or later.

int fn1();

template  void fn2(Fn &) {
  fn(42);
}

void fn2() {
  auto const x = fn1();
  fn2([&](auto) { x; });
}

Building with -std=c++14, the output is:

test.cpp: In instantiation of ‘fn2():: [with auto:1 = int]’:
test.cpp:4:5:   required from ‘void fn2(Fn&&) [with Fn =
fn2()::]’
test.cpp:9:23:   required from here
test.cpp:9:19: internal compiler error: Segmentation fault
   fn2([&](auto) { x; });
   ^
0xaab7ff crash_signal
../.././gcc/toplev.c:383
0x70ac4c maybe_constant_init(tree_node*, tree_node*)
../.././gcc/cp/constexpr.c:4097
0x6320bf tsubst_copy
../.././gcc/cp/pt.c:13180
0x622c68 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:15797
0x62b392 tsubst_expr
../.././gcc/cp/pt.c:14606
0x62a4f6 tsubst_expr
../.././gcc/cp/pt.c:14017
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62a09d instantiate_decl(tree_node*, int, bool)
../.././gcc/cp/pt.c:20675
0x6597d2 mark_used(tree_node*, int)
../.././gcc/cp/decl2.c:5122
0x5f889b build_over_call
../.././gcc/cp/call.c:7545
0x5fafd1 build_op_call_1
../.././gcc/cp/call.c:4347
0x5fafd1 build_op_call(tree_node*, vec**, int)
../.././gcc/cp/call.c:4370
0x6c3118 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../.././gcc/cp/semantics.c:2426
0x624d46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:15434
0x62b392 tsubst_expr
../.././gcc/cp/pt.c:14606
0x62a4f6 tsubst_expr
../.././gcc/cp/pt.c:14017
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62a09d instantiate_decl(tree_node*, int, bool)
../.././gcc/cp/pt.c:20675
0x63edeb instantiate_pending_templates(int)
../.././gcc/cp/pt.c:20792
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Output of g++ -v:

Using built-in specs.
COLLECT_GCC=/home/pbrannan/opt/gcc-5-branch/bin/g++
COLLECT_LTO_WRAPPER=/home/pbrannan/opt/gcc-5-branch/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --disable-multilib
--prefix=/home/pbrannan/opt/gcc-5-branch : (reconfigured) ./configure
--disable-multilib --prefix=/home/pbrannan/opt/gcc-5-branch
--enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 5.4.1 20170326 (GCC)

[Bug objc/80192] arguments to check_protocols should be marked as translateable

2017-03-25 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80192

--- Comment #1 from Andrew Pinski  ---
This is another keyword case IIRC.

[Bug rtl-optimization/80193] New: ICE on valid (but hairy) C code at -O3 on x86_64-linux-gnu: in check_allocation, at ira.c:2563

2017-03-25 Thread su at cs dot ucdavis.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80193

Bug ID: 80193
   Summary: ICE on valid (but hairy) C code at -O3 on
x86_64-linux-gnu: in check_allocation, at ira.c:2563
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression and has been difficult to reduce further.
The code is complex, but valid nonetheless. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170325 (experimental) [trunk revision 246473] (GCC)
$
$ gcc-trunk -O2 small.c
$
$ gcc-trunk -O3 small.c
bad allocation for 386 and 522
small.c: In function ‘bf’:
small.c:187:1: internal compiler error: in check_allocation, at ira.c:2563
 }
 ^
0xa4f86c check_allocation
../../gcc-source-trunk/gcc/ira.c:2563
0xa4f86c ira
../../gcc-source-trunk/gcc/ira.c:5374
0xa4f86c execute
../../gcc-source-trunk/gcc/ira.c:5592
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


---


int printf (const char *, ...);

char a, e, h, ag, ak, am, ar, ay, az, bc, bd, k, l;
int f, i, n, o, c, ac, ad, p, ah, s, aj, al, an, b, ao, aq, at, av, be, t, u,
g, q, r, ai, **aa, ap;

int d (int v)
{ 
  return v + a;
}

int j (char v, char w)
{ 
  return v - w;
}

void m (int p)
{
}

static void bf ()
{ 
  int bg[240], bi, bk, bl, bj, bm = -1;
  const int *bh;
  if (h)
{ 
  int bn, bo;
  while (1)
{ 
  int *bp = 
  const int **bq = , **br = bq;
  while (av)
while (ah)
  ;
  int bs = r, bt;
  if (bt)
break;
bu:
  for (; r; r = d (r))
{ 
  *bp = j (q && b, 0);
  if (n)
u = b;
  if (u && ak)
p = 0;
}
  if (c)
{ 
  while (a)
while (r)
  { 
int bw = ar, bx = an;
  by:
printf ("%d\n", an);
while (ao)
  while (bw)
{ 
  a = !g || f / g;
  if (i)
az = i;
  l = j (q && bh, 5);
  if (n != 0)
t = l / n;
  if (t)
while (bo)
  ;
}
while (a)
  ;
if (s)
  while (bx)
while (1)
  { 
if (r)
  break;
*aa || q;
  }
while (at)
  ;
  }
  while (av)
if (b)
  goto by;
  while (bl)
while (1)
  { 
if (r)
  break;
while (ag)
  if (bi)
printf ("%d\n", 0);
if (bk)
  { 
bo = bn = bi = printf ("");
goto bz;
  }
while (o)
  if (a)
{ 
  while (1)
;
ca:
  ;
}
if (ap)
  while (1)
;
while (a)
  { 
if (ai)
  {
  bz:
while (be)
  if (a)
while (bn)
  bl = bg[am];
while (ac)
  if (ad)
{ 
  bj++;
  while (bj)
if (c)
  goto bu;

[Bug objc/80192] New: arguments to check_protocols should be marked as translateable

2017-03-25 Thread roland.illig at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80192

Bug ID: 80192
   Summary: arguments to check_protocols should be marked as
translateable
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from objc-act.c:

warning (0, "%s %qE does not fully implement the %qE protocol",
 type, name, PROTOCOL_NAME (p));

The placeholder %s either gets the string "class" or "category". These words
should be marked for translation by surrounding them with _(...).

[Bug c++/80191] New: diagnostic placeholder "new initializer" must be marked for translation

2017-03-25 Thread roland.illig at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80191

Bug ID: 80191
   Summary: diagnostic placeholder "new initializer" must be
marked for translation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from cp/typeck.c:

permerror (input_location,
   "%s expression list treated as compound expression",
   msg);

The placeholder "msg" gets the value "new initializer" in init.c, but that
string literal is not enclosed in _(...), therefore it won't be translated.

That call seems to be the only place where build_x_compound_expr_from_vec is
actually called, so having a placeholder might be unnecessary overhead.

[Bug target/80190] New: darwin: untranslateable placeholder "non-ASCII character"

2017-03-25 Thread roland.illig at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80190

Bug ID: 80190
   Summary: darwin: untranslateable placeholder "non-ASCII
character"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from config/darwin.c:

warning (darwin_warn_nonportable_cfstrings, "%s in CFString literal",
 s[l] ? "non-ASCII character" : "embedded NUL");

When running GCC in a German locale, the placeholder %s will still be output in
English since it is not marked for translation. Both string literals must be
surrounded by _(...).

[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated

2017-03-25 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189

--- Comment #1 from Andrew Pinski  ---
IIRC these are keywords for OpenMP.

[Bug translation/80189] New: gimplify.c: check whether parallel/task/teams should be translated

2017-03-25 Thread roland.illig at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189

Bug ID: 80189
   Summary: gimplify.c: check whether parallel/task/teams should
be translated
   Product: gcc
   Version: 7.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 gimplify.c, function omp_default_clause:

const char *rtype;

if (ctx->region_type & ORT_PARALLEL)
  rtype = "parallel";
else if (ctx->region_type & ORT_TASK)
  rtype = "task";
else if (ctx->region_type & ORT_TEAMS)
  rtype = "teams";
else
  gcc_unreachable ();

error ("%qE not specified in enclosing %s",
   DECL_NAME (lang_hooks.decls.omp_report_decl (decl)), rtype);
error_at (ctx->location, "enclosing %s", rtype);

Should "rtype" be translated here? If so, the string literals must be inlined
into the diagnostic since they result in different grammar, at least in German.

If they should not be translated, they should be marked in the code as
intentionally not translated, since this code looks like an oversight.

[Bug translation/80188] New: calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

2017-03-25 Thread roland.illig at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188

Bug ID: 80188
   Summary: calls.c: reason argument to
maybe_complain_about_tail_call must be marked for
translation
   Product: gcc
   Version: 7.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 calls.c:

static void
maybe_complain_about_tail_call (tree call_expr, const char *reason)
{
  ...
  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
}

The "reason" argument must be marked for translation using N_("..."), but is
not. For example:

maybe_complain_about_tail_call (exp,
  "a callee-copied argument is"
  " stored in the current "
  " function's frame");

This means that the string "a callee-copied ..." is always given in English,
even if the rest of the diagnostic is given in German or some other language.

I don't know how to reproduce this particular diagnostic, but there should be a
test for it. When running this test in a non-English locale, the diagnostic
with mixed language will show up.

[Bug c/80182] gcc -lm -o

2017-03-25 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182

--- Comment #3 from Jonathan Wakely  ---
Related to Bug 36312

[Bug c/80182] gcc -lm -o

2017-03-25 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182

--- Comment #2 from Jonathan Wakely  ---
I think the complaint is that -o foo.c overwrites foo.c (which has nothing to
do with -lm)

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

2017-03-25 Thread koenigni at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69498

--- Comment #6 from koenigni at gcc dot gnu.org ---
> +  p = strchr(name, '.');   

s/strchr/strrchr

Also, regression tested for x86_64-pc-linux-gnu

[Bug libstdc++/80187] New: C++ variant should be trivially copy constructible if possible

2017-03-25 Thread ambrop7 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187

Bug ID: 80187
   Summary: C++ variant should be trivially copy constructible if
possible
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ambrop7 at gmail dot com
  Target Milestone: ---

Presumably because std::variant is not trivially copy constructible,
the ABI will be unable to pass it by value in a register in a call to a
non-inlined function taking the variant by value, but will have to pass it by
reference.

Test case:

#include 
struct TaggedUnion { union { int i; char c; }; int tag; };
void f1(std::variant);
void f2(TaggedUnion);
int main ()
{
f1(42);
f2({42, 0});
return 0;
}

Result on Linux x86-64: f1 is called passing the argument by address, f2 is
called passing by register.

See the standard proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0602r0.html

however I think this can be fixed in gcc regardless of when/whether the
proposal is accepted.

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

2017-03-25 Thread koenigni at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69498

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||koenigni at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |koenigni at gcc dot 
gnu.org

--- Comment #5 from koenigni at gcc dot gnu.org ---
Proposed fix for z2.f90 and z3.f90.

Index: symbol.c 
=== 
--- symbol.c(Revision 246320)   
+++ symbol.c(Arbeitskopie)  
@@ -2782,10 +2782,20 @@ void
 gfc_delete_symtree (gfc_symtree **root, const char *name)  
 {  
   gfc_symtree st, *st0;
+  const char *p;   

-  st0 = gfc_find_symtree (*root, name);
+  /* Submodules are marked as mod.submod.  When freeing a submodule
+ symbol, the symtree only has "submod", so adjust that here.  */   

-  st.name = gfc_get_string ("%s", name);   
+  p = strchr(name, '.');   
+  if (p)   
+p++;   
+  else 
+p = name;  
+   
+  st0 = gfc_find_symtree (*root, p);   
+
+  st.name = gfc_get_string ("%s", p);
   gfc_delete_bbt (root, , compare_symtree);

   free (st0);

[Bug c++/80186] New: ICE on C++ code with invalid constructor on x86_64-linux-gnu: Segmentation fault (program cc1plus)

2017-03-25 Thread su at cs dot ucdavis.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80186

Bug ID: 80186
   Summary: ICE on C++ code with invalid constructor on
x86_64-linux-gnu: Segmentation fault (program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to affect at least all versions 4.6.x and later.

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170325 (experimental) [trunk revision 246473] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp: In instantiation of ‘struct A<int, int>’:
small.cpp:10:34:   required from here
small.cpp:5:3: error: invalid constructor; you probably meant ‘A<int, int>
(const A<int, int>&)’
   A (A < T, T >);
   ^
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
$ 





template < class T, class > struct A
{
  A ();
  A (A &);
  A (A < T, T >);
};

void f () 
{
  A < int, int > (A < int, int >());
}

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

2017-03-25 Thread zeccav at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #14 from Vittorio Zecca  ---
(In reply to Dominique d'Humieres from comment #13)
> > I am still having an ICE as in comment 11.
> 
> Me too even on trunk (7.0.1)!-(I also get an ICE with the original test.)
> Reopening the PR.
> 
> > Opening a new bug.
> 
> Did you do it?

No I did not open a new bug, because it already exists as 68045.

[Bug target/80180] Incorrect codegen from rdseed intrinsic use

2017-03-25 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80180

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|--- |5.5

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

[Bug target/80180] Incorrect codegen from rdseed intrinsic use

2017-03-25 Thread uros at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80180

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Mar 25 19:47:14 2017
New Revision: 246479

URL: https://gcc.gnu.org/viewcvs?rev=246479=gcc=rev
Log:
PR target/80180
* config/i386/i386.c (ix86_expand_builtin)
: Do not expand arg0 between
flags reg setting and flags reg using instructions.
: Ditto.  Use non-flags reg
clobbering instructions to zero extend op2.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c

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

2017-03-25 Thread fmarchal at perso dot be 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055

--- Comment #5 from Frederic Marchal  ---
(In reply to David Malcolm from comment #4)
> Would this prefix be for the benefit of the user, or for translator?  (or
> both?)
>
> I believe that everywhere we're using internal_error, the diagnostics
> machinery will add "internal compiler error: " as a prefix when the message
> is emitted to the user, and I believe this prefix is translated.

The prefix was meant for the user.

Roland's suggestion was to reduce the translators workload by removing
technical messages from the translation as users aren't supposed to see them
and much less understand them.

My opinion was that it would be rude to display an untranslated message to the
user. But, to spare users some head scratching when faced with a message they
are not supposed to understand, I suggested to clearly identify such messages
as intended to the gcc development team.

If internal_error messages are already clearly identified as such, then all is
well from my point of view but you may want to argue about how unlikely it is
for a final user to ever see one internal_error.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

2017-03-25 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #14 from Jerry DeLisle  ---
Fixed on trunk, closing.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

2017-03-25 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Mar 25 18:48:01 2017
New Revision: 246478

URL: https://gcc.gnu.org/viewcvs?rev=246478=gcc=rev
Log:
2017-03-25  Jerry DeLisle  

PR libgfortran/78881
* io/io.h (st_parameter_dt): Rename unused component last_char to
child_saved_iostat. Move comment to gfc_unit.
* io/list_read.c (list_formatted_read_scalar): After call to
child READ procedure, save the returned iostat value for later
check. (finish_list_read): Only finish READ if child_saved_iostat
was OK.
* io/transfer.c (read_sf_internal): If there is a saved character
in last character, seek back one. Add a new check for EOR
condition. (read_sf): If there is a saved character
in last character, seek back one. (formatted_transfer_scalar_read):
Initialize last character before invoking child procedure.
(data_transfer_init): If child dtio, set advance
status to nonadvancing. Move update of size and check for EOR
condition to before child dtio return.

* gfortran.dg/dtio_26.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_26.f03
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/transfer.c

[Bug translation/80185] New: Message build from untranslated string concatenation in fortran/resolve.c

2017-03-25 Thread fmarchal at perso dot be 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80185

Bug ID: 80185
   Summary: Message build from untranslated string concatenation
in fortran/resolve.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In function resolve_fl_procedure() in fortran/resolve.conf, one can find this
code around line 12345 (nice line number BTW):

  /* Check the result characteristics.  */
  if (!gfc_check_result_characteristics (sym, iface, errmsg, 200))
{
  gfc_error ("%s between the MODULE PROCEDURE declaration "
 "in module %s and the declaration at %L in "
 "SUBMODULE %s", errmsg, module_name,
 >declared_at, submodule_name);
  return false;
}

The first %s is an untranslated string such as "Type mismatch in function
result (%s/%s)" or "ALLOCATABLE attribute mismatch in " among other things.

That kind of construct is impossible to translate even if errmsg were
translated.

This is going to be a real mess to fix because
gfc_check_result_characteristics() is used at several places.

[Bug target/80180] Incorrect codegen from rdseed intrinsic use

2017-03-25 Thread uros at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80180

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Mar 25 18:10:37 2017
New Revision: 246477

URL: https://gcc.gnu.org/viewcvs?rev=246477=gcc=rev
Log:
PR target/80180
* config/i386/i386.c (ix86_expand_builtin)
: Do not expand arg0 between
flags reg setting and flags reg using instructions.
: Ditto.  Use non-flags reg
clobbering instructions to zero extend op2.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c

[Bug fortran/79382] DTIO ICE

2017-03-25 Thread pault at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sat Mar 25 17:38:17 2017
New Revision: 246476

URL: https://gcc.gnu.org/viewcvs?rev=246476=gcc=rev
Log:
2017-03-25  Paul Thomas  

PR fortran/80156
PR fortran/79382
* decl.c (access_attr_decl): Remove the error for an absent
generic DTIO interface and ensure that symbol has the flavor
FL_PROCEDURE.

2017-03-25  Paul Thomas  

PR fortran/80156
PR fortran/79382
* gfortran.dg/dtio_23.f90 : Remove the dg-error and add the
testcase for PR80156. Add a main programme that tests that
the typebound generic is accessible.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_23.f90

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

2017-03-25 Thread pault at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80156

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sat Mar 25 17:38:17 2017
New Revision: 246476

URL: https://gcc.gnu.org/viewcvs?rev=246476=gcc=rev
Log:
2017-03-25  Paul Thomas  

PR fortran/80156
PR fortran/79382
* decl.c (access_attr_decl): Remove the error for an absent
generic DTIO interface and ensure that symbol has the flavor
FL_PROCEDURE.

2017-03-25  Paul Thomas  

PR fortran/80156
PR fortran/79382
* gfortran.dg/dtio_23.f90 : Remove the dg-error and add the
testcase for PR80156. Add a main programme that tests that
the typebound generic is accessible.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_23.f90

[Bug target/80180] Incorrect codegen from rdseed intrinsic use

2017-03-25 Thread uros at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80180

--- Comment #1 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Mar 25 16:34:09 2017
New Revision: 246475

URL: https://gcc.gnu.org/viewcvs?rev=246475=gcc=rev
Log:
PR target/80180
* config/i386/i386.c (ix86_expand_builtin)
: Do not expand arg0 between
flags reg setting and flags reg using instructions.
: Ditto.  Use non-flags reg
clobbering instructions to zero extend op2.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

2017-03-25 Thread asolokha at gmx dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818

--- Comment #15 from Arseny Solokha  ---
(In reply to Segher Boessenkool from comment #14)
> I cannot get any of the testcases to fail with current trunk (but
> they do fail with GCC 6).  Combine always merges the compare into
> the if_then_else pattern, and there are no such patterns in rs6000
> (this could be done with a cmp+isel define_insn_and_split, and is
> probably a good idea, but we do not have that currently).

OK, I'll post another one or two the next week. This is still reproducible on
the trunk, but the actual code pattern causing the ICE seems to be a moving
target.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

2017-03-25 Thread segher at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818

--- Comment #14 from Segher Boessenkool  ---
I cannot get any of the testcases to fail with current trunk (but
they do fail with GCC 6).  Combine always merges the compare into
the if_then_else pattern, and there are no such patterns in rs6000
(this could be done with a cmp+isel define_insn_and_split, and is
probably a good idea, but we do not have that currently).

[Bug tree-optimization/64715] [5/6/7 Regression] __builtin_object_size (..., 1) fails to locate subobject

2017-03-25 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|7.0 |8.0

[Bug tree-optimization/80181] [7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:505

2017-03-25 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80181

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-25
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242920.

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

2017-03-25 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80183

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-25
 CC||fdumont at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Started with r243379.

[Bug testsuite/80184] New: FAIL: gcc.dg/torture/pr79732.c -O* (test for excess errors) on darwin

2017-03-25 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80184

Bug ID: 80184
   Summary: FAIL: gcc.dg/torture/pr79732.c   -O*  (test for excess
errors) on darwin
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin*
Target: x86_64-apple-darwin*
 Build: x86_64-apple-darwin*

The test gcc.dg/torture/pr79732.c fails on darwin with

/opt/gcc/_clean/gcc/testsuite/gcc.dg/torture/pr79732.c:3:5: error: only weak
aliases are supported in this configuration
 int bar () __attribute__ ((alias ("foo")));
 ^~~

This can be fixed with the following patch

--- ../_clean/gcc/testsuite/gcc.dg/torture/pr79732.c2017-02-28
18:16:34.0 +0100
+++ gcc/testsuite/gcc.dg/torture/pr79732.c  2017-03-07 23:09:44.0
+0100
@@ -1,4 +1,6 @@
 /* { dg-do link } */
+/* { dg-require-weak "" } */
+/* { dg-require-alias "" } */

 int bar () __attribute__ ((alias ("foo")));
 void foo () { }

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

2017-03-25 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 49630, which changed state.

Bug 49630 Summary: [OOP] ICE on obsolescent deferred-length type bound 
character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

   What|Removed |Added

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

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

2017-03-25 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #13 from Dominique d'Humieres  ---
> I am still having an ICE as in comment 11.

Me too even on trunk (7.0.1)!-(I also get an ICE with the original test.)
Reopening the PR.

> Opening a new bug.

Did you do it?

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

2017-03-25 Thread pault at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80156

--- Comment #7 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #6)
> > I can fix this and prevent the ICE of PR79832 ...
> 
> Is this the right PR?

Well caught! PR79382.

Paul

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

2017-03-25 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80183

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 41052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41052=edit
testcase. valgrind clang-format bench.ii

[Bug c/80182] gcc -lm -o

2017-03-25 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-25
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Do you that you were getting undefined symbols when having -lm before any
object/source file? If so this is not a gcc bug (or a linker one). This is how
single pass linker work.  Note if libm is a shared library normally it would
force the linker to link to it except on Linux distros where --as-needed is
default.

[Bug libstdc++/80183] New: [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

2017-03-25 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80183

Bug ID: 80183
   Summary: [7 Regression] Conditional jump or move depends on
uninitialised value:
std::local_Rb_tree_decrement(std::_Rb_tree_node_base*)
(tree.cc:97)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Running clang-format under valgrind shows:

==69398== Conditional jump or move depends on uninitialised value(s)
==69398==at 0x42D3B08:
std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)
==69398==by 0x101B12FF:
std::_Rb_tree_const_iterator::operator--() (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B17FF:
std::reverse_iterator::operator->() const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B0597:
clang::tooling::applyAllReplacements[abi:cxx11](llvm::StringRef,
clang::tooling::Replacements const&) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101099FB: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef,
bool*)::{lambda(clang::format::TokenAnalyzer&)#1}::operator()(clang::format::TokenAnalyzer&)
const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x10109E67: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef, bool*) (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000C603: clang::format::format(llvm::StringRef) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000D1D7: main (in
/home/trippels/llvm_build/bin/clang-format)
==69398== 
==69398== Conditional jump or move depends on uninitialised value(s)
==69398==at 0x42D3B08:
std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)
==69398==by 0x101B12FF:
std::_Rb_tree_const_iterator::operator--() (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B17FF:
std::reverse_iterator::operator->() const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B05BF:
clang::tooling::applyAllReplacements[abi:cxx11](llvm::StringRef,
clang::tooling::Replacements const&) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101099FB: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef,
bool*)::{lambda(clang::format::TokenAnalyzer&)#1}::operator()(clang::format::TokenAnalyzer&)
const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x10109E67: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef, bool*) (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000C603: clang::format::format(llvm::StringRef) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000D1D7: main (in
/home/trippels/llvm_build/bin/clang-format)
==69398== 
==69398== Conditional jump or move depends on uninitialised value(s)
==69398==at 0x42D3B08:
std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)
==69398==by 0x101B12FF:
std::_Rb_tree_const_iterator::operator--() (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B17FF:
std::reverse_iterator::operator->() const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B05E7:
clang::tooling::applyAllReplacements[abi:cxx11](llvm::StringRef,
clang::tooling::Replacements const&) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101099FB: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef,
bool*)::{lambda(clang::format::TokenAnalyzer&)#1}::operator()(clang::format::TokenAnalyzer&)
const (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x10109E67: clang::format::reformat(clang::format::FormatStyle
const&, llvm::StringRef, llvm::ArrayRef,
llvm::StringRef, bool*) (in /home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000C603: clang::format::format(llvm::StringRef) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x1000D1D7: main (in
/home/trippels/llvm_build/bin/clang-format)
==69398== 
==69398== Conditional jump or move depends on uninitialised value(s)
==69398==at 0x42D3B08:
std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)
==69398==by 0x101B12FF:
std::_Rb_tree_const_iterator::operator--() (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101B06DF:
clang::tooling::applyAllReplacements[abi:cxx11](llvm::StringRef,
clang::tooling::Replacements const&) (in
/home/trippels/llvm_build/bin/clang-format)
==69398==by 0x101099FB:

[Bug c/80182] New: gcc -lm -o

2017-03-25 Thread nikhil.pinnaparaju at research dot iiit.ac.in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182

Bug ID: 80182
   Summary: gcc -lm -o
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikhil.pinnaparaju at research dot iiit.ac.in
  Target Milestone: ---

When using the command "gcc -lm -o ". When trying to link math,
using that combination of flags caused me to lose several hours of work on code
which is really frustrating. Additionally i had thought the file could have
been sent to the trash bin or made hidden but it was no where to be found.

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

2017-03-25 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80156

--- Comment #6 from Dominique d'Humieres  ---
> I can fix this and prevent the ICE of PR79832 ...

Is this the right PR?

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

2017-03-25 Thread pault at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80156

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
This, of course, is mine.

I can fix this and prevent the ICE of PR79832 but I see no way at the moment to
retain the error message of the latter.

Cheers

Paul

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-25 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #49 from Bernd Edlinger  ---
While I think that adding explicit copy/assignment constructors
as in comment #43 should work and looks like the most portable
solution for boost, I am unsure if may_alias shouldn't really
work different.

I thought of another use of may_alias that also applies to C:
Isn't the plan to add may_alias to the struct sockaddr_storage ?

And wouldn't you then expect to add a sockaddr_storage
to a structure like:

struct A
{
   struct sockaddr_storage s;
};

does'nt that mean that

A a, b;

a.s = b.s;

will also ignore the may_alias ?