[Bug c++/79702] New: AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1

[kreckel at ginac dot de]

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

Bug ID: 79702
   Summary: AX_CXX_COMPILE_STDCXX([17]) does not work with
GCC=7.0.1
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kreckel at ginac dot de
  Target Milestone: ---

This program is reduced from the C++17 conftest produced by the macro from
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html:

#include 

struct S
{
  int x1 : 2;
  volatile double y1;
};

S f3()
{
  return {};
}

const auto [ x3, y3 ] = f3();

It fails to compile with g++ 7.0.1 20170205 on x86_64-pc-linux-gnu:
$ g++ -std=c++17 -c conftest.cpp 
conftest.cpp:14:12: error: 'std::tuple_size::value' is not an integral
constant expression
 const auto [ x3, y3 ] = f3();
^~

The error has something to do with , as it goes away if I comment out
the #include directive.

[Bug preprocessor/79701] New: #pragma ignored "-Wcomment" has no effect

[damien at iwi dot me]

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

Bug ID: 79701
   Summary: #pragma ignored "-Wcomment" has no effect
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damien at iwi dot me
  Target Milestone: ---

Hi,

It seems that `diagnostic ignored -Wcomment` has no effect.
Since nothing states that it does not work, I would expect no warning here.
Thanks :)

```
int main() {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcomment"
/* /* */
#pragma GCC diagnostic pop
return 0;
}

gcc -Wall /tmp/foo.cpp
/tmp/foo.cpp:5:5: warning: "/*" within comment [-Wcomment]
```

