[Bug pch/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Component|middle-end  |pch

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Matthias Klose from comment #5)
> you need to build and submit the report without precompiled headers. In this
> form it is not reproducible.

Well, if the segfault only happens if PCH are used, this is impossible.

[Bug middle-end/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-23
 CC||doko at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Matthias Klose  ---
you need to build and submit the report without precompiled headers. In this
form it is not reproducible.

[Bug middle-end/71622] gcc 5.3.1 crashes when it tries to compile qtbase [dev]

[thiago at kde dot org]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #4 from Thiago Macieira  ---
This happens with OpenSUSE's GCC 5.3.1 too. It does not happen with 6.1.1, so
whatever the problem was, it's been solved.

I can also confirm that the problem goes away when PCH support is disabled in
Qt. Maybe that can help the maintainers a find if there's a patch to backport
to the gcc_5_branch.

[Bug c/71627] AVR error: unable to find a register to spill in class 'POINTER_X_REGS'

[khuongnguyen00331 at gmail dot com]

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

Khuong Nguyen Tan  changed:

   What|Removed |Added

 Target||AVR
 CC||khuongnguyen00331 at gmail dot 
com
  Known to work||4.7.2
   Host||Linux Debian GNU/Linux
  Known to fail||4.9.0, 4.9.2, 5.3.0, 6.1.0
  Build||AVR

--- Comment #1 from Khuong Nguyen Tan  ---
/* { dg-do run } */

/*#include "exit-abort.h"*/
#include 
#define PROGMEM __attribute__((progmem))

const char strA[] PROGMEM = "%ld + %ld + %ld + %ld + %ld = %ld !\n";
//const char strB[] PROGMEM = "%d + %d + %d + %d + %d + %d = %ld !\n";
//const char strA[] PROGMEM = "%c + %c + %c= %c !\n";
//const char strc PROGMEM = 'c';

//volatile __memx const unsigned char s = 1, a='a',b='b',c='c';
//volatile __flash const unsigned char s = 1, a='a',b='b',c='c';
volatile __memx const long  a=24, b=26, c=50, d=23, e=40, f=43;

volatile  long result;
int main()
{
   //char result = 'e'; 
   //printf_P(strB, a, b);
   //printf_P(strC, a);
   result = a + b + c + d + e + f;
   printf_P(strA, a,b,c,d,e,f, result);

   //printf_P("\n==>%c", strc);
   //printf("\nString: %s\n", "End");
   return 0;
}

[Bug c/71627] New: AVR error: unable to find a register to spill in class 'POINTER_X_REGS'

[khuongnguyen00331 at gmail dot com]

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

Bug ID: 71627
   Summary: AVR error: unable to find a register to spill in class
'POINTER_X_REGS'
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khuongnguyen00331 at gmail dot com
  Target Milestone: ---

Created attachment 38751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38751=edit
test memx-space

avr-gcc  -mmcu=atmega128 -fdump-rtl-all -o avr.s  -O1 avr.c
avr.c: In function ‘main’:
avr.c:28:1: error: unable to find a register to spill in class ‘POINTER_X_REGS’
 }
 ^
avr.c:28:1: error: this is the insn:
(insn 108 107 109 2 (set (reg:QI 21 r21)
(subreg:QI (reg/f:PSI 61) 2)) avr.c:22 71 {movqi_insn}
 (nil))
avr.c:28: confused by earlier errors, bailing out

[Bug middle-end/49905] Better sanity checking on sprintf src & dest to produce warning for dodgy code ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
I'm working on a patch.

[Bug c/71560] union compound literal initializes wrong union field

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to vries from comment #3)

That would make sense.  Please let me know if you're planning to make these
changes, otherwise I can give it a whirl.

[Bug c/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-23
 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
Summary|ICE at -O1 and above on |[4.9/5/6/7 regression] ICE
   |x86_64-linux-gnu (in|at -O1 and above on
   |output_constant_pool_2, at  |x86_64-linux-gnu (in
   |varasm.c:3837)  |output_constant_pool_2, at
   ||varasm.c:3837)
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with r204274 (gcc 4.9.0) as the root cause:

r204274 | jakub | 2013-10-31 15:06:49 -0400 (Thu, 31 Oct 2013) | 19 lines

* optabs.c (expand_vec_perm): Avoid vector mode punning
SUBREGs in SET_DEST.
* expmed.c (store_bit_field_1): Likewise.
* config/i386/sse.md (movdi_to_sse, vec_pack_sfix_trunc_v2df,
vec_pack_sfix_v2df, vec_shl_, vec_shr_,
vec_interleave_high, vec_interleave_low): Likewise.
* config/i386/i386.c (ix86_expand_vector_move_misalign,
ix86_expand_sse_movcc, ix86_expand_int_vcond, ix86_expand_vec_perm,
ix86_expand_sse_unpack, ix86_expand_args_builtin,
ix86_expand_vector_init_duplicate, ix86_expand_vector_set,
emit_reduc_half, expand_vec_perm_blend, expand_vec_perm_pshufb,
expand_vec_perm_interleave2, expand_vec_perm_pshufb2,
expand_vec_perm_vpshufb2_vpermq,
expand_vec_perm_vpshufb2_vpermq_even_odd, expand_vec_perm_even_odd_1,
expand_vec_perm_broadcast_1, expand_vec_perm_vpshufb4_vpermq2,
ix86_expand_sse2_mulv4si3, ix86_expand_pinsr): Likewise.
(expand_vec_perm_palignr): Likewise.  Modify a copy of *d rather
than *d itself.

[Bug c/71610] Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01658.html

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01658.html

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
I'm working on a fix for the specific issue in comment #0.

[Bug c/71567] Incorrect loop optimization

[tyoma.ariv at gmail dot com]

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

--- Comment #6 from Artem  ---
(In reply to Manuel López-Ibáñez from comment #5)
> 
> Your code is still broken and it may get miscompiled with a different
> version of GCC or a different compiler or due to any changes to the
> surrounding code.

Is there any way to indicate such kind of errors during compilation.
I tried to add options -Wall -Waggressive-loop-optimizations for compilation
code from the description. But I didn't get any warnings related to "reading
one past the array bounds".
Which kind of warnings are switched on by adding
-Waggressive-loop-optimizations?

Could you please advise
Thank you
Artem

[Bug target/67400] -fno-plt doesn't work with function pointers

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jun 22 22:06:56 2016
New Revision: 237720

URL: https://gcc.gnu.org/viewcvs?rev=237720=gcc=rev
Log:
PR target/67400
* config/i386/i386-protos.h (ix86_force_load_from_GOT_p): New.
* config/i386/i386.c (ix86_force_load_from_GOT_p): New function.
(ix86_legitimate_constant_p): Do not allow UNSPEC_GOTPCREL if
ix86_force_load_from_GOT_p returns true.
(ix86_legitimate_address_p): Allow UNSPEC_GOTPCREL if
ix86_force_load_from_GOT_p returns true.
(ix86_print_operand_address_as): Support UNSPEC_GOTPCREL if
ix86_force_load_from_GOT_p returns true.
(ix86_expand_move): Load the external function address via the
GOT slot if ix86_force_load_from_GOT_p returns true.
* config/i386/predicates.md (x86_64_immediate_operand): Return
false for SYMBOL_REFs where ix86_force_load_from_GOT_p returns true.
(x86_64_zext_immediate_operand): Ditto.

testsuite/ChangeLog:

PR target/67400
* gcc.target/i386/pr67400-1.c: New test.
* gcc.target/i386/pr67400-2.c: Likewise.
* gcc.target/i386/pr67400-3.c: Likewise.
* gcc.target/i386/pr67400-4.c: Likewise.
* gcc.target/i386/pr67400-5.c: Likewise.
* gcc.target/i386/pr67400-6.c: Likewise.
* gcc.target/i386/pr67400-7.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr67400-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-3.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-4.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-5.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-6.c
trunk/gcc/testsuite/gcc.target/i386/pr67400-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Okay, I updated the Wiki.  I would have liked to have added a link to the
--help option in the manual but, unfortunately, the anchors in it change from
one release to the next.  I suppose the next best thing I could do is link to
the Overall-Options.html page where it's documented.

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Marc Glisse from comment #5)
> Though I guess a bit of redundancy in the place you suggest may indeed
> help...

It is also OK to link to the manual. See
https://gcc.gnu.org/wiki/FAQ#wnowarning

But I just realised that help=optimisers is not really the answer, given:
https://gcc.gnu.org/wiki/FAQ#optimization-flags

Would one of you care to update the answer accordingly? Thanks!

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
We already have, just above the description of -O in the manual:

"  Not all optimizations are controlled directly by a flag.  Only
   optimizations that have a flag are listed in this section.

   Most optimizations are only enabled if an -O level is set on the
   command line.  Otherwise they are disabled, even if individual
   optimization flags are specified.

   Depending on the target and how GCC was configured, a slightly
   different set of optimizations may be enabled at each -O level than
   those listed here.  You can invoke GCC with -Q --help=optimizers to
   find out the exact set of optimizations that are enabled at each level."

Though I guess a bit of redundancy in the place you suggest may indeed help...

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Manuel López-Ibáñez from comment #3)

Good idea.  Thanks.  I think it might help set the right expectation if this
detail was more succinctly mentioned in the manual itself.  For instance, under
the -O options, by changing:

  -O turns on the following optimization flags: ...

to

  -O turns on the optimization flags below.  It may also enable additional
optimizations that aren't controlled by individual flags on which the listed
optimizations depend.  As a result, the effect of -O is not the same as
specifying all of the flags on the list.

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Renlin Li from comment #0)
>   char array[] = "abc";
>   return __builtin_strlen (array);

There are DUPs for this part.

> int hallo ();
> int dummy ()
> {
>   char array[] = "abc";
>   return hallo () + __builtin_strlen (array);
> }
> 
> the __builtin_strlen is not fold into a const as in foo () above. Presumably,
> gcc is too conservative about what hallo () function can do. By adding a
> pure attribute to hallo (), gcc will generate optimal code.

Here it depends if we produce:

size_t tmp1=hallo();
size_t tmp2=strlen(array);
return tmp1+tmp2;

or use the reverse order for tmp1 and tmp2. Currently we evaluate a before b in
a+b, this example seems to suggest that when one sub-expression is pure and not
the other, it would make sense to evaluate the pure one first (assuming we can
determine that information early enough). It also depends where the C++
proposal about order of evaluation is going...

Or we could do like clang and improve alias analysis. We should know that array
doesn't escape and thus that hallo() cannot write to it.

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #1)
>   https://gcc.gnu.org/wiki/FAQ#optimization-options
> 
> Basically, -ON options are more than just aggregates of -fxxx options.  They
> may implicitly enable additional optimizations that other optimizations need
> to do their work.  (You may find the output of gcc -help=optimizers helpful
> here, though it too needs to be interpreted with the above caveat in mind.)

Hi Martin, I extended the FAQ answer to mention -help=optimizers as you did. It
is always better to extend the FAQ page (it is a wiki!) than to add this extra
info every time someone asks. The goal of this FAQ is that we can always answer
by pointing to the FAQ. If you think the answer in the FAQ is not (good)
enough, then please extend/rephrase it (it is a wiki!).

[Bug c/71626] New: ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[chengniansun at gmail dot com]

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

Bug ID: 71626
   Summary: ICE at -O1 and above on x86_64-linux-gnu (in
output_constant_pool_2, at varasm.c:3837)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a regression. gcc-4.9 also ICEs. 

$: 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.0/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.0 20160622 (experimental) [trunk revision 237712] (GCC) 
$: 
$: gcc-trunk -O1 small.c
small.c: In function ‘fn’:
small.c:5:16: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
   vllong1 v = {fn};
^~
small.c:5:16: note: (near initialization for ‘v’)
small.c: At top level:
small.c:7:1: internal compiler error: in output_constant_pool_2, at
varasm.c:3837
 }
 ^
0xea3de4 output_constant_pool_2
../../gcc-source-trunk/gcc/varasm.c:3837
0xea3e9d output_constant_pool_1
../../gcc-source-trunk/gcc/varasm.c:3909
0xeb270d output_constant_pool_contents
../../gcc-source-trunk/gcc/varasm.c:4023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: cat small.c
typedef long llong;
typedef llong vllong1 __attribute__((__vector_size__(sizeof(llong;

vllong1 fn() {
  vllong1 v = {fn};
  return v;
}

$:

[Bug c/71610] Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #2)
> I'm working on this

Considering Bug 71613, it may be better to follow Clang and make the main
location the one of the enum label.

[Bug middle-end/71625] New: missing strlen optimization on different array initialization style

[renlin at gcc dot gnu.org]

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

Bug ID: 71625
   Summary: missing strlen optimization on different array
initialization style
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renlin at gcc dot gnu.org
  Target Milestone: ---

Hi,

The following two functions shall give the same result 3.
Currently, foo () can be optimized to return a constant.
bar (), however, contains function call to strlen, which is sub-optimal.

int foo ()
{
  char array[] = "abc";
  return __builtin_strlen (array);
}

int bar ()
{
  char array[] = {'a', 'b', 'c', '\0'};
  return __builtin_strlen (array);
}


Clang 3.8 produce optimal code-generation for both cases.
In addition, I have another case here:

int hallo ();
int dummy ()
{
  char array[] = "abc";
  return hallo () + __builtin_strlen (array);
}

the __builtin_strlen is not fold into a const as in foo () above. Presumably,
gcc is too conservative about what hallo () function can do. By adding a pure
attribute to hallo (), gcc will generate optimal code.

Clang 3.8 gives optimal code in this case as well.

[Bug middle-end/71619] [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Practically the same issue as PR48189.

[Bug c/71610] Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
I'm working on this

[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #3 from Thomas Preud'homme  ---
I have a patch for this but it has not had much testing so far. It also
includes code to fix -mslow-flash-data with floating-point constants. I'll see
to split the patch in two as testing the integer part should be simpler.

Best regards.

[Bug middle-end/71606] [4.9/5/6/7 Regression] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
I'm testing a candidate patch.

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
Bug 12944 depends on bug 31336, which changed state.

Bug 31336 Summary: template friends and Koenig lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31336

   What|Removed |Added

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

[Bug c++/59366] A friend function template defined in a class is found without ADL

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||andrew.olson at hughes dot net

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

[Bug c++/65608] [meta-bug] friend issues

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 31336, which changed state.

Bug 31336 Summary: template friends and Koenig lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31336

   What|Removed |Added

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

[Bug c++/31336] template friends and Koenig lookup

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Blocks||12944
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
In the originally submitted test program, both GCC 7 and EDG eccp 4.11 accept
all cases but #5.  Clang 3.8 also rejects #5 and #7.  Below is a reduced test
case that reproduces the same behavior.  By my reading, case #5 is invalid but
case #7 is valid because the friend function bar is found by argument dependent
lookup.  The invalid case wasn't handled correctly until r219689 committed to
resolve bug 59366. Closing as duplicate of that bug.


So I'm inclined to resolve this bug as fixed.

$ cat t.C && gcc -S -Wall -Wextra t.C
struct Foo { };

struct Bar
{
  template 
  friend void bar (const T&, int);
};

int main ()
{
  Foo f;

  bar (1, 5);
  bar (f, 7); 
}
t.C: In function ‘int main()’:
t.C:13:3: error: ‘bar’ was not declared in this scope
   bar (1, 5);
   ^~~

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804
Bug 37804 depends on bug 31336, which changed state.

Bug 31336 Summary: template friends and Koenig lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31336

   What|Removed |Added

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

[Bug tree-optimization/71490] [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #4 from Bill Seurer  ---
Also fails on powerpc

[Bug sanitizer/71611] UBSan shows type '' for enums based on long

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Certainly not here.
int
f1 ()
{
  enum I { c = -__LONG_MAX__ - 1 } x = c;
  x = -x;
  return x;
}

int
f2 ()
{
  enum J { c = -__INT_MAX__ - 1 } x = c;
  x = -x;
  return x;
}

int
f3 ()
{
  int x = -__INT_MAX__ - 1;
  x = -x;
  return x;
}

int
f4 ()
{
  enum { c = -__LONG_MAX__ - 1 } x = c;
  x = -x;
  return x;
}

int
f5 ()
{
  enum { c = -__INT_MAX__ - 1 } x = c;
  x = -x;
  return x;
}

int
main ()
{
  f1 ();
  f2 ();
  f3 ();
  f4 ();
  f5 ();
  return 0;
}

reports:
pr71611.c:5:5: runtime error: negation of -9223372036854775808 cannot be
represented in type 'I'; cast to an unsigned type to negate this value to
itself
pr71611.c:13:5: runtime error: negation of -2147483648 cannot be represented in
type 'J'; cast to an unsigned type to negate this value to itself
pr71611.c:21:5: runtime error: negation of -2147483648 cannot be represented in
type 'int'; cast to an unsigned type to negate this value to itself
pr71611.c:29:5: runtime error: negation of -9223372036854775808 cannot be
represented in type ''; cast to an unsigned type to negate this value
to itself
pr71611.c:37:5: runtime error: negation of -2147483648 cannot be represented in
type ''; cast to an unsigned type to negate this value to itself

GCC in the middle-end considers enums and integer types with the same sign and
precision as compatible types, so there is no guarantee the types the sanitizer
sees are the original ones, and changing that (making for -fsanitize=undefined
conversion between different types not useless) would be way too costly for the
generated code quality.

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[Roger.Jeurninck at gmail dot com]

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

Roger Jeurninck  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Roger Jeurninck  ---

thanks for your answer the hints you gave will definitely help me further.
please close this ticket
grtz,

Roger

[Bug sanitizer/71611] UBSan shows type '' for enums based on long

[ch3root at openwall dot com]

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

--- Comment #2 from Alexander Cherepanov  ---
On 06/22/2016 06:08 PM, jakub at gcc dot gnu.org wrote:
> This has nothing to do with enums based on long, but about anonymous enums.
>  is what is used for all types that don't have a name.
> Would you prefer  instead or ?

If I change LONG_MIN to INT_MIN in my example then the message talks 
about 'int':

test.c:6:5: runtime error: negation of -2147483648 cannot be represented 
in type 'int'; cast to an unsigned type to negate this value to itself

So it definitely depends on an integer type that the enum is based on. 
But maybe this was not intentional?

[Bug c/70339] Poor message for "singed" vs "signed" typo

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jun 22 15:20:41 2016
New Revision: 237714

URL: https://gcc.gnu.org/viewcvs?rev=237714=gcc=rev
Log:
C FE: suggest corrections for misspelled identifiers and type names

gcc/c-family/ChangeLog:
PR c/70339
* c-common.h (enum lookup_name_fuzzy_kind): New enum.
(lookup_name_fuzzy): New prototype.

gcc/c/ChangeLog:
PR c/70339
* c-decl.c: Include spellcheck-tree.h and gcc-rich-location.h.
(implicit_decl_warning): When issuing warnings for implicit
declarations, attempt to provide a suggestion via
lookup_name_fuzzy.
(undeclared_variable): Likewise when issuing errors.
(lookup_name_in_scope): Likewise.
(struct edit_distance_traits): New struct.
(best_macro_match): New typedef.
(find_closest_macro_cpp_cb): New function.
(lookup_name_fuzzy): New function.
* c-parser.c: Include gcc-rich-location.h.
(c_token_starts_typename): Split out case CPP_KEYWORD into...
(c_keyword_starts_typename): ...this new function.
(c_parser_declaration_or_fndef): When issuing errors about
missing "struct" etc, add a fixit.  For other kinds of errors,
attempt to provide a suggestion via lookup_name_fuzzy.
(c_parser_parms_declarator): When looking ahead to detect typos in
type names, also reject CPP_KEYWORD.
(c_parser_parameter_declaration): When issuing errors about
unknown type names, attempt to provide a suggestion via
lookup_name_fuzzy.
* c-tree.h (c_keyword_starts_typename): New prototype.

gcc/ChangeLog:
PR c/70339
* diagnostic-core.h (pedwarn_at_rich_loc): New prototype.
* diagnostic.c (pedwarn_at_rich_loc): New function.
* spellcheck.h (best_match::best_match): Add a
"best_distance_so_far" optional parameter.
(best_match::set_best_so_far): New method.
(best_match::get_best_distance): New accessor.
(best_match::get_best_candidate_length): New accessor.

gcc/testsuite/ChangeLog:
PR c/70339
* c-c++-common/attributes-1.c: Update dg-prune-output to include
hint.
* gcc.dg/diagnostic-token-ranges.c (undeclared_identifier): Update
expected results due to builtin "nanl" now being suggested for
"name".
* gcc.dg/pr67580.c: Update expected messages.
* gcc.dg/spellcheck-identifiers.c: New testcase.
* gcc.dg/spellcheck-typenames.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers.c
trunk/gcc/testsuite/gcc.dg/spellcheck-typenames.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/diagnostic-core.h
trunk/gcc/diagnostic.c
trunk/gcc/spellcheck.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c
trunk/gcc/testsuite/gcc.dg/pr67580.c

[Bug rtl-optimization/71621] [7 Regression] ICE in assign_by_spills, at lra-assigns.c:1417 (error: unable to find a register to spill) w/ -O2 -mavx2 -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-22
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r237556, but that just likely made it no longer latent.

[Bug c++/67008] Qualified name-lookup in using-declaration fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Blocks||12944
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
The test case failed with GCC 4.5 but I'm not able to reproduce the error with
either 6.1 or 7.0. It looks like it may have been broken for some time in 6.0
but then was fixed by r235206 under bug 70522.  Resolving as a duplicate.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
Bug 12944 depends on bug 67008, which changed state.

Bug 67008 Summary: Qualified name-lookup in using-declaration fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67008

   What|Removed |Added

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

[Bug c++/71616] [7 Regression] ICE on valid C++ code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
A bit modified test-case ICE in verifier:

extern "C" inline 
int pthread_equal () {}

static __typeof pthread_equal __gthrw_pthread_equal 
__attribute__ ((__weakref__ ("pthread_equal")));

void foo () 
{
  __gthrw_pthread_equal ();
}


$ ./xg++ -B. ~/Programming/testcases/pr71616.c -c
/home/marxin/Programming/testcases/pr71616.c:10:1: error: comdat-local function
called by void foo() outside its comdat
 }
 ^
_ZL21__gthrw_pthread_equalv/1 (int __gthrw_pthread_equal()) @0x7f38b1b66170
  Type: function definition analyzed alias transparent_alias weakref
  Visibility: weak comdat_group:pthread_equal
  Same comdat group as: pthread_equal/0
  References: pthread_equal/0 (alias)
  Referring: 
  First run: 0
  Function flags:
  Called by: _Z3foov/2 (1.00 per call) (can throw external) 
  Calls: 
/home/marxin/Programming/testcases/pr71616.c:10:1: internal compiler error:
verify_cgraph_node failed
0xa03d0a cgraph_node::verify_node()
../../gcc/cgraph.c:3454
0x9f8baf symtab_node::verify()
../../gcc/symtab.c:1177
0x9f8c8f symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1197
0xa0c024 symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:614
0xa0c024 symbol_table::compile()
../../gcc/cgraphunit.c:2383
0xa0e557 symbol_table::compile()
../../gcc/cgraphunit.c:2539
0xa0e557 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2565

[Bug c++/70522] Hidden friend functions block qualified name lookup into nested unnamed namespace

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||anders.granlund.0 at gmail dot 
com

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

[Bug sanitizer/71611] UBSan shows type '' for enums based on long

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
This has nothing to do with enums based on long, but about anonymous enums.
 is what is used for all types that don't have a name.
Would you prefer  instead or ?

[Bug target/71615] wrong float point result with {-Ofast, -march=native, and valgrind}

[wangmianzhi1 at linuxmail dot org]

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

Mianzhi Wang  changed:

   What|Removed |Added

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

--- Comment #4 from Mianzhi Wang  ---
By executing:
$ valgrind --show-emwarns=yes ./test

It turned out:
==16833== Emulation warning: unsupported action:
==16833==   Setting %mxcsr.fz (SSE flush-underflows-to-zero mode)
==16833==at 0x4006D2: set_fast_math (crtfastmath.c:93)
==16833==by 0x400A8C: __libc_csu_init (in /home/mianzhi/Desktop/test/test)
==16833==by 0x51857BE: (below main) (libc-start.c:247)

So it IS an known issue of valgrind.
See:
``Valgrind has the following limitations in its implementation of x86/AMD64
SSE2 FP arithmetic, relative to IEEE754''
of:
http://valgrind.org/docs/manual/manual-core.html#manual-core.limits

Here I'm closing the ticket.

[Bug c++/71420] "‘type’ is not a class type" error for address-of operator overloaded for enum type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-22
 CC||msebor at gcc dot gnu.org
 Blocks||12944
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #2 from Martin Sebor  ---
Confirmed with the simplified test case below.  Both Clang 3.8 and EDG eccp
4.11 accept the code.  GCC never seems to have gotten this right (there might
already be a bug about this somewhere though I couldn't find one that matched).

$ cat t.C && gcc -S -Wall -Wextra t.C

enum E { A };

constexpr E operator & (E e)
{
  return e;
}

template
struct S { };

S s;
t.C:8:26: error: ‘E’ is not a class type
 template
  ^~
t.C:11:4: error: template argument 2 is invalid
 S s;
^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug target/71615] wrong float point result with {-Ofast, -march=native, and valgrind}

[wangmianzhi1 at linuxmail dot org]

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

--- Comment #3 from Mianzhi Wang  ---
The bug disappears on an i7 3700k with the identical OS, GCC, and valgrind.
Should be something related to the AMD CPU.

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  ---
(In reply to Senthil Kumar Selvaraj from comment #12)
> This works if the start of data is specified as -Tdata 0xaddress. Other ways
> of specifying the same thing don't work; -Tdata=0xaddress,
> -Wl,-Tdata=0xaddress or -Wl,-Tdata,0xaddress all fail.

Hard to fix all these in the compiler like -Wl,--section-start

We could document the current behavior and that -Tdata or -Ttext should be
used.

Or we could introduce a new option to use in the specs only and that also wraps
around like %{!mnew-option:%{!Tdata:Tdata ...}}

In any case the user must read the documentation and be aware of the new option
or the recommended practice.

A new option does not make much sense because instead of -mnew-option she could
just as well use -Tdata as needed...

> Do you know why the linker picks the option first appearing on the
> commandline, rather than the usual last?

No, and dunno how the linker handles several maybe conflicting multiple
specifications.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

[paul.richard.thomas at gmail dot com]

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

--- Comment #11 from paul.richard.thomas at gmail dot com  ---
When I have a moment, I intend to fix 5- and 6-branches.

Cheers

Paul

On 22 June 2016 at 16:12, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
>
> --- Comment #10 from Dominique d'Humieres  ---
> Any reason why this PR is not closed as FIXED?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/71618] Improve C++ compilation by adding specific optimization flags

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
I suspect you're missing an aspect of GCC optimization options that's not very
apparent from reading the manual alone and that's been the topic of enough
similar questions in the past to get its own FAQ entry:

  https://gcc.gnu.org/wiki/FAQ#optimization-options

Basically, -ON options are more than just aggregates of -fxxx options.  They
may implicitly enable additional optimizations that other optimizations need to
do their work.  (You may find the output of gcc -help=optimizers helpful here,
though it too needs to be interpreted with the above caveat in mind.)

I resolve this bug as Invalid because it doesn't report a problem but, IIUC,
rather asks a question.  I suggest to ask questions about using GCC on the
gcc-help list.  If you do think there is a problem with GCC or its
documentation, please open a new bug and describe what you think is wrong and
what you expect.

[Bug c++/71616] [7 Regression] ICE on valid C++ code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-22
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid C++ code at|[7 Regression] ICE on valid
   |-O1 and above on|C++ code at -O1 and above
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |binds_to_current_def_p, at  |binds_to_current_def_p, at
   |symtab.c:2232   |symtab.c:2232
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r235065.

[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to vries from comment #7)
> The previous patch did give the error for -m32.

Meant: The previous patch did _not_ give the error for -m32.

[Bug middle-end/71619] [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Jakub Jelinek  ---
Started with r237103.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5, 4.9.4
   Keywords||wrong-code
   Last reconfirmed||2016-06-22
 Blocks||68241
 Ever confirmed|0   |1
Summary|Segfault when allocating|[5/6/7 Regression] Segfault
   |deferred-length characters  |when allocating
   |to size of a pointer|deferred-length characters
   ||to size of a pointer
  Known to fail||5.4.0, 6.1.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
Segfault confirmed from 5.4 up to trunk (7.0).

> This works in 4.9.0 and 4.8.3, as well as ifort 14.

Confirmed with 4.9.4 20160521 (prerelease) and 4.8.5.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #38736|0   |1
is obsolete||
  Attachment #38737|0   |1
is obsolete||

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 38750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38750=edit
Updated tentative patch

(In reply to vries from comment #6)
> Created attachment 38737 [details]
> tentative patch with log entry and test-case
> 
> Currently testing on x86_64.

The previous patch did give the error for -m32. This one does.

Bootstrapped and reg-tested on x86_64 with -m64/-m32.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Any reason why this PR is not closed as FIXED?

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

--- Comment #11 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jun 22 14:05:55 2016
New Revision: 237706

URL: https://gcc.gnu.org/viewcvs?rev=237706=gcc=rev
Log:
gcc/

PR middle-end/71488
* tree-vect-patterns.c (vect_recog_mask_conversion_pattern): Support
comparison of boolean vectors.
* tree-vect-stmts.c (vectorizable_comparison): Vectorize comparison
of boolean vectors using bitwise operations.

gcc/testsuite/

PR middle-end/71488
* g++.dg/pr71488.C: New test.
* gcc.dg/vect/vect-bool-cmp.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr71488.C
trunk/gcc/testsuite/gcc.dg/vect/vect-bool-cmp.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-stmts.c

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #38740|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Created attachment 38749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38749=edit
gcc7-pr66867.patch

Patch I'm going to bootstrap/regtest.

[Bug ipa/71624] New: [6 regression][7 regression][CHKP] internal compiler error: in duplicate_thunk_for_node

[ienkovich at gcc dot gnu.org]

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

Bug ID: 71624
   Summary: [6 regression][7 regression][CHKP] internal compiler
error: in duplicate_thunk_for_node
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Here is a small test causing ICE:

>cat small.cc
class c1
{
public:
  virtual int fn1 () const;
  int fn2 (const int *) const;
};

class c2
{
  int fn1 ();
  c1 obj;
};

int
c1::fn1 () const
{
  return 0;
}

int
c1::fn2 (const int *) const
{
  return this->fn1 ();
}

int
c2::fn1 ()
{
  return obj.fn2 (0);
}
>g++ -O2 -mmpx -fcheck-pointer-bounds small.cc -S
small.cc:30:1: internal compiler error: in duplicate_thunk_for_node, at
cgraphclones.c:321
 }
 ^
0x9350ca duplicate_thunk_for_node
/export/users/gnutester/stability/svn/trunk/gcc/cgraphclones.c:321
0x93524f cgraph_edge::redirect_callee_duplicating_thunks(cgraph_node*)
/export/users/gnutester/stability/svn/trunk/gcc/cgraphclones.c:355
0x93550b cgraph_node::create_clone(tree_node*, long, int, bool,
vec, bool, cgraph_node*, bitmap_head*)
/export/users/gnutester/stability/svn/trunk/gcc/cgraphclones.c:477
0x93585b cgraph_node::create_virtual_clone(vec,
vec*, bitmap_head*, char const*)
/export/users/gnutester/stability/svn/trunk/gcc/cgraphclones.c:578
0x140a7fc create_specialized_node
/export/users/gnutester/stability/svn/trunk/gcc/ipa-cp.c:3473
0x140c1bb decide_whether_version_node
/export/users/gnutester/stability/svn/trunk/gcc/ipa-cp.c:4392
0x140c1bb ipcp_decision_stage
/export/users/gnutester/stability/svn/trunk/gcc/ipa-cp.c:4504
0x140c1bb ipcp_driver
/export/users/gnutester/stability/svn/trunk/gcc/ipa-cp.c:4618
0x140c1bb execute
/export/users/gnutester/stability/svn/trunk/gcc/ipa-cp.c:4708

Looks like we are trying to propagate through instrumentation thunk which is
supposed to be restricted.

[Bug fortran/71623] New: Segfault when allocating deferred-length characters to size of a pointer

[zed.three at gmail dot com]

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

Bug ID: 71623
   Summary: Segfault when allocating deferred-length characters to
size of a pointer
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zed.three at gmail dot com
  Target Milestone: ---

Created attachment 38748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38748=edit
MVCE for allocation bug

When running the attached MVCE with gfortran 5.4.0 and 6.1.1 (20160615
[gcc-6-branch revision 237474]), there's a segfault on the line:

 allocate(character(len=size(array_ptr))::string)

but not on

 allocate(character(len=size(array))::string)

or

 allocate(character(len=ptr_size)::string)

where array_ptr => array, and ptr_size = size(array_ptr).

This works in 4.9.0 and 4.8.3, as well as ifort 14.

[Bug rtl-optimization/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
btw, to trigger the ICE on other tuning options use:
 --param max-rtl-if-conversion-insns=2

[Bug rtl-optimization/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Testing a patch.

[Bug rtl-optimization/58008] ICE: Max. number of generated reload insns per insn is achieved (90)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
I cannot reproduce this one neither w/ 5.4 nor w/ current trunk.

[Bug rtl-optimization/71621] New: [7 Regression] ICE in assign_by_spills, at lra-assigns.c:1417 (error: unable to find a register to spill) w/ -O2 -mavx2 -ftree-vectorize

[asolokha at gmx dot com]

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

Bug ID: 71621
   Summary: [7 Regression] ICE in assign_by_spills, at
lra-assigns.c:1417 (error: unable to find a register
to spill) w/ -O2 -mavx2 -ftree-vectorize
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: uros at gcc dot gnu.org, vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-7.0.0-alpha20160619 snapshot fails to compile the following reduced
testcase w/ -O2 -mavx2 -ftree-vectorize:

int cn;
int *li;

void
y8 (void)
{
  int gv;
  int *be = 
  short int v4 = 2;

  while (*li != 0)
{
  int sy;
  for (sy = 0; sy < 5; ++sy)
{
  int **t6 = 
  gv |= sy ? 0 : v4;
  if (gv != 0)
++gv;
  t6 = 
  if (gv != 0)
*t6 = 0;
}
  for (gv = 0; gv < 24; ++gv)
v4 |= 1 <= 1 % 0;
  ++(*li);
}
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20160619 -w -c -O2 -mavx2 -ftree-vectorize
nl1c5wer.c
nl1c5wer.c: In function 'y8':
nl1c5wer.c:28:1: error: unable to find a register to spill
 }
 ^
nl1c5wer.c:28:1: error: this is the insn:
(insn 35 177 37 3 (set (reg:V16HI 136)
(vec_duplicate:V16HI (reg:HI 199))) 4217 {*vec_dupv16hi}
 (expr_list:REG_DEAD (reg:HI 199)
(nil)))
nl1c5wer.c:28:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1417

Changing -mavx2 to -march=haswell results in the following:

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20160619 -w -c -O2 -march=haswell
-ftree-vectorize nl1c5wer.c
nl1c5wer.c: In function 'y8':
nl1c5wer.c:28:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)

[Bug middle-end/71619] [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-22
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, having a patch that I'll send to ML soon.

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #4)
> Created attachment 38744 [details]
> pr71347.c.214t.optimized
> 
> The new testcase FAILs on sparc*-sun-solaris2.* (both 32 and 64-bit):
> 
> FAIL: gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> 
> Dump attached.
> 
>   Rainer

Thanks for reporting.  I am going to disable this on various targets according
to https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01377.html

[Bug tree-optimization/71620] New: gcc.dg/vect/slp-45.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 71620
   Summary: gcc.dg/vect/slp-45.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Created attachment 38745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38745=edit
slp-45.c.149t.vect

The new gcc.dg/vect/slp-45.c testcase FAILs on Solaris/SPARC, both 32 and
64-bit:

+FAIL: gcc.dg/vect/slp-45.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"
vectorized 1 loops" 13
+FAIL: gcc.dg/vect/slp-45.c scan-tree-dump-times vect "vectorized 1 loops" 13

Dump attached.

  Rainer

[Bug tree-optimization/71620] gcc.dg/vect/slp-45.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug rtl-optimization/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed|2016-06-20 00:00:00 |2016-6-22
 CC||ktkachov at gcc dot gnu.org
  Component|c   |rtl-optimization
   Target Milestone|--- |7.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Confirmed the ICE on x86_64.

Thanks for the full backtrace Rainer
Judging by the backtrace it looks like it could be caused or exposed by my
patch at https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01058.html

I'll have a look

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Created attachment 38744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38744=edit
pr71347.c.214t.optimized

The new testcase FAILs on sparc*-sun-solaris2.* (both 32 and 64-bit):

FAIL: gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"

Dump attached.

  Rainer

[Bug c/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
I'm seeing the same ICE as a testsuite regression in sparc*-sun-solaris2*
bootstraps:

+FAIL: gcc.dg/torture/pr67121.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel
-loops -ftracer -finline-functions  (internal compiler error)
+FAIL: gcc.dg/torture/pr67121.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel
-loops -ftracer -finline-functions  (test for excess errors)
+WARNING: gcc.dg/torture/pr67121.c   -O3 -fomit-frame-pointer -funroll-loops
-fp
eel-loops -ftracer -finline-functions  compilation failed to produce executable
+FAIL: gcc.dg/torture/pr67121.c   -O3 -g  (internal compiler error)
+FAIL: gcc.dg/torture/pr67121.c   -O3 -g  (test for excess errors)
+WARNING: gcc.dg/torture/pr67121.c   -O3 -g  compilation failed to produce
execu
table

for both 32- and 64-bit:

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/torture/pr67121.c:31:1:
internal compiler error: in maybe_legitimize_operand, at optabs.c:6893
0x88b233 maybe_legitimize_operand
/vol/gcc/src/hg/trunk/local/gcc/optabs.c:6892
0x88b233 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/vol/gcc/src/hg/trunk/local/gcc/optabs.c:6959
0x88b667 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/vol/gcc/src/hg/trunk/local/gcc/optabs.c:6977
0x88da97 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/vol/gcc/src/hg/trunk/local/gcc/optabs.c:7020
0x88da97 emit_conditional_move(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, rtx_def*, rtx_def*, machine_mode, int)
/vol/gcc/src/hg/trunk/local/gcc/optabs.c:4280
0xed304f noce_emit_cmove
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:1727
0xed53fb noce_convert_multiple_sets
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:3232
0xedb183 noce_process_if_block
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:3406
0xedcdbf noce_find_if_block
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:4047
0xedcdbf find_if_header
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:4252
0xedcdbf if_convert
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:5401
0xeddde7 rest_of_handle_if_conversion
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:5460
0xeddde7 execute
/vol/gcc/src/hg/trunk/local/gcc/ifcvt.c:5497

  Rainer

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

[saaadhu at gcc dot gnu.org]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

 CC||saaadhu at gcc dot gnu.org

--- Comment #12 from Senthil Kumar Selvaraj  ---
This works if the start of data is specified as -Tdata 0xaddress. Other ways of
specifying the same thing don't work; -Tdata=0xaddress, -Wl,-Tdata=0xaddress or
-Wl,-Tdata,0xaddress all fail.

Do you know why the linker picks the option first appearing on the commandline,
rather than the usual last?

[Bug middle-end/71619] New: [7 Regression] ICE: in predict_loops, at predict.c:1772 with --param=max-predicted-iterations=0

[zsojka at seznam dot cz]

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

Bug ID: 71619
   Summary: [7 Regression] ICE: in predict_loops, at
predict.c:1772 with --param=max-predicted-iterations=0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ gcc -O --param=max-predicted-iterations=0 testcase.c 
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in predict_loops, at predict.c:1772
 }
 ^
0xad753b predict_loops
/repo/gcc-trunk/gcc/predict.c:1772
0xad7b39 tree_estimate_probability(bool)
/repo/gcc-trunk/gcc/predict.c:2573
0xad972b execute
/repo/gcc-trunk/gcc/predict.c:3271
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-237652-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-237652-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160621 (experimental) (GCC)

[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords|wrong-code  |lto

--- Comment #6 from Markus Trippelsdorf  ---
Pure PGO bootstrap works fine.

[Bug c/71560] union compound literal initializes wrong union field

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #2)
> 99) Note that this differs from a cast expression.  For example, a cast
> specifies a conversion to scalar types or void only, and the result of a
> cast expression is not an lvalue.

https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html :
...
A cast to union is actually a constructor, not a cast, and hence does not yield
an lvalue like normal casts.
...

This implies that normal casts yield lvalues (maybe still referring to
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Lvalues.html ?). I suppose we
should fix this bit of doc as well.

[Bug c++/71618] New: Improve C++ compilation by adding specific optimization flags

[Roger.Jeurninck at gmail dot com]

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

Bug ID: 71618
   Summary: Improve C++ compilation by adding specific
optimization flags
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Roger.Jeurninck at gmail dot com
  Target Milestone: ---

Hi,

I'm compiling C++ code together with gmock. Unfortunately this slows down the
compilation for one file to 10 minutes (using -g -O0) 
Using one of the optimization levels (e.g. -O1) does improve the performance a
lot to a little more than 1 minute. Unfortunately this is not the best solution
as the code which is being compiled is being used for testing and debugging and
optimization might hamper this. 
As a solution I try to pinpoint the optimization flag which does give this
beneficial compilation performance. The strange thing I do notice now that
proving 'g++ -O1' does not give the same result as providing the list of
optimization flags belonging to -O1. So what am I missing here?

- Commands used --
about 1m30s => g++ -O1 -c 
about 10m => g++ -fauto-inc-dec -fcprop-registers -fdce -fdefer-pop
-fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2
-fif-conversion -finline-small-functions -fipa-pure-const -fipa-reference
-fmerge-constants -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp
-ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse
-ftree-fre -ftree-sra -ftree-ter -funit-at-a-time -fomit-frame-pointer -c


- gcc specs --
gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --prefix=/cadappl/gcc/4.4.2/gcc
--enable-languages=c,c++,fortran,java
--with-gmp-lib=/shared/caddev/wblanken/5.10/gcc_4.4.2/gcc/4.4.2/SunOS_5.10/cadenv_home/cadlib:/usr/lib:/usr/ccs/lib:/usr/dt/lib:/usr/openwin/lib
--with-gmp-include=/shared/caddev/wblanken/5.10/gcc_4.4.2/gcc/4.4.2/SunOS_5.10/cadenv_home/cadinc
--with-mpfr-lib=/shared/caddev/wblanken/5.10/gcc_4.4.2/gcc/4.4.2/SunOS_5.10/cadenv_home/cadlib:/usr/lib:/usr/ccs/lib:/usr/dt/lib:/usr/openwin/lib
--with-mpfr-include=/shared/caddev/wblanken/5.10/gcc_4.4.2/gcc/4.4.2/SunOS_5.10/cadenv_home/cadinc
--without-gnu-as --with-ld=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 4.4.2 (GCC)

[Bug c/71617] New: rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]

[mathieu.malaterre at gmail dot com]

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

Bug ID: 71617
   Summary: rs6000.c:8483:32: warning: comparison is always true
due to limited range of data type [-Wtype-limits]
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

The following code should be cleaned up:

powerpc64-linux-gnu-g++-5 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o rs6000.o -MT rs6000.o
-MMD -MP -MF ./.deps/rs6000.TPo ../../src/gcc/config/rs6000/rs6000.c
../../src/gcc/config/rs6000/rs6000.c: In function 'bool
use_toc_relative_ref(rtx, machine_mode)':
../../src/gcc/config/rs6000/rs6000.c:8483:32: warning: comparison is always
true due to limited range of data type [-Wtype-limits]
&& GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT));
^

[Bug target/71615] wrong float point result with {-Ofast, -march=native, and valgrind}

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #2 from nsz at gcc dot gnu.org ---
see x86 floating-point limitations in valgrind:
http://valgrind.org/docs/manual/manual-core.html#manual-core.limits

[Bug fortran/71592] Add some facilities for compile-time check

[heresy-me at hotmail dot com]

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

鍾  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #5 from 鍾  ---
full_assertion_declaration ::= assertion_directive assertion_declaration
assertion_directive ::= *$assertion|c$assertion|!$assertion
assertion_declaration ::= assertion_body{,assertion_body}
assertion_body ::= static_assertion|dynamic_assertion
static_assertion ::= static(compile_time_boolean_expression,[failure_message])
dynamic_assertion ::=
dynamic(execution_time_boolean_expression,[failure_message])
failure_message ::= static_fortran_string

the static assertion directives of procedure is not only work on current
compilation unit, but also work on any module(possibly). a procedure contain
static assertion directive of a module, its assertion can contained by the
modules' mod file. So any procedures use this module procedure will be checked
the assertions by the compiler on compile-time(not on execution-time).

the dynamic assertion isn't like the simple preprocess assertion. dynamic
assertion will generate some check code, but the check code is not expanded on
the body of procedures. it can be a independent code fraction, or inlined to
the procedure consumer, but never alter the execution code of called procedure.

Then, the assertion can added freely for the function when declaration or
implementation.