[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions

[law at redhat dot com]

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

--- Comment #28 from Jeffrey A. Law  ---
WRT c#26.  

Yes, I would agree that finding CSE's that way is rather gross, but
significantly less so than what will be required to address this problem in
phi-opt.

Pattern matching this is going to be significantly more complex than the
ADD_OVERFLOW/SUB_OVERFLOW.  I've looked at that code via pr79095 and catching
these saturating idioms is significantly more complex.

I prototyped the idea of having DOM do extra lookups for a widened version of X
OP Y.  It's a bit ugly relative to the match.pd approach, but possibly
manageable.

However, doing that in DOM exposes some lameness we'd have to address in VRP.

Prior to DOM2 we have:

;   basic block 4, loop depth 0, count 0, freq 4665, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [67.6%]  (TRUE_VALUE,EXECUTABLE)
  _6 = (unsigned char) val_12(D);
  _7 = _3 + _6;
  iftmp.1_13 = (int) _7;

We transform that into:

;;   basic block 4, loop depth 0, count 0, freq 4665, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [67.6%]  (TRUE_VALUE,EXECUTABLE)
  iftmp.1_13 = _15 & 255

That's value preserving and clearly an improvement.  Unfortunately we have to
wait until vrp2 to discover that the masking is redundant and simplify the
statement into:


iftmp.1_13 = _15

The problem is we do not propagate that copy into the PHI node at BB4's
successor.  By the time we do finally propagate away the copy, there aren't any
additional phi-opt passes to turn things into a MIN/MAX.

THe lack of copy propagation when VRP simplifies a statement like that is due
to using op_with_constant_singleton_value_range as the callback for
substitute_and_fold.  op_with_constant_singleton_value_range only returns
exactly what you would think -- constant singleton ranges.  Thus we don't
discover or exploit copy propagation opportunities created by VRP's statement
simplification.

Enhancing the callback to return an SSA_NAME for cases were VRP simplifies
arithmetic/logicals to copies allows the propagation step to propagate the copy
into the PHI node in BB4's successor.

That in turn allows phi-opt to do its job and by the .optimized dump we have:

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  _1 = (sizetype) i_9(D);
  _2 = tmp_10(D) + _1;
  _3 = *_2;
  _4 = (int) _3;
  _5 = _4 + val_12(D);
  _16 = MAX_EXPR <_5, 0>;
  iftmp.0_7 = MIN_EXPR <_16, 255>;
  return iftmp.0_7;
;;succ:   EXIT [100.0%]


Which is what we want at this stage.  Transforming something like that into
saturating arithmetic for processors which support such insns is much easier
(but IMHO out of the scope of this BZ).

Anyway, I'm offline the next few days and largely booked on non-technical stuff
much of March.  I don't know if I'll be able to push this further over the next
few weeks or not.

[Bug tree-optimization/79697] unused realloc(0, n) not eliminated

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 40821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40821=edit
untested patch

In cddce/dce pass, mark_stmt_if_obviously_necessary() does not special case
strdup, strndup, and marks them as obviously necessary.
From the dump of cddce1:
Marking useful stmt: __builtin_strdup ("abc");

The attached (untested) patch does not mark stmt necessary if it's a call stmt
and callee is strdup/strndup, and for realloc if the first arg compares equal
to null_pointer_node and can thus delete these calls.
Does it look OK ?

Thanks,
Prathamesh

[Bug debug/31920] Bad location information for Java local variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Java has been removed so resolving as won'tfix.

[Bug target/31705] inline assembler causes ICE: extract_constrain_insn_cached, at recog.c:2002

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Sounds like this ice-on-invalid.  I cannot reproduce the ICE anymore so
resolving as fixed.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.3.2, 4.6.0, 5.3.0, 6.3.0,
   ||7.0

--- Comment #4 from Martin Sebor  ---
Confirmed with today's top of trunk (7.0).  It might be worthwhile to break up
the test cases into individual bugs.

$ (set -x && cat t.c && for n in 1 2 3 4 5; do gcc -DTEST=$n -O2 -S -Wall
-Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout t.c; done)
+ cat t.c
#if TEST == 1
int foo(int n)  // should not ICE
{
return ({struct {int x[n];} x; x.x[12] = 1; x;}).x[12];
}
#elif TEST == 2
int foo(void)   // should not ICE
{
return sizeof({int n = 20; struct {int x[n];} x; x.x[12] = 1; x;});
}
#elif TEST == 3
int foo(void)   // should not return 0
{
int n = 0;
return sizeof({n = 10; struct {int x[n];} x; x;});
}
#elif TEST == 4
int foo(void)   // should not ICE
{
return (*({
int n = 20;
char (*x)[n][n] = __builtin_malloc(n * n);
(*x)[12][1] = 1;
x;
}))[12][1];
}
#elif TEST == 5
int foo(void)   // should return 1, returns 0
{
int n = 0;
return (*({
n = 20;
char (*x)[n][n] = __builtin_malloc(n * n);
(*x)[12][1] = 1;
(*x)[0][1] = 0;
x;
}))[12][1];
}
#endif
+ for n in 1 2 3 4 5
+ gcc -DTEST=1 -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
t.c: In function ‘foo’:
t.c:4:30: warning: a member of a structure or union cannot have a variably
modified type [-Wpedantic]
 return ({struct {int x[n];} x; x.x[12] = 1; x;}).x[12];
  ^
t.c:4:16: warning: ISO C forbids braced-groups within expressions [-Wpedantic]
 return ({struct {int x[n];} x; x.x[12] = 1; x;}).x[12];
^

;; Function foo (foo, funcdef_no=0, decl_uid=1795, cgraph_uid=0,
symbol_order=0)

foo (int n)
{
  struct 
  {
int x[0:D.1807];
  } * x.1;
  struct 
  {
int x[0:D.1807];
  } * D.1814;
  sizetype _1;
  sizetype _2;
  int _16;

   [100.00%]:
  _1 = (sizetype) n_3(D);
  _2 = _1 * 4;
  _8 = __builtin_alloca_with_align (_2, 32);
  x.1_12 = __builtin_alloca_with_align (_2, 32);
  x.1_12->x[12] = 1;
  __builtin_memcpy (_8, x.1_12, _2);
  _16 = _8->x[12];
  return _16;

}


+ for n in 1 2 3 4 5
+ gcc -DTEST=2 -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
t.c: In function ‘foo’:
t.c:9:48: warning: a member of a structure or union cannot have a variably
modified type [-Wpedantic]
 return sizeof({int n = 20; struct {int x[n];} x; x.x[12] = 1; x;});
^
t.c:9:22: warning: ISO C forbids braced-groups within expressions [-Wpedantic]
 return sizeof({int n = 20; struct {int x[n];} x; x.x[12] = 1; x;});
  ^
t.c:9:22: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2582
 return sizeof({int n = 20; struct {int x[n];} x; x.x[12] = 1; x;});
~~^
0xb93ec7 gimplify_var_or_parm_decl
/ssd/src/gcc/git-svn/gcc/gimplify.c:2582
0xbba91b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11635
0xb8d9ba internal_get_tmp_var
/ssd/src/gcc/git-svn/gcc/gimplify.c:567
0xb8dd96 get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
/ssd/src/gcc/git-svn/gcc/gimplify.c:620
0xb9f95c gimplify_save_expr
/ssd/src/gcc/git-svn/gcc/gimplify.c:5762
0xbb9e44 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11490
0xbb934d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11294
0xbbb651 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11921
0xbb934d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11294
0xb9e1dd gimplify_modify_expr
/ssd/src/gcc/git-svn/gcc/gimplify.c:5457
0xbb8c6d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/ssd/src/gcc/git-svn/gcc/gimplify.c:11192

[Bug middle-end/29887] wrong-code for errno handling on overflow/underflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
When compiled with today's GCC 7 the test case prints the expected result.  Is
there still a problem here or can the bug be resolved as fixed?

$ (set -x && cat t.c && for m in 32 64; do gcc -O2 -Wall
-funsafe-math-optimizations -m$m -lm t.c && ./a.out 5000; done)

+ cat t.c
#include 
#include 
#include 

int main(int argc, char **argv)
{
  double y = atof(argv[1]);
  double x = exp (y);
  printf("%.6e %.6e\n", y, x);
  perror("errno");
  return 0;
}
+ for m in 32 64
+ gcc -O2 -Wall -funsafe-math-optimizations -m32 -lm t.c
+ ./a.out 5000
5.00e+03 inf
errno: Numerical result out of range
+ for m in 32 64
+ gcc -O2 -Wall -funsafe-math-optimizations -m64 -lm t.c
+ ./a.out 5000
5.00e+03 inf
errno: Numerical result out of range

[Bug bootstrap/29741] Fails to build bootstrap under solaris 10, i386

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Resolving as invalid based on comment #2.  Successful Solaris 11 builds have
also been reported on gcc-testresults, most recently here:
https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg02070.html

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Ah, thanks for the reference.  It sounds like GCC should call mpfr_free_cache
before exiting as is recommended in section 4.7 Memory Handling of the MPFR
manual (as I just discovered by searching for the function):

It is strongly advised to do that before terminating a thread, or before
exiting when using tools like ‘valgrind’ (to avoid memory leaks being
reported).

[Bug tree-optimization/79699] small memory leak in MPFR

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The only mpfr_free_cache call I see in GCC is in the Fortran front end.  
Without such a call on exit, leaks in MPFR need not be meaningful.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Also:

modf{f,l}
acos{f,l}
asin{f,l}
atan2{f,l}
cos{f,l}
sin{f,l}
tan{f,l}
cosh{f,l}
sinh{f,l}
tanh{f,l}
exp{f,l}
frexp{f,l}
ldexp{f,l}
log{f,l}
log10{f,l}
pow{f,l}
sqrt{f,l}
ceil{f,l}
floor{f,l}
fmod{f,l}

[Bug libstdc++/79700] New: std::fabsf and std::fabsl missing from

[redi at gcc dot gnu.org]

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

Bug ID: 79700
   Summary: std::fabsf and std::fabsl missing from 
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

using std::fabsf;
using std::fabsl;

abs.cc:3:12: error: ‘std::fabsf’ has not been declared
 using std::fabsf;
^
abs.cc:4:12: error: ‘std::fabsl’ has not been declared
 using std::fabsl;
^

These are required by C++17 (and maybe implicitly by C++11, although it's not
very clear)

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

URL||https://gforge.inria.fr/tra
   ||cker/index.php?func=detail&
   ||aid=21197_id=136
   ||=619

--- Comment #1 from Martin Sebor  ---
I raised MPFR bug report 21197 for this:
https://gforge.inria.fr/tracker/index.php?func=detail=21197_id=136=619

[Bug tree-optimization/79697] unused realloc(0, n) not eliminated

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
It makes sense to convert realloc(0, n) to just malloc and the rest just works.

[Bug tree-optimization/79699] New: small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

Bug ID: 79699
   Summary: small memory leak in MPFR
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The gimple-ssa-sprintf pass seems to trigger a small memory leak in MPFR as the
test case below shows, presumably due to some caching by the library.  The leak
depends on the value on the floating argument and doesn't grow with the number
of sprintf calls or directives processed.

$ cat t.c && gcc -DX=123.4 -S -Wall -Wextra -Wpedantic t.c -wrapper
valgrind,--leak-check=full
int f (void)
{
  return __builtin_snprintf (0, 0, "%f", X);
}
==31067== Memcheck, a memory error detector
==31067== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==31067== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==31067== Command: /ssd/build/gcc-git-svn/gcc/cc1 -quiet -iprefix
/ssd/build/gcc-git-svn/gcc/../lib/gcc/x86_64-pc-linux-gnu/7.0.1/ -isystem
/ssd/build/gcc-git-svn/gcc/include -isystem
/ssd/build/gcc-git-svn/gcc/include-fixed -D X=123.4 t.c -quiet -dumpbase t.c
-mtune=generic -march=x86-64 -auxbase t -Wall -Wextra -Wpedantic -o t.s
==31067== 
==31067== 
==31067== HEAP SUMMARY:
==31067== in use at exit: 1,808,389 bytes in 2,295 blocks
==31067==   total heap usage: 5,473 allocs, 3,178 frees, 3,892,322 bytes
allocated
==31067== 
==31067== 24 bytes in 1 blocks are possibly lost in loss record 13 of 624
==31067==at 0x4C29C4F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31067==by 0x1CB1E22: __gmp_default_allocate (memory.c:54)
==31067==by 0x1C45544: mpfr_init2 (init2.c:55)
==31067==by 0x1C519E5: mpfr_cache (cache.c:61)
==31067==by 0x1C22E0C: mpfr_log (log.c:129)
==31067==by 0x1C4418B: mpfr_log2 (log2.c:119)
==31067==by 0x1C2D916: mpfr_pow (pow.c:566)
==31067==by 0x1C44AC9: mpfr_ui_pow (ui_pow.c:36)
==31067==by 0x1C283FE: floor_log10 (vasprintf.c:825)
==31067==by 0x1C29711: regular_fg (vasprintf.c:1366)
==31067==by 0x1C2A28B: partition_number (vasprintf.c:1598)
==31067==by 0x1C2A69F: sprnt_fp (vasprintf.c:1708)
==31067== 
==31067== 24 bytes in 1 blocks are possibly lost in loss record 14 of 624
==31067==at 0x4C2BB9C: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31067==by 0x1CB1E7C: __gmp_default_reallocate (memory.c:102)
==31067==by 0x1C30F78: mpfr_set_prec (set_prec.c:41)
==31067==by 0x1C51A03: mpfr_cache (cache.c:66)
==31067==by 0x1C22E59: mpfr_log (log.c:131)
==31067==by 0x1C4418B: mpfr_log2 (log2.c:119)
==31067==by 0x1C2D916: mpfr_pow (pow.c:566)
==31067==by 0x1C44AC9: mpfr_ui_pow (ui_pow.c:36)
==31067==by 0x1C283FE: floor_log10 (vasprintf.c:825)
==31067==by 0x1C29711: regular_fg (vasprintf.c:1366)
==31067==by 0x1C2A28B: partition_number (vasprintf.c:1598)
==31067==by 0x1C2A69F: sprnt_fp (vasprintf.c:1708)
==31067== 
==31067== LEAK SUMMARY:
==31067==definitely lost: 0 bytes in 0 blocks
==31067==indirectly lost: 0 bytes in 0 blocks
==31067==  possibly lost: 48 bytes in 2 blocks
==31067==still reachable: 1,808,341 bytes in 2,293 blocks
==31067== suppressed: 0 bytes in 0 blocks
==31067== Reachable blocks (those to which a pointer was found) are not shown.
==31067== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==31067== 
==31067== For counts of detected and suppressed errors, rerun with: -v
==31067== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

[Bug c++/61596] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug c++/79698] spurious -Wunused-local-typedefs on a typedef used by a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
It looks like bug 61596 already tracks this problem.

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

[Bug c++/79698] New: spurious -Wunused-local-typedefs on a typedef used by a template

[msebor at gcc dot gnu.org]

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

Bug ID: 79698
   Summary: spurious -Wunused-local-typedefs on a typedef used by
a template
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues the -Wunused-local-typedefs warning for the typedef defined in
struct B in the function template f() below even though the typedef is used. 
Clang handles this case correctly.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic -Wunused-local-typedefs t.C
template 
struct A {
  typedef typename T::U U;
  U u;
};

template 
T f ()
{
  struct B {
typedef T U;
  };

  return typename A::U ();
}
t.C: In function ‘T f()’:
t.C:11:15: warning: typedef ‘f()::B::U’ locally defined but not used
[-Wunused-local-typedefs]
 typedef T U;
   ^

[Bug c/79691] -Wformat-truncation suppressed by (and only by) -Og

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01480.html

[Bug tree-optimization/79697] unused realloc(0, n) not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79696

--- Comment #2 from Martin Sebor  ---
Bug 79696 tracks the missing warnings.

[Bug tree-optimization/79697] unused realloc(0, n) not eliminated

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Ditto for __builtin_strdup and __builtin_strndup.  Both of those calls can (and
arguably should) be eliminated.  If they're not eliminated (but even if they
are) a warning on them can and arguably should be issued as suggested in bug
79696.

Clang 5.0 eliminates both of the calls but doesn't issue a warning.  Clang does
not, however, eliminate the unused call to realloc in the test case in comment
#1.

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused-result
-fdump-tree-optimized=/dev/stdout t.c
void f (void)
{
  __builtin_strdup ("abc");
}

void g (void)
{
  __builtin_strndup ("abc", 2);
}


;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%]:
  __builtin_strdup ("abc"); [tail call]
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1798, cgraph_uid=1, symbol_order=1)

g ()
{
   [100.00%]:
  __builtin_strndup ("abc", 2); [tail call]
  return;

}

[Bug tree-optimization/79697] New: unused realloc(0, n) not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 79697
   Summary: unused realloc(0, n) not eliminated
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC eliminates calls to allocation functions like malloc and calloc whose
return value is unused but fails to eliminate equivalent calls to realloc:

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused-result
-fdump-tree-optimized=/dev/stdout t.c
void f (void)
{
  __builtin_malloc (123);
}

void g (void)
{
  __builtin_realloc (0, 123);
}

;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1798, cgraph_uid=1, symbol_order=1)

g ()
{
   [100.00%]:
  __builtin_realloc (0B, 123); [tail call]
  return;

}

[Bug c/79696] missing -Wunused-result on calls to malloc() and calloc()

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
-Wunused-result warns on the attribute warn_unused_result usage.  If these
functions are not marked that way in glibc, it is maybe a glibc bug.
I don't think we should mark these as warn_unused_result really.

[Bug c/79696] New: missing -Wunused-result on calls to malloc() and calloc()

[msebor at gcc dot gnu.org]

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

Bug ID: 79696
   Summary: missing -Wunused-result on calls to malloc() and
calloc()
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When optimization is enabled GCC eliminates calls to malloc, calloc, and
aligned_alloc whose result isn't used but it fails to issue a -Wunused-result
warning for them.  It looks like the reason is that the built-ins are not
decorated with attribute warn_unused_result (either in GCC, or, with the
exception of realloc, their public declarations in Glibc).

$ cat u.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused-result
-fdump-tree-optimized=/dev/stdout u.C
void f ([[maybe_unused]] int a [[maybe_unused]])
{
}

;; Function void f() (_Z1fv, funcdef_no=0, decl_uid=2274, cgraph_uid=0,
symbol_order=0)

void f() ()
{
   [100.00%]:
  return;

}



;; Function void g() (_Z1gv, funcdef_no=4, decl_uid=2276, cgraph_uid=1,
symbol_order=1)

void g() ()
{
   [100.00%]:
  return;

}



;; Function void h() (_Z1hv, funcdef_no=6, decl_uid=2278, cgraph_uid=2,
symbol_order=2)

void h() ()
{
   [100.00%]:
  return;

}

[Bug c++/79361] [5/6 Regression] ICE redefining a template function as defaulted or deleted

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |redefining a template   |redefining a template
   |function as defaulted or|function as defaulted or
   |deleted |deleted

--- Comment #3 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/79361] [5/6/7 Regression] ICE redefining a template function as defaulted or deleted

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Feb 23 23:20:58 2017
New Revision: 245692

URL: https://gcc.gnu.org/viewcvs?rev=245692=gcc=rev
Log:
/cp
2017-02-23  Paolo Carlini  

PR c++/79361
* pt.c (register_specialization): Check duplicate_decls return value
for error_mark_node and pass it back.

/testsuite
2017-02-23  Paolo Carlini  

PR c++/79361
* g++.dg/cpp0x/pr79361-1.C: New.
* g++.dg/cpp0x/pr79361-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79361-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr79361-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek  ---
An alternative, and hopefully still valid testcase:

struct A
{
  char c;
};

int main()
{
  static char A::* q;
  A a;
  return &(a.*q) - 
}

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 23 22:05:19 2017
New Revision: 245690

URL: https://gcc.gnu.org/viewcvs?rev=245690=gcc=rev
Log:
PR tree-optimization/79389
* ifcvt.c (struct noce_if_info): Add rev_cond field.
(noce_reversed_cond_code): New function.
(noce_emit_store_flag): Use rev_cond if non-NULL instead of
reversed_comparison_code.  Formatting fix.
(noce_try_store_flag): Test rev_cond != NULL in addition to
reversed_comparison_code.
(noce_try_store_flag_constants): Likewise.
(noce_try_store_flag_mask): Likewise.
(noce_try_addcc): Use rev_cond if non-NULL instead of
reversed_comparison_code.
(noce_try_cmove_arith): Likewise.  Formatting fixes.
(noce_try_minmax, noce_try_abs): Clear rev_cond.
(noce_find_if_block): Initialize rev_cond.
(find_cond_trap): Call noce_get_condition with then_bb == trap_bb
instead of false as last argument never attempt to reverse it
afterwards.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c

[Bug tree-optimization/79663] [7 Regression] r244815 causes 10% regression for spec1k/172.mgrid on AArch64

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Fixed by Bin's patch on the trunk.

[Bug tree-optimization/79663] [7 Regression] r244815 causes 10% regression for spec1k/172.mgrid on AArch64

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Thu Feb 23 22:02:01 2017
New Revision: 245689

URL: https://gcc.gnu.org/viewcvs?rev=245689=gcc=rev
Log:
2017-01-21  Bin Cheng  

PR tree-optimization/79663
* tree-predcom.c (combine_chains): Process refs in reverse order
only for ZERO length chains, and add explaining comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/79578] Unnecessary instructions in generated code

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Thu Feb 23 21:43:03 2017
New Revision: 245688

URL: https://gcc.gnu.org/viewcvs?rev=245688=gcc=rev
Log:
PR tree-optimization/79578
* tree-ssa-dse.c (clear_bytes_written_by): Use OEP_ADDRESS_OF
in call to operand_equal_p.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
Note this was extracted from the main motivator for path splitting, so it's
probably wise to make sure we get this right.

The key is blob of code:

for ()
  {
 ...
 if (bufferstep)
outputbuffer = (delta << 4) & 0xf0;
  else
*outp++ = (delta & 0x0f) | outputbuffer;
  bufferstep = !bufferstep;
  }

Path splitting essentially turns that into:


for ()
  {
 ...
 if (bufferstep)
   {
 outputbuffer = (delta << 4) & 0xf0;
 bufferstep = !bufferstep;
   }
  else
   {
 *outp++ = (delta & 0x0f) | outputbuffer;
 bufferstep = !bufferstep;
   }
  }

DOM should know that bufferstep has the range [0,1] and thus can record a path
sensitive equivalence for bufferstep on both arms resulting in:


for ()
  {
 ...
 if (bufferstep)
   {
 outputbuffer = (delta << 4) & 0xf0;
 bufferstep = 0;
   }
  else
   {
 *outp++ = (delta & 0x0f) | outputbuffer;
 bufferstep = 1;
   }
  }

And we propagate the assignment to bufferstep away into a PHI node.

As long as we preserve that (simplification of the xor), we're good.

Long term we'd like to thread the if (bufferstep) test since bufferstep is just
a flip-flop and the state for every iteration can be known at compile time. 
BUt that's a future TODO.  Again, preserve the ability to simplify the
assignment to bufferstep at the bottom of the loop and we're good.

[Bug target/79636] [5/6/7 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P2  |P4

[Bug c++/79695] spurious -Wunused-variable on a static global of a type declared unused

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79667,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79585,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79548,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71456,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44648

--- Comment #2 from Martin Sebor  ---
See bug 79667, bug 79585, bug 79548, bug 71456, and bug 44648 for other issues
related to -Wunused-variable.

[Bug c++/79695] spurious -Wunused-variable on a static global of a type declared unused

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
Let me correct that: GCC warns on the first two variables, not on the local one
defined in function g().  It used to warn on it until r145440.

[Bug c++/79695] New: spurious -Wunused-variable on a static global of a type declared unused

[msebor at gcc dot gnu.org]

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

Bug ID: 79695
   Summary: spurious -Wunused-variable on a static global of a
type declared unused
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ (but not GCC in C mode) warns on all three variables in the program below
even though their type is declared attribute unused and thus no warning should
be issued for them.

In addition, the wording of the warning is inconsistent.  It should be the same
in both cases.  The first instance is issued by the C++ front end and the
latter two come from cgraphunit.c.

$ (set -x && cat u.c && for lang in c c++; do gcc -S -Wall -Wextra -Wpedantic
-x$lang u.c; done)
+ cat u.c
typedef int __attribute__ ((unused)) T;

static T x;

void f (void)
{
  static T y;
}

void g (void)
{
  T z;
}

+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -xc u.c
+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -xc++ u.c
u.c: In function ‘void f()’:
u.c:7:12: warning: unused variable ‘y’ [-Wunused-variable]
   static T y;
^
u.c: At global scope:
u.c:7:12: warning: ‘y’ defined but not used [-Wunused-variable]
u.c:3:10: warning: ‘x’ defined but not used [-Wunused-variable]
 static T x;
  ^

[Bug target/79268] [6/7 Regression] Wrong code generation for vec_xl and vec_xst intrinsics

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Feb 23 19:29:40 2017
New Revision: 245687

URL: https://gcc.gnu.org/viewcvs?rev=245687=gcc=rev
Log:
2017-02-23  Bill Schmidt  

PR target/79268
* gcc.target/powerpc/pr79268.c: Enable for BE targets also.


Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr79268.c

[Bug c++/79689] ICE with trailing return type

[mwarusz at gmail dot com]

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

--- Comment #3 from Maciej Waruszewski  ---
Full output that I'm getting:

*** buffer overflow detected ***:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus terminated
=== Backtrace: =
/usr/lib/libc.so.6(+0x70c4b)[0x7f2742ab2c4b]
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f2742b3af17]
/usr/lib/libc.so.6(+0xf7050)[0x7f2742b39050]
/usr/lib/libc.so.6(+0xf6609)[0x7f2742b38609]
/usr/lib/libc.so.6(_IO_default_xsputn+0xac)[0x7f2742ab6c6c]
/usr/lib/libc.so.6(_IO_vfprintf+0xcd3)[0x7f2742a89a73]
/usr/lib/libc.so.6(__vsprintf_chk+0x8c)[0x7f2742b3869c]
/usr/lib/libc.so.6(__sprintf_chk+0x7d)[0x7f2742b385ed]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x705bcd]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x70d6dd]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x709adc]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x70bfb8]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x70e696]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x70f76e]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(_Z11mangle_declP9tree_node+0x9c)[0x70f8ec]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(_Z19decl_assembler_nameP9tree_node+0x2a)[0xcf099a]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0x7fa5cb]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(_ZN12symbol_table25finalize_compilation_unitEv+0x59)[0x7fb669]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus[0xb08fd5]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(_ZN6toplev4mainEiPPc+0x6d4)[0x5fda54]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(main+0x27)[0x5ffc27]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f2742a62291]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus(_start+0x2a)[0x60002a]
=== Memory map: 
0040-01bca000 r-xp  00:14 6328766   
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus
01dca000-01dd r--p 017ca000 00:14 6328766   
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus
01dd-01ddd000 rw-p 017d 00:14 6328766   
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/cc1plus
01ddd000-01f2d000 rw-p  00:00 0 
01fb6000-02091000 rw-p  00:00 0  [heap]
7f2742579000-7f274258f000 r-xp  00:14 6306516   
/usr/lib/libgcc_s.so.1
7f274258f000-7f274278e000 ---p 00016000 00:14 6306516   
/usr/lib/libgcc_s.so.1
7f274278e000-7f274278f000 r--p 00015000 00:14 6306516   
/usr/lib/libgcc_s.so.1
7f274278f000-7f274279 rw-p 00016000 00:14 6306516   
/usr/lib/libgcc_s.so.1
7f27427c2000-7f2742a42000 rw-p  00:00 0 
7f2742a42000-7f2742bd7000 r-xp  00:14 4243191   
/usr/lib/libc-2.24.so
7f2742bd7000-7f2742dd6000 ---p 00195000 00:14 4243191   
/usr/lib/libc-2.24.so
7f2742dd6000-7f2742dda000 r--p 00194000 00:14 4243191   
/usr/lib/libc-2.24.so
7f2742dda000-7f2742ddc000 rw-p 00198000 00:14 4243191   
/usr/lib/libc-2.24.so
7f2742ddc000-7f2742de rw-p  00:00 0 
7f2742de-7f2742ee3000 r-xp  00:14 4243245   
/usr/lib/libm-2.24.so
7f2742ee3000-7f27430e2000 ---p 00103000 00:14 4243245   
/usr/lib/libm-2.24.so
7f27430e2000-7f27430e3000 r--p 00102000 00:14 4243245   
/usr/lib/libm-2.24.so
7f27430e3000-7f27430e4000 rw-p 00103000 00:14 4243245   
/usr/lib/libm-2.24.so
7f27430e4000-7f27430fa000 r-xp  00:14 6306412   
/usr/lib/libz.so.1.2.11
7f27430fa000-7f27432f9000 ---p 00016000 00:14 6306412   
/usr/lib/libz.so.1.2.11
7f27432f9000-7f27432fa000 r--p 00015000 00:14 6306412   
/usr/lib/libz.so.1.2.11
7f27432fa000-7f27432fb000 rw-p 00016000 00:14 6306412   
/usr/lib/libz.so.1.2.11
7f27432fb000-7f27432fd000 r-xp  00:14 4243244   
/usr/lib/libdl-2.24.so
7f27432fd000-7f27434fd000 ---p 2000 00:14 4243244   
/usr/lib/libdl-2.24.so
7f27434fd000-7f27434fe000 r--p 2000 00:14 4243244   
/usr/lib/libdl-2.24.so
7f27434fe000-7f27434ff000 rw-p 3000 00:14 4243244   
/usr/lib/libdl-2.24.so
7f27434ff000-7f2743591000 r-xp  00:14 6147841   
/usr/lib/libgmp.so.10.3.2
7f2743591000-7f274379 ---p 00092000 00:14 6147841   
/usr/lib/libgmp.so.10.3.2
7f274379-7f2743791000 r--p 00091000 00:14 6147841   
/usr/lib/libgmp.so.10.3.2
7f2743791000-7f2743792000 rw-p 00092000 00:14 6147841   
/usr/lib/libgmp.so.10.3.2
7f2743792000-7f27437f3000 r-xp  00:14 6147854   
/usr/lib/libmpfr.so.4.1.5
7f27437f3000-7f27439f2000 ---p 00061000 00:14 6147854   
/usr/lib/libmpfr.so.4.1.5
7f27439f2000-7f27439f4000 r--p 0006 00:14 6147854   
/usr/lib/libmpfr.so.4.1.5
7f27439f4000-7f27439f5000 rw-p 00062000 00:14 6147854   

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
I see, thanks for pointing that out.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[reichelt at gcc dot gnu.org]

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

--- Comment #16 from Volker Reichelt  ---
According to [expr.mptr.oper] the code in comment 15 has undefined behavior,
because the second operand of ->* is the null-pointer-to-member-value.

[Bug target/79636] [5/6/7 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
The bug is also present in GCC-4.7 which uses the old reload pass.  But GCC-4.4
works ok on the test.

The culprit is in udivmod.  GCC-4.4 generates a shift instead of udivmod
generated by GCC-4.7 and the trunk.

As for more accurate live analysis based on partial availability.  It was
implemented in global.c 15 years ago.  Unfortunately, it created more problems
than solutions and was removed in a short time.  DF-infastructure has analogous
code (DF_LIVE problem) but it is not used for the same reasons (I remember
people tried this too in global.c).

So the simplest solution would be generating the shift for -O0 too.  Another
alternative is to implement hard reg live range splitting in LRA for this case
but it would be a dangerous approach when we are close to the release.

The code is very questionable to me.  I'd never use dx for register variable in
a real program as it is used by an integer div/mod.

I don't think it should be a P2 or even P3 bug.

[Bug c/79692] -Wformat-overflow false positive?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  A small test case is below.  When an integer directive's argument
is in a known range the checker assumes the result of the directive is also in
a known range even if the width or precision is not.  When the range of the
directive's output is known the checker uses its upper bound to determine
whether or not to warn, even at level 1.

The solution (until this is fixed) is to constrain the width (or precision)
range, e.g., by adding the following above the sprintf call.

  if (w < 0 || w > 7)
__builtin_unreachable ();

$ cat u.c && gcc -O2 -S -Wall -Wunused -Wpedantic
-fdump-tree-printf-return-value=/dev/stdout u.c
char d[8];

void f (int w, unsigned x)
{
  if (x > 9)
x = 0;

  __builtin_sprintf (d, "%*x", w, x);
}


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

u.c:8: __builtin_sprintf: objsize = 8, fmtstr = "%*x"
  Directive 1 at offset 0: "%*x", width in range [0, 2147483648]
u.c: In function ‘f’:
u.c:8:26: warning: ‘%*x’ directive writing between 1 and 2147483648 bytes into
a region of size 8 [-Wformat-overflow=]
   __builtin_sprintf (d, "%*x", w, x);
  ^~~
u.c:8:25: note: directive argument in the range [0, 9]
   __builtin_sprintf (d, "%*x", w, x);
 ^
Result: 1, 2147483648, 2147483648, 2147483648 (1, 2147483648, 2147483648,
2147483648)
  Directive 2 at offset 3: "", length = 1
u.c:8:3: note: ‘__builtin_sprintf’ output between 2 and 2147483649 bytes into a
destination of size 8
   __builtin_sprintf (d, "%*x", w, x);
   ^~

f (int w, unsigned int x)
{
   [100.00%]:
  if (x_2(D) > 9)
goto ; [54.00%]
  else
goto ; [46.00%]

   [54.00%]:

   [100.00%]:
  # x_1 = PHI 
  __builtin_sprintf (, "%*x", w_4(D), x_1);
  return;

}

[Bug testsuite/79455] c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with r244854 (where it was activated)

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
I think the most relevant issue here is that we are usually generating a call
to memset here, but apparently on rare occasions we do not.  That kind of
inconsistency is troubling, to say the least.

As Segher said elsewhere, though, this test may require -fno-builtin-memset to
give consistent results on POWER.

[Bug testsuite/79455] c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with r244854 (where it was activated)

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #1 from kelvin at gcc dot gnu.org ---
As of today (svn revision 245252), I'm seeing intermittent success.  This
turned up during routine regression testing of a proposed patch.  Consistently,
the bootstrapped gcc version before my patch was applied succeeds.  Here is an
excerpt from that gcc.log file:

==  
WARNING: ThreadSanitizer: data race (pid=104133)
  Atomic read of size 1 at 0x100200d8 by thread T2: 
#0 pthread_mutex_lock
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/libs\
anitizer/sanitizer_common/sanitizer_common_interceptors.inc:3607
(libtsan.so.0+\
0x000446a4) 
#1 Thread2
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/gcc/testsuite/c\
-c++-common/tsan/race_on_mutex.c:22 (race_on_mutex.exe+0x1e84)  

  Previous write of size 1 at 0x100200d8 by thread T1:  
#0 pthread_mutex_init
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/libs\
anitizer/tsan/tsan_interceptors.cc:1117 (libtsan.so.0+0x0002d1f8)   
#1 Thread1
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/gcc/testsuite/c\
-c++-common/tsan/race_on_mutex.c:12 (race_on_mutex.exe+0x1d54)  

  Location is global 'Mtx' of size 40 at 0x100200d8
(race_on_mutex.exe+0x00\
00100200d8) 

  Thread T2 (tid=104335, running) created by main thread at:
#0 pthread_create
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/libsanit\
izer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x0002c53c)
#1 main
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/gcc/testsuite/c-c+\
+-common/tsan/race_on_mutex.c:32 (race_on_mutex.exe+0x1f70)

  Thread T1 (tid=104334, finished) created by main thread at:
#0 pthread_create
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/libsanit\
izer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x0002c53c)
#1 main
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4patch/gcc/testsuite/c-c+\
+-common/tsan/race_on_mutex.c:31 (race_on_mutex.exe+0x1f50)

SUMMARY: ThreadSanitizer: data race
/home/kelvin/gcc-root/gcc-trunk4ltc92025.b4\
patch/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c:22 in Thread2
==
ThreadSanitizer: reported 1 warnings
PASS: c-c++-common/tsan/race_on_mutex.c   -O0  execution test
PASS: c-c++-common/tsan/race_on_mutex.c   -O0  output pattern test, WARNING:
Th\
readSanitizer: data race.*(
|^M
|^M)  Atomic read of size 1 at .* by thread T2:(
|^M
|^M)#0 pthread_mutex_lock.*#1 Thread2.* .*(race_on_mutex.c:22|\?{2}:0)
\
(.*)  Previous write of size 1 at .* by thread T1:(
|^M
|^M)#0 pthread_mutex_init .* (.)*#1 Thread1.*
.*(race_on_mutex.c:12|\?{\
2}:0) .*

With the gcc.log output for the version of gcc that has my patch, this test is
consistently failing.  The relevant part of the trace output on the version
that fails is quoted below.  Note that the "previous write was of size 8"
instead of size 1, which is what the dg-output directive is looking for.

==
WARNING: ThreadSanitizer: data race (pid=36311)
  Atomic read of size 1 at 0x100200d8 by thread T2:
#0 pthread_mutex_lock
/home/kelvin/gcc-root/gcc-trunk4ltc92025/libsanitizer\
/sanitizer_common/sanitizer_common_interceptors.inc:3607
(libtsan.so.0+0x00\
044704)
#1 Thread2
/home/kelvin/gcc-root/gcc-trunk4ltc92025/gcc/testsuite/c-c++-com\
mon/tsan/race_on_mutex.c:22 (race_on_mutex.exe+0x1f24)

  Previous write of size 8 at 0x100200d8 by thread T1:
#0 memset
/home/kelvin/gcc-root/gcc-trunk4ltc92025/libsanitizer/sanitizer_c\
ommon/sanitizer_common_interceptors.inc:558 (libtsan.so.0+0x00036154)
#1 pthread_mutex_init  (libpthread.so.0+0xb61c)
#2 Thread1
/home/kelvin/gcc-root/gcc-trunk4ltc92025/gcc/testsuite/c-c++-com\
mon/tsan/race_on_mutex.c:12 (race_on_mutex.exe+0x1df4)

  Location is global 'Mtx' of size 40 at 0x100200d8
(race_on_mutex.exe+0x00\
00100200d8)

  Thread T2 (tid=36382, running) created by main thread at:
#0 pthread_create
/home/kelvin/gcc-root/gcc-trunk4ltc92025/libsanitizer/tsa\
n/tsan_interceptors.cc:900 (libtsan.so.0+0x0002c59c)
#1 main
/home/kelvin/gcc-root/gcc-trunk4ltc92025/gcc/testsuite/c-c++-common\
/tsan/race_on_mutex.c:32 (race_on_mutex.exe+0x10001010)

  Thread T1 (tid=36378, finished) created by main thread at:
#0 pthread_create
/home/kelvin/gcc-root/gcc-trunk4ltc92025/libsanitizer/tsa\
n/tsan_interceptors.cc:900 

[Bug c/79693] New: Memory buffer handling - additional optimization proposal

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 79693
   Summary: Memory buffer handling - additional optimization
proposal
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

I have checked how gcc treats temporary buffers allocated in different ways
(local buffer on stack, malloced locally in function, malloced outside and
passed via argument) and found that gcc could do better work there. I have few
proposals how to make things better:

1. Introduce __builtin_assume_temporary(ptr) and/or __attribute__((temporary))
which will tell gcc that given function argument or variable is a temporary
buffer and its contents after function execution will not be used. By doing so
gcc could treat it as if it was allocated locally in function and optimize out
unnecessary memory writes.

2. One of function versions used malloc() to allocate buffer of constant size
at beginning of function, and free() to delete it at the end. When this
function was inlined and called twice, its body was inserted twice in my code.
Other function versions with buffer on stack or malloced outside and passed via
argument were inserted once. I am not sure if this is some bug or feature,
someone familiar with this should check it.

3. If there is valid reason to actually duplicate this code (e.g. loop
unrolling), gcc could detect that code calls malloc and free in loop and
repeatedly allocate/free buffer of the same size. In such case gcc could
optimize this to call malloc and free once. If someone will use calloc, gcc
could simply clear buffer before each loop iteration.

I tested this with gcc 5.4.0 shipped by default in Cygwin 64 bit. Test code
used by me is below.

Code:

#include 
#include 

#define CNT 4

#define ATTR_INLINE __attribute__((hot, always_inline)) static inline
//#define ATTR_INLINE

ATTR_INLINE int func_1(int* data)
{
int buff[CNT * CNT];

for (int i = 0; i < CNT; ++i)
{
for (int j = 0; j < CNT; ++j)
{
buff[i * CNT + j] = data[i];
}
}

for (int n = 0; n < CNT; ++n)
{
for (int i = 0; i < n; ++i)
{
for (int j = 0; j < n; ++j)
{
buff[i * CNT + j] = buff[(i+1) * CNT + j] + buff[i * CNT +
j+1];
}
}
}

return buff[0];
}

ATTR_INLINE int func_2(int* data)
{
int* buff = (int*)malloc(CNT * CNT * sizeof(int));

for (int i = 0; i < CNT; ++i)
{
for (int j = 0; j < CNT; ++j)
{
buff[i * CNT + j] = data[i];
}
}

for (int n = 0; n < CNT; ++n)
{
for (int i = 0; i < n; ++i)
{
for (int j = 0; j < n; ++j)
{
buff[i * CNT + j] = buff[(i+1) * CNT + j] + buff[i * CNT +
j+1];
}
}
}

int result = buff[0];
free(buff);
return result;
}

ATTR_INLINE int func_3(int* __restrict__ data, int* __restrict__ buff)
{
for (int i = 0; i < CNT; ++i)
{
for (int j = 0; j < CNT; ++j)
{
buff[i * CNT + j] = data[i];
}
}

for (int n = 0; n < CNT; ++n)
{
for (int i = 0; i < n; ++i)
{
for (int j = 0; j < n; ++j)
{
buff[i * CNT + j] = buff[(i+1) * CNT + j] + buff[i * CNT +
j+1];
}
}
}

return buff[0];
}

ATTR_INLINE int func_4(int* data, int* buff)
{
for (int i = 0; i < CNT; ++i)
{
for (int j = 0; j < CNT; ++j)
{
buff[i * CNT + j] = data[i];
}
}

for (int n = 0; n < CNT; ++n)
{
for (int i = 0; i < n; ++i)
{
for (int j = 0; j < n; ++j)
{
buff[i * CNT + j] = buff[(i+1) * CNT + j] + buff[i * CNT +
j+1];
}
}
}

return buff[0];
}

int main()
{
int* data = (int*)malloc(CNT * sizeof(int));
int* buff = (int*)malloc(CNT * sizeof(int));
for (int n = 0; n < CNT; ++n)
data[n] = rand();

int sum = 0;
printf("1");
sum += func_1(data);
sum += func_1(data);
printf("2");
sum += func_2(data);
sum += func_2(data);
printf("3");
sum += func_3(data, buff);
sum += func_3(data, buff);
printf("4");
sum += func_4(data, buff);
sum += func_4(data, buff);
printf("4");

return sum;
}

[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu
   ||hppa*-*-hpux*
   Priority|P3  |P4

--- Comment #6 from Bill Schmidt  ---
So for POWER, this is just showing that old versions of glibc have a problem. 
So we can't XFAIL it because that will break for newer versions of glibc.  Thus
we have no plans to make any changes here; we'll just tolerate the FAIL on
older systems.

Leaving the bug open for hppa*-*-hpux* in case they want to use it for
tracking.  John David, please close whenever you have a resolution for those
targets.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Slightly reduced original testcase:

struct A
{
  char c;
};

int main()
{
  static char A::* const q = nullptr;
  A a;
  return &(a.*q) - 
}

[Bug middle-end/79396] [5/6/7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE  |[5/6/7 Regression] ICE
   |(verify_flow_info failed)   |(verify_flow_info failed)
   |with -fnon-call-exceptions  |with -fnon-call-exceptions
   |-O2 |-O2 -march=haswell

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Martin Liška from comment #9)
> Confirmed with: g++ pr79396.c -fnon-call-exceptions -O2 -march=haswell -c
> -std=c++11

Thanks. I can also confirm that removing -march=haswell from my configure line
avoids the ICE.

[Bug c++/79689] ICE with trailing return type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-23
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Same for me.

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #19 from Nick Clifton  ---
Excellent - in which case I will close this PR.

[Bug c/79691] -Wformat-truncation suppressed by (and only by) -Og

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-23
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed for the missing diagnostic
(https://gcc.gnu.org/ml/gcc/2017-02/msg00105.html).

It's a also a missed optimization because, as can be seen in the test case
below, the sprintf return value optimization isn't done:

$ (set -x && cat t.c && for O in 1 g; do gcc -O$O -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c; done)
+ cat t.c
int f (void)
{
  return __builtin_snprintf (0, 0, "%i", 123);
} 
+ for O in 1 g
+ gcc -O1 -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout t.c

;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%]:
  return 3;

}


+ for O in 1 g
+ gcc -Og -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout t.c

;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f ()
{
  int _3;

   [100.00%]:
  _3 = __builtin_snprintf (0B, 0, "%i", 123);
  return _3;

}

[Bug c/79692] New: -Wformat-overflow false positive?

[sirl at gcc dot gnu.org]

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

Bug ID: 79692
   Summary: -Wformat-overflow false positive?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

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

With trunk r245678 on x86_64 the attached testcase prints these warnings:

gcc-trunk -Wformat-overflow -O2 -c test-sprintf-2.c 
test-sprintf-2.c: In function 'test':
test-sprintf-2.c:90:32: warning: '%0*lX' directive writing between 1 and
2147483648 bytes into a region of size 76 [-Wformat-overflow=]
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
^
test-sprintf-2.c:90:24: note: directive argument in the range [0,
4611686018427387904]
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
^~~~
test-sprintf-2.c:90:24: note: directive argument in the range [0,
4611686018427387904]
test-sprintf-2.c:90:7: note: 'sprintf' output 9 or more bytes (assuming
4294967303) into a destination of size 80
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
   ^
 (uint64_t) from, reg, sTo, nTo, (uint64_t) to);
 ~~
test-sprintf-2.c:109:29: warning: '%0*lX' directive writing between 1 and
2147483648 bytes into a region of size 76 [-Wformat-overflow=]
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
 ^
test-sprintf-2.c:109:21: note: directive argument in the range [0,
4611686018427387904]
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
 ^~~~
test-sprintf-2.c:109:4: note: 'sprintf' output 8 or more bytes (assuming
2147483655) into a destination of size 80
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
^
  (uint64_t) from, nLen, (uint64_t) len);
  ~~

To me it seems it shouldn't warn. PR 79275 looks like a variant of this problem
and was already fixed.

[Bug c/79691] New: -Wformat-truncation suppressed by (and only by) -Og

[sbergman at redhat dot com]

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

Bug ID: 79691
   Summary: -Wformat-truncation suppressed by (and only by) -Og
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:

> $ cat test.c
> #include 
> int main() {
> char buf[3];
> snprintf(buf, sizeof buf, "%s", "foo");
> return 0;
> }
> $ gcc -Wformat-truncation -Og ~/test.c
> $ gcc -Wformat-truncation -O ~/test.c
> test.c: In function ‘main’:
> test.c:4:34: warning: ‘snprintf’ output truncated before the last
> format character [-Wformat-truncation=]
>  snprintf(buf, sizeof buf, "%s", "foo");
>   ^
> test.c:4:5: note: ‘snprintf’ output 4 bytes into a destination of size 3
>  snprintf(buf, sizeof buf, "%s", "foo");
>  ^~

Any other optimization level (-O0..3/s/fast) does emit the warning.

(See mail thread starting at 
"New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?".)

[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> But an extra assert like the following triggers during bootstrap so we can't
> really avoid the casting (in all cases).
> 
> Index: gcc/tree-ssa-address.c
> ===
> --- gcc/tree-ssa-address.c  (revision 245681)
> +++ gcc/tree-ssa-address.c  (working copy)
> @@ -708,6 +702,9 @@ create_mem_ref (gimple_stmt_iterator *gs
>tree mem_ref, tmp;
>struct mem_address parts;
>  
> +  if (base_hint)
> +gcc_assert (POINTER_TYPE_P (TREE_TYPE (base_hint)));
> +
>addr_to_parts (type, addr, iv_cand, base_hint, , speed);
>gimplify_mem_ref_parts (gsi, );
>mem_ref = create_mem_ref_raw (type, alias_ptr_type, , true);
> 
> OTOH it looks harmless for a few cases I tried (the base_hint won't match
> in the search for it).  Testing w/o that assert.

Ok, so we'd move an integer to ->base and then later when building the
TARGET_MEM_REF we'd refuse that base and do

  else if (addr->base
   && POINTER_TYPE_P (TREE_TYPE (addr->base)))
{
  base = addr->base;
  index2 = NULL_TREE;
}
  else
{
  base = build_int_cst (build_pointer_type (type), 0);
  index2 = addr->base;
}

which cost-wide wasn't expected?  It's probably also not a good idea
in general to generate a zero-based TARGET_MEM_REF

It's also against the very first check:

  if (verify
  && !valid_mem_ref_p (TYPE_MODE (type), TYPE_ADDR_SPACE (type), addr))
return NULL_TREE;

which btw also uses a bogus type to get the address-space from.

So I think a better fix would be to ensure that TREE_TYPE (mem-ref) has
the same address-space as its pointed-to type in operand 0 ...

[Bug middle-end/79665] gcc's signed (x*x)/200 is slower than clang's

[tulipawn at gmail dot com]

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

--- Comment #13 from PeteVine  ---
Still, the 5% regression must have happened very recently. The fast gcc was
built on 20170220 and the slow one yesterday, using the original patch. Once
again, switching away from Cortex-A53 codegen restores the expected
performance.

[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

[krebbel at gcc dot gnu.org]

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

--- Comment #15 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Feb 23 15:18:16 2017
New Revision: 245684

URL: https://gcc.gnu.org/viewcvs?rev=245684=gcc=rev
Log:
PR 68749: S/390: Disable ifcvt-4.c for -m31.

gcc/testsuite/ChangeLog:

2017-02-23  Dominik Vogt  

PR 68749
* gcc.dg/ifcvt-4.c: Disable for -m31, use -march=z196.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ifcvt-4.c

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
Traveling now, back home end of March.
Did you check the value of variable "len" maybe it's zero so it's not
really a bug.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #14 from Marek Polacek  ---
Ah, I see cp_convert_to_pointer does

 212   /* A NULL pointer-to-data-member is represented by -1, not by
 213  zero.  */
 214   tree val = (TYPE_PTRDATAMEM_P (type)
 215   ? build_int_cst_type (type, -1)
 216   : build_int_cst (type, 0));

[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
But an extra assert like the following triggers during bootstrap so we can't
really avoid the casting (in all cases).

Index: gcc/tree-ssa-address.c
===
--- gcc/tree-ssa-address.c  (revision 245681)
+++ gcc/tree-ssa-address.c  (working copy)
@@ -708,6 +702,9 @@ create_mem_ref (gimple_stmt_iterator *gs
   tree mem_ref, tmp;
   struct mem_address parts;

+  if (base_hint)
+gcc_assert (POINTER_TYPE_P (TREE_TYPE (base_hint)));
+
   addr_to_parts (type, addr, iv_cand, base_hint, , speed);
   gimplify_mem_ref_parts (gsi, );
   mem_ref = create_mem_ref_raw (type, alias_ptr_type, , true);

OTOH it looks harmless for a few cases I tried (the base_hint won't match
in the search for it).  Testing w/o that assert.

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #40818|0   |1
is obsolete||

--- Comment #16 from Richard Biener  ---
Created attachment 40819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40819=edit
revised patch

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Uh.  (sizetype) q is folded to -1 in constant_value_1.  DECL_INITIAL of "q" is
-1, that's what build_zero_init_1 did:
 177   else if (TYPE_PTR_OR_PTRMEM_P (type))
 178 init = fold (convert (type, nullptr_node));
type is offset_type.  Why is nullptr_node converted to offset_type -1?!

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Richard Biener from comment #14)
> Created attachment 40818 [details]
> patch
> 
> Patch I am testing for the loop splitting cost model.  I still believe loop
> splitting on its own is not profitable and it should be integrated with
> threading and CSE.

It regresses

FAIL: gcc.dg/tree-ssa/pr69270.c scan-tree-dump-not dom3 "bit_xor"
FAIL: gcc.dg/tree-ssa/pr69270.c scan-tree-dump-times dom3 "Folded to: _[0-9]+ =
0;" 1
FAIL: gcc.dg/tree-ssa/pr69270.c scan-tree-dump-times dom3 "Folded to: _[0-9]+ =
1;" 1
FAIL: gcc.dg/tree-ssa/pr69270.c scan-tree-dump-times dom3 "Replaced
.bufferstep_[0-9]+. with constant .0." 1
FAIL: gcc.dg/tree-ssa/pr69270.c scan-tree-dump-times dom3 "Replaced
.bufferstep_[0-9]+. with constant .1." 1

this testcase wants to "thread"

   if (bufferstep != 0)
...
   bufferstep ^= 1;

once which the backward threading code does only if we first split the path.
This effectively rotates the loop.  The threading doesn't seem to matter
though, what matters is the xor that can be conditionally simplified.

Thus another "enabler" for path splitting would be

  if (x ==/!= CST)
...
  use-of-x;

so we can constant propagate.

[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
This is similar to PR66768 but is somewhat special because the vectorizer
generates

 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x768ba348
precision 8 min  max >
unsigned V16QI
size 
unit size 
align 128 symtab 0 alias set 0 canonical type 0x769c3738 nunits 16
pointer_to_this >

arg 0 

thus the address-space is _only_ on the pointer operand (generally RTL
expansion
looks at the reference type, MEM_REF and TARGET_MEM_REF are special-cased
though).

And IVOPTs does:

7395  ref = create_mem_ref (, TREE_TYPE (*use->op_p), ,
7396reference_alias_ptr_type (*use->op_p),
7397iv, base_hint, data->speed);
7398  copy_ref_info (ref, *use->op_p);

and TREE_TYPE (*use->op_p) is the type of the reference, not the pointer
type of the base (and create_mem_ref builds a "bogus" pointer type from that).

The issue is that addr-to-parts via move_hint_to_base builds a new pointer
type, converting the pointer to the generic address-space.  In this case
it's a matter of preserving the correct info:

Index: gcc/tree-ssa-address.c
===
--- gcc/tree-ssa-address.c  (revision 245681)
+++ gcc/tree-ssa-address.c  (working copy)
@@ -435,7 +435,7 @@ move_fixed_address_to_symbol (struct mem
 /* If ADDR contains an instance of BASE_HINT, move it to PARTS->base.  */

 static void
-move_hint_to_base (tree type, struct mem_address *parts, tree base_hint,
+move_hint_to_base (struct mem_address *parts, tree base_hint,
   aff_tree *addr)
 {
   unsigned i;
@@ -455,13 +455,7 @@ move_hint_to_base (tree type, struct mem
   if (i == addr->n)
 return;

-  /* Cast value to appropriate pointer type.  We cannot use a pointer
- to TYPE directly, as the back-end will assume registers of pointer
- type are aligned, and just the base itself may not actually be.
- We use void pointer to the type's address space instead.  */
-  qual = ENCODE_QUAL_ADDR_SPACE (TYPE_ADDR_SPACE (type));
-  type = build_qualified_type (void_type_node, qual);
-  parts->base = fold_convert (build_pointer_type (type), val);
+  parts->base = val;
   aff_combination_remove_elt (addr, i);
 }

@@ -663,7 +657,7 @@ addr_to_parts (tree type, aff_tree *addr
  there is no reliable way how to distinguish between pointer and its
  offset, this is just a guess.  */
   if (!parts->symbol && base_hint)
-move_hint_to_base (type, parts, base_hint, addr);
+move_hint_to_base (parts, base_hint, addr);
   if (!parts->symbol && !parts->base)
 move_pointer_to_base (parts, addr);

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||33056

--- Comment #6 from Dominique d'Humieres  ---
I cannot reproduce this PR even with an instrumented compiler. How do you get
the error?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug 33056] [Meta-bug] Data - statement related bugs

[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 CC||amker at gcc dot gnu.org
Summary|Vectorizer drops gs: prefix |IVOPTs drops gs: prefix
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, but it's IVOPTs, not the vectorizer.  -fno-ivopts fixes it.

[Bug tree-optimization/79690] New: Vectorizer drops gs: prefix

[me at manueljacob dot de]

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

Bug ID: 79690
   Summary: Vectorizer drops gs: prefix
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: me at manueljacob dot de
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

void fill(unsigned char __seg_gs *arr, unsigned char c, long n) {
for (long i = 0; i < n; ++i)
arr[i] = c;
}

On x86-64, gcc -O3 emits this instruction, missing the gs: prefix:

movaps  %xmm0, -16(%rcx)

[Bug fortran/66328] Wrong initialization of derived-type DATA

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||33056

--- Comment #4 from Dominique d'Humieres  ---
AFAICT this is fixed on 6.3.0 and trunk (7.0), but not on 5.4.1 (r245576).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug 33056] [Meta-bug] Data - statement related bugs

[Bug fortran/49588] DATA statement with vector sections rejected (ICE: TODO)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||33056

--- Comment #2 from Dominique d'Humieres  ---
Still present at r245564.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug 33056] [Meta-bug] Data - statement related bugs

[Bug fortran/79685] [5/6/7 Regression] ICE on valid code in gfc_match_structur_constructor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||33056

--- Comment #2 from Dominique d'Humieres  ---
Workaround

--- pr79685.f90 2017-02-23 11:21:32.0 +0100
+++ pr79685_db.f90  2017-02-23 14:20:59.0 +0100
@@ -17,9 +17,9 @@ module foo
   private

   integer, parameter :: n_cfactors = 1
-  type(OCF), dimension(n_cfactors), save, protected :: table_color_factors
   real, parameter, private :: color_factor_01 = +1.0
-  data table_color_factors( 1) / OCF(1,1,color_factor_01) /
+  type(OCF), dimension(n_cfactors), save, protected :: table_color_factors &
+  = OCF(1,1,color_factor_01)

 end module foo

I am pretty sure that there is(are) (a) related PR(s), but I cannot find
it(them).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug 33056] [Meta-bug] Data - statement related bugs

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
What's changed in r231197 is that previously we had
return  = (int) ((long int) ((char *)  + (sizetype) q) - (long int)
);
but now
return  = (int) ((long int) ((char *)  + 18446744073709551615) -
(long int) );

[Bug fortran/79685] [5/6/7 Regression] ICE on valid code in gfc_match_structur_constructor

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 CC||marxin at gcc dot gnu.org
Summary|ICE on valid code in|[5/6/7 Regression] ICE on
   |gfc_match_structur_construc |valid code in
   |tor |gfc_match_structur_construc
   ||tor
 Ever confirmed|0   |1

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

[Bug c++/79689] ICE with trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This doesn't ICE for me.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[reichelt at gcc dot gnu.org]

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

--- Comment #11 from Volker Reichelt  ---
The following testcase returns 1 for me since at least GCC 4.7.
clang (3.2 - 4.0.0rc2), VS (2012, 2015) and ICC all return 0.


struct A
{
  char c;
};

int main()
{
  static char A::* p1 = ::c;
  char A::* const q1 = p1;

  char A::* p2 = ::c;
  static char A::* const q2 = p2;

  A a;
  return (&(a.*q1) - ) || (&(a.*q2) - ) ? 1 : 0;
}

[Bug c/79684] Conditional jump or move depends on uninitialised value in GIMPLE FE

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Feb 23 12:38:39 2017
New Revision: 245681

URL: https://gcc.gnu.org/viewcvs?rev=245681=gcc=rev
Log:
2017-02-23  Richard Biener  

PR c/79684
* gimple-parser.c (c_parser_gimple_statement): Use set_error
to initialize c_exprs to return.
(c_parser_gimple_binary_expression): Likewise.
(c_parser_gimple_unary_expression): Likewise.
(c_parser_gimple_postfix_expression): Likewise.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c

[Bug c/79684] Conditional jump or move depends on uninitialised value in GIMPLE FE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/79689] New: ICE with trailing return type

[mwarusz at gmail dot com]

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

Bug ID: 79689
   Summary: ICE with trailing return type
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mwarusz at gmail dot com
  Target Milestone: ---

The following valid c++11 code:

template 
auto f(T x) -> decltype(-1. * x)
{
  return -1. * x;
}

int main()
{
  auto y = f(44.);
}

triggers ICE using gcc 6.3.1. The minus sign under decltype
seems to be instrumental as without it it compiles fine. 

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

[Bug target/71017] libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

[dominiq at gcc dot gnu.org]

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

--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Thu Feb 23 12:19:05 2017
New Revision: 245680

URL: https://gcc.gnu.org/viewcvs?rev=245680=gcc=rev
Log:
2017-01-23  Dominique d'Humieres  

PR target/71017
* config/i386/cpuid.h: Fix another undefined behavior.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h

[Bug c++/79686] Variadic template expansion into concept with leading parameters

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
There used to be a similar error for class templates like X so the
concepts branch might have inherited that bug and then not got fixed when the
class template case was fixed.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Ok, so the Comment 4 testcase started to abort with r217814 and stopped with
r229167.

[Bug c/79688] New: ICE with a RTL test-case and -O1 provided

[marxin at gcc dot gnu.org]

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

Bug ID: 79688
   Summary: ICE with a RTL test-case and -O1 provided
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I know it's kind of nasty to provide an optimization option, but maybe worth
mentioning:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c
-O1
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c:
In function ‘test_1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c:103:1:
internal compiler error: in df_scan_verify, at df-scan.c:4267
 }
 ^
0x84bab6 df_scan_verify()
../../gcc/df-scan.c:4266
0x837cd4 df_verify()
../../gcc/df-core.c:1831
0x837cd4 df_analyze_1
../../gcc/df-core.c:1217
0x138da1a rest_of_handle_dse
../../gcc/dse.c:3418
0x138da1a execute
../../gcc/dse.c:3519

[Bug c++/78301] noexcept() operator rejects sibling method call without object

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
And std::declval()->inner() doesn't work either:

ne.cc:5:59: error: invalid use of incomplete type ‘struct a’
  void outer() const noexcept( noexcept( std::declval()->inner() ) ) {
   ^~
ne.cc:3:8: note: definition of ‘struct a’ is not complete until the closing
brace
 struct a {
^

Which is PR 66256.

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Created attachment 40818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40818=edit
patch

Patch I am testing for the loop splitting cost model.  I still believe loop
splitting on its own is not profitable and it should be integrated with
threading and CSE.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Looks valid to me.

[Bug tree-optimization/79683] SLP vectorizer drops gs: prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Feb 23 11:43:51 2017
New Revision: 245679

URL: https://gcc.gnu.org/viewcvs?rev=245679=gcc=rev
Log:
2017-02-23  Richard Biener  

PR tree-optimization/79683
* tree-vect-stmts.c (vect_analyze_stmt): Do not overwrite
vector types for data-refs.

* gcc.target/i386/pr79683.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr79683.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/79683] SLP vectorizer drops gs: prefix

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed for GCC 7.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Not sure, but clang++ accepts this without warning and the program returns 0.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Well, the first question is: is this valid C++ code?

[Bug c++/71568] Inexplicable error: "X is inaccessible within this context" for a public member

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 /tmp % cat tupl.ii
struct A {
  static constexpr int value = 0;
};
template  struct B { typedef int type; };
template  struct C;
template  struct C<_Idx, _Head> : _Head {};
template  class F : C<0, _Elements...> {};
template  using void_t = void;
template  struct G : A {};
template  struct G> {};
template  typename B::type write(Head);
struct D {
  void nlog_custom();
};
void test() {
  F __trans_tmp_2;
  write(__trans_tmp_2);
}

markus@x4 /tmp % clang++ -c tupl.ii
markus@x4 /tmp % icpc -c tupl.ii
markus@x4 /tmp % g++ -c tupl.ii
tupl.ii: In instantiation of ‘struct G’:
tupl.ii:11:59:   required by substitution of ‘template typename
B::type write(Head) [with Head = F]’
tupl.ii:17:22:   required from here
tupl.ii:10:51: error: ‘void D::nlog_custom()’ is inaccessible within this
context
 template  struct G> {};
   ^~
tupl.ii:13:8: note: declared here
   void nlog_custom();
^~~
tupl.ii:10:51: error: ‘void D::nlog_custom()’ is inaccessible within this
context
 template  struct G> {};
   ^~
tupl.ii:13:8: note: declared here
   void nlog_custom();
^~~
tupl.ii: In function ‘void test()’:
tupl.ii:17:22: error: no matching function for call to ‘write(F&)’
   write(__trans_tmp_2);
  ^
tupl.ii:11:59: note: candidate: template typename
B::type write(Head)
 template  typename B::type write(Head);
   ^
tupl.ii:11:59: note:   substitution of deduced template arguments resulted in
errors seen above

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Duh, I can reproduce the abort with gcc-5 on my laptop, but not on another
machine.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[reichelt at gcc dot gnu.org]

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

--- Comment #5 from Volker Reichelt  ---
The problems actually seem to be older.

We experienced crashes already with GCC 4.8.2, but don't have a small testcase
for this, yet.

[Bug c++/71568] Inexplicable error: "X is inaccessible within this context" for a public member

[jaak at ristioja dot ee]

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

--- Comment #1 from Jaak Ristioja  ---
After trying to minimize the code, this still seems to trigger the same error:


#include 

template  using whatever = void;

template struct has_f;

template 
struct has_f> {};

struct X {
  void f() const {}
};

using t = has_f::asdf;


This is quite weird indeed.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Hmm, I was using:

struct A {
  char c;
};

int main() {
  char A::*p = ::c;
  static char A::*const q = p;
  A a;
  if (&(a.*q) - )
__builtin_abort();
}

and this triggers with gcc-5.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
commit 69f54cf56ac077735cc599dc0db060143ba3713c
Author: jason 
Date:   Wed Dec 2 19:04:43 2015 +

Introduce cp_fold_rvalue.

* cp-gimplify.c (cp_fold_maybe_rvalue, cp_fold_rvalue): New.
(c_fully_fold): Use cp_fold_rvalue.
(cp_fold): Use them for rvalue operands.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231197
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
For me, gcc 5 returns 0.  Bisecting...

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-23
 CC||trippels at gcc dot gnu.org
  Known to work||4.9.3
Summary|[6/7 Regression] Wrong code |[5/6/7 Regression] Wrong
   |with pointer-to-member  |code with pointer-to-member
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with gcc-5 for me.

[Bug c++/79687] New: [6/7 Regression] Wrong code with pointer-to-member

[reichelt at gcc dot gnu.org]

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

Bug ID: 79687
   Summary: [6/7 Regression] Wrong code with pointer-to-member
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following code snippet is miscompiled since GCC 6:

==
struct A
{
  char c;
};

int main()
{
  char A::* p = ::c;
  static char A::* const q = p;

  A a;
  return &(a.*q) - 
}
==

The program should return 0, but doesn't.

[Bug c++/79686] New: Variadic template expansion into concept with leading parameters

[anthony.ajw at gmail dot com]

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

Bug ID: 79686
   Summary: Variadic template expansion into concept with leading
parameters
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anthony.ajw at gmail dot com
  Target Milestone: ---

If I declare a concept that takes a fixed argument and then a variadic
argument, I cannot use it in a function that passes a variadic parameter pack
to the concept. The following code fails to compile:

template
concept bool X=true;

template
void foo(Args&& ...) requires X{}

int main(){
foo(3);
}

Output of g++ -fconcepts t.cpp

t.cpp:5:31: error: invalid reference to concept ‘X’
 void foo(Args&& ...) requires X{}
   ^~
t.cpp: In function ‘int main()’:
t.cpp:8:10: error: cannot call function ‘void foo(Args&& ...) requires 
 [with Args = {int}]’
 foo(3);
  ^
t.cpp:5:6: note:   constraints not satisfied
 void foo(Args&& ...) requires X{}
  ^~~
t.cpp:8:10: note: ill-formed constraint
 foo(3);
  ^

g++ --version
g++ (Ubuntu 6.2.0-3ubuntu11~16.04) 6.2.0 20160901

I get the same errors from my build of gcc 7:

g++-7 --version
g++-7 (GCC) 7.0.0 20170115 (experimental)

[Bug middle-end/79665] gcc's signed (x*x)/200 is slower than clang's

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Huh, never mind. That sdiv was there even before this changes, it is unrelated
to this. I don't have see how there could be a slowdown from this change