[Bug tree-optimization/68797] gcc -m32 does not finish when compiling test cases from PR66070

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Does this still happen?

[Bug c++/69772] enum class bool comparison error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

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

[Bug target/69832] internal compiler error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Depends on||65572

--- Comment #6 from Andrew Pinski  ---
Might be a dup of bug 65572.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65572
[Bug 65572] ptrmem5.C:7:26: internal compiler error: in gimplify_expr, at
gimplify.c:8629

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #3 from Martin Sebor  ---
I'm testing with debugging compilers so maybe that makes the difference.

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-04
 CC|amodra at gcc dot gnu.org  |amodra at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
"o" constraints where "wY" ought to be used.  Also, wY looks to be wrong for
32-bit..

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Martin Sebor from comment #1)
> I can confirm the ICE but not the regression part.  My bisection script
> shows an ICE goes all the way back to 4.3.0.  The first revision I have
> access to that crashes is r128126.

Martin, below is what I see: 

$ g++-6.1 -c -std=c++11 small.cpp
small.cpp:17:23: error: specializing member ‘B<>::C::a’ requires
‘template<>’ syntax
 template <> const int B <>::template C < int () >::a;
   ^~~~
$ g++-5.4 -c -std=c++11 small.cpp
small.cpp:17:23: error: specializing member ‘B<>::C::a’ requires
‘template<>’ syntax
 template <> const int B <>::template C < int () >::a;
   ^
$ g++-4.9 -c -std=c++11 small.cpp
small.cpp:17:23: error: specializing member ‘B<>::C::a’ requires
‘template<>’ syntax
 template <> const int B <>::template C < int () >::a;
   ^
$

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Martin Sebor  ---
I'll see about implementing this enhancement request after I'm done with the
-Wformat-length patch (bug 49905).

[Bug target/72802] New: powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[anton at samba dot org]

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

Bug ID: 72802
   Summary: powerpc64le: -mcpu=power9 emits lxssp instruction with
offset that isn't a multiple of 4
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
CC: amodra at gcc dot gnu.org, bergner at gcc dot gnu.org,
meissner at gcc dot gnu.org, segher at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

I just hit this binutils error:

blah.s:401: Error: operand out of domain (2 is not a multiple of 4)

Which corresponds to:

lxssp 31,2(30)

Alan points out that the bottom two bits are part of the opcode, so it had
better be 4 byte aligned.

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
I can confirm the ICE but not the regression part.  My bisection script shows
an ICE goes all the way back to 4.3.0.  The first revision I have access to
that crashes is r128126.

[Bug c/72797] bogus -Wmisleading-indentation with -ftrack-macro-expansion=0 on a multi-statement macro

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
-ftrack-macro-expansion=0 is set in a number of tests that define helper macros
to help reduce clutter from repetitive constructs.  Without the setting,
diagnostic messages in these tests would point to the macro definition instead
of its expansion, defeating the DejaGnu directives and causing test failures. 
I suspect the option needs to stay until this is fixed and the diagnostics
point to the macro expansion as most users probably expect anyway.  Until then,
I think the surprising effect of the option on -Wmisleading-indentation could
be documented.

For example:

$ cat -n y.c && /build/gcc-71912/gcc/xgcc -B /build/gcc-71912/gcc -S -Wall
-Wextra -Wpedantic -xc++ y.c
 1  #define F(N, n) struct N { int i, a[]; } n
 2  
 3  struct S {// { dg-message "in the definition of" }
 4F (A, a);   // { dg-error "flexible array member" }
 5F (B, b);   // { dg-message "next member" }
 6  };
y.c:1:37: error: flexible array member ‘S::A::a’ not at end of ‘struct S’
 #define F(N, n) struct N { int i, a[]; } n
 ^
y.c:4:3: note: in expansion of macro ‘F’
   F (A, a);
   ^
y.c:5:9: note: next member ‘S::B S::b’ declared here
   F (B, b);
 ^
y.c:1:42: note: in definition of macro ‘F’
 #define F(N, n) struct N { int i, a[]; } n
  ^
y.c:3:8: note: in the definition of ‘struct S’
 struct S {
^

[Bug c++/72801] New: ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[su at cs dot ucdavis.edu]

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

Bug ID: 72801
   Summary: ICE on invalid C++ code with ill-formed class member
specialization: tree check: expected class
‘expression’, have ‘type’ (integer_type) in
tree_operand_check, at tree.h:3521
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.1.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.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 20160802 (experimental) [trunk revision 238983] (GCC)
$
$ g++-trunk -c small.cpp
small.cpp:17:50: internal compiler error: tree check: expected class
‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521
 template <> const int B <>::template C < int () >::a;
  ^~
0x1071a07 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9793
0x5da8f1 expr_check
../../gcc-source-trunk/gcc/tree.h:3192
0x5da8f1 tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3521
0x709be5 tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3244
0x709be5 unify_pack_expansion
../../gcc-source-trunk/gcc/cp/pt.c:19337
0x70a7b9 type_unification_real
../../gcc-source-trunk/gcc/cp/pt.c:18481
0x70c2fe unify
../../gcc-source-trunk/gcc/cp/pt.c:20176
0x70c516 unify
../../gcc-source-trunk/gcc/cp/pt.c:20056
0x70ed47 get_partial_spec_bindings
../../gcc-source-trunk/gcc/cp/pt.c:20826
0x7066c6 most_specialized_partial_spec
../../gcc-source-trunk/gcc/cp/pt.c:21082
0x721993 instantiate_class_template_1
../../gcc-source-trunk/gcc/cp/pt.c:9847
0x721993 instantiate_class_template(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:10412
0x7c7363 complete_type(tree_node*)
../../gcc-source-trunk/gcc/cp/typeck.c:133
0x79954c cp_parser_nested_name_specifier_opt
../../gcc-source-trunk/gcc/cp/parser.c:6131
0x79a05e cp_parser_nested_name_specifier
../../gcc-source-trunk/gcc/cp/parser.c:6194
0x7a7cf6 cp_parser_ptr_operator
../../gcc-source-trunk/gcc/cp/parser.c:19525
0x79e67b cp_parser_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18841
0x7b38b5 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18424
0x7b57d1 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25938
0x7b65e3 cp_parser_explicit_specialization
../../gcc-source-trunk/gcc/cp/parser.c:15779
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


template < typename, typename > struct A {};

template < typename ... T > struct B
{ 
  template < typename > struct C
  { 
static const int a = 0;
  };

  template < typename R, typename ... S >
  struct C < R (A < T, S > ...) >
  { 
static const int a = 1;
  };
};

template <> const int B <>::template C < int () >::a;

[Bug c++/72800] New: ICE on invalid C++14 code with initialized lambda capture: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505

[su at cs dot ucdavis.edu]

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

Bug ID: 72800
   Summary: ICE on invalid C++14 code with initialized lambda
capture: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in add_capture, at
cp/lambda.c:505
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.1.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.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 20160802 (experimental) [trunk revision 238983] (GCC)
$
$ g++-trunk -c -std=c++14 small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:4:7: error: direct-list-initialization of ‘auto’ requires exactly one
element [-fpermissive]
   [n {}] {};
   ^
small.cpp:4:7: note: for deduction to ‘std::initializer_list’, use
copy-list-initialization (i.e. add ‘=’ before the ‘{’)
small.cpp:4:7: error: deducing from brace-enclosed initializer list requires
#include 
small.cpp:4:7: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505
0x1071a07 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9793
0x8a32d4 tree_class_check
../../gcc-source-trunk/gcc/tree.h:3146
0x8a32d4 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc-source-trunk/gcc/cp/lambda.c:505
0x7946cb cp_parser_lambda_introducer
../../gcc-source-trunk/gcc/cp/parser.c:10025
0x7946cb cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9733
0x795f6c cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4960
0x797fe6 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6717
0x7a101c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8012
0x7a1877 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8689
0x7a1e75 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8791
0x7a2760 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9079
0x7a5059 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9246
0x7a57cf cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10709
0x7935fb cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10560
0x7942bc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10832
0x7943af cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10786
0x7b2c4f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20743
0x7b2c4f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20779
0x7b36f1 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25475
0x7b4405 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25387
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


--


void foo ()
{ 
  // should be e.g.: [n {0}] {};
  [n {}] {};
}

[Bug middle-end/70920] if ((intptr_t)ptr == 0) doesn't get simplified to if (ptr == 0)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to mwahab from comment #4)
> (In reply to prathamesh3492 from comment #3)
> > Fixed on trunk.
> 
> I think that this is the cause of a failure in gcc.dg/tree-ssa/pr22051-2.c
> for arm-none-linux-gnueabihf and arm-none-eabi. 
> 
> With the patch, the scan-tree-dump match in the test file fails because the
> conditional becomes
> 
> if (q_2(D) != 0B)
> 
> rather than the expected
> 
> if (r_3 != 0)
> 
> 
> The comment in the test file suggests that the optimization might be wrong.
Sorry for the breakage.
Patch posted for this case:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00246.html

Thanks,
Prathamesh
> 
> Matthew

[Bug c/72797] bogus -Wmisleading-indentation with -ftrack-macro-expansion=0 on a multi-statement macro

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #0)
> When invoked with the -ftrack-macro-expansion=0 and
> -Wmisleading-indentation, GCC warns on the following program derived from a
> GCC test suite.  Since the code is clearly indented and there is no mention
> of the -ftrack-macro-expansion option having this effect, the warning is
> unexpected.

No mention where? Some diagnostics rely on macro info to produce better
diagnostics. If you deactivate it, then you get bad diagnostics. Don't do that.

> In addition, the documentation for -ftrack-macro-expansion=level says that 
> 
>   Value '0' of level de-activates this option just as if no
> -ftrack-macro-expansion was present on the command line. 
> 
> Contrary to the statement above, GCC output changes and the warning
> disappears when the -ftrack-macro-expansion option is removed.

Yes, this must be a relic of the time it was not the default.

Personally, I think we should get rid of this option. This was useful when
tracking macro expansion was new and to work-around bugs. There is no point in
maintaining two code paths and much less on trying to make diagnostics better
for the -ftrack-macro-expansion=0 path. That effort would be better spent in
making the default more efficient and useful.

If we give a warning for:

do { if (i) i = 0; i++; } while (0);

that is, the processed source, that would be different. But it doesn't seem to
be the case in 7.0

[Bug fortran/72798] Module (.mod) file changes even when interface does not

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
Hmm, I can understand why having an internal pure attribute makes sense from an
optimiser point of view. But it results in having lots of compilation cascades
during debugging, which sucks.

Is there a way to force gfortran to treat all routines as being (internally)
impure, unless explicitly declared as pure?

[Bug fortran/72798] Module (.mod) file changes even when interface does not

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
The difference comes from the (internal) implicit pure attribute.
Without the print, the subroutine gets the pure attribute, so that its usage
may be more aggressively optimized (Honestly, on a small test I made, there was
actually no difference).

[Bug c++/72799] [C++11] ref-qualifiers are dropped from some function types

[aoliva at gcc dot gnu.org]

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

--- Comment #1 from Alexandre Oliva  ---
Uhh, sorry, I pasted the error messages from a compiler with changes that
attempted to fix the problem.  Here's what gcc version 5.3.1 20160406 (Red Hat
5.3.1-6) (GCC) reports:
/l/tmp/build/gcc/trunk/gcc/testsuite/g++.dg/other/refqual-1.C:15:12: error:
prototype for ‘void (S::* S::mfpmf() &&)() const &’ does not match any in class
‘S’
 void (S::* S::mfpmf(void) &&)(void) const & { return ::mf; } // ... here...
^
/l/tmp/build/gcc/trunk/gcc/testsuite/g++.dg/other/refqual-1.C:10:12: error:
candidate is: void (S::* S::mfpmf() &&)() const
   rqft S::*mfpmf(void) &&;
^
/l/tmp/build/gcc/trunk/gcc/testsuite/g++.dg/other/refqual-1.C:23:18: error:
cannot convert ‘void (S::*)() const &’ to ‘pmft2 {aka void (S::*)() const}’ in
initialization
 pmft2 pmf2 = ::mf;
  ^

[Bug c++/72799] New: [C++11] ref-qualifiers are dropped from some function types

[aoliva at gcc dot gnu.org]

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

Bug ID: 72799
   Summary: [C++11] ref-qualifiers are dropped from some function
types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aoliva at gcc dot gnu.org
  Target Milestone: ---

// { dg-do compile }
// { dg-options "-std=c++11" }

// Make sure we don't drop ref-qualifiers...

typedef void rqft(void) const &;

struct S {
  rqft mf;
  rqft S::*mfpmf(void) &&;
};

void S::mf() const & {}

void (S::* S::mfpmf(void) &&)(void) const & { return ::mf; } // ... here...

typedef void (S::*pmft1)(void) const &; // ... and here.

pmft1 pmf1 = ::mf;

typedef rqft S::*pmft2;

pmft2 pmf2 = ::mf;

/* gcc version 7.0.0 20160724-ish says:
.../gcc/testsuite/g++.dg/other/refqual-1.C:15:12: error: prototype for ‘void
(S::* S::mfpmf() &&)() const’ does not match any in class ‘S’
 void (S::* S::mfpmf(void) &&)(void) const & { return ::mf; } // ... here...
^
.../gcc/testsuite/g++.dg/other/refqual-1.C:10:12: error: candidate is: void
(S::* S::mfpmf() &&)() const &
   rqft S::*mfpmf(void) &&;
^
.../gcc/testsuite/g++.dg/other/refqual-1.C:19:18: error: cannot convert ‘void
(S::*)() const &’ to ‘pmft1 {aka void (S::*)() const}’ in initialization
 pmft1 pmf1 = ::mf;
  ^~
*/

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/72798] New: Module (.mod) file changes even when interface does not

[townsend at astro dot wisc.edu]

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

Bug ID: 72798
   Summary: Module (.mod) file changes even when interface does
not
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 39054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39054=edit
Test case demonstrating problem

In a big project I'm involved in, we take advantage of the fact that gfortran's
.mod files don't change across a recompilation, if the public interface of the
module is unchanged. This allows us to avoid very time-consuming compilation
cascades.

However, I've run into a case where this desirable behavior doesn't seem to
work. If I compile the attached module ('gfortran -c test_mod.f90') with and
without the print statement commented out, I get .mod files which not only
differ in contents, but also in size.

Is this correct behavior? If so, how might I go about judging whether the
public interface of a module has or hasn't changed?

[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc

[bugfeed at online dot de]

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

--- Comment #15 from Leif Leonhardy  ---
(In reply to Richard Biener from comment #14)
> Fixed.

In trunk that is.


In GCC 6.1.0 we still have

$ egrep -iw 'gmp|mpfr|mpc' src/gcc-6.1.0/contrib/download_prerequisites 
MPFR=mpfr-2.4.2
GMP=gmp-4.3.2
MPC=mpc-0.8.1
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1
tar xjf $MPFR.tar.bz2 || exit 1
ln -sf $MPFR mpfr || exit 1
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$GMP.tar.bz2 || exit 1
tar xjf $GMP.tar.bz2  || exit 1
ln -sf $GMP gmp || exit 1
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPC.tar.gz || exit 1
tar xzf $MPC.tar.gz || exit 1
ln -sf $MPC mpc || exit 1

(Same for GCC 4.9.4, released today.  And we of course keep getting reports
about 't-scan' failing in GMP 4.3.2 on gmp-bugs@...)

[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Based on further discussion
(http://chat.stackoverflow.com/rooms/119045/discussion-between-a3f-and-peter-cordes),
the only bug (or feature?) here is that asm("":::"memory") doesn't count as a
reference for `y`.

i.e. the reason that asm statement works as a barrier is that it might read
`y`, but gcc will still optimize away `y` completely if the only explicit
reference in the translation unit are the stores in g().  This leads to a link
error for:

static int y;
int g() {
   y = 1; asm volatile("movl $5, y(%%rip)":::"memory");
   y = 2; return y;
}

// int gety(){ return y; }  // link error with this commented out, otherwise ok

This can be seen as a feature: It's probably not desirable for any "memory"
clobber to prevent optimizing away any static variables.

If  y  does exist in the asm output at all, I think gcc's behaviour as far as
making the y=1 and y=2 stores happen separately is correct.  If y exists at
all, its value in memory has to be up-to-date.

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-03
 CC||jason at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #1)
> markus@x4 js % cat jsarray.ii
> struct a;
> template  struct b { typedef a c; };
> struct d {
>   void e(int);
> };
> struct a : d {
>   void e(int) = delete;
> };
> template  struct g : b::c {
>   g(int) { this->d::e(0); }
> };
> struct h : g<0> {
>   using i = g;
>   h() : i(0) {}
> };
> 
> markus@x4 js % g++ -c jsarray.ii
> jsarray.ii: In instantiation of ‘g::g(int) [with int f = 0]’:
> jsarray.ii:14:12:   required from here
> jsarray.ii:10:12: error: use of deleted function ‘void a::e(int)’
>g(int) { this->d::e(0); }
> ^~~~
> jsarray.ii:7:8: note: declared here
>void e(int) = delete;
> ^

Great, I triggered creduce before leaving work. Looks we've already have a
test-case ;)

Started with: r236221:

/home/marxin/Programming/testcases/pr72796.cc:10:21: error: ‘d’ is not a base
of ‘g’
   g(int) { this->d::e(0); }

which changed in r237558 to the aforementioned error message.

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #23 from PeteVine  ---
> updating URL to latest 1.4.8 version. Can you please check that the problem 
> is still reproducible?

Thanks, forgot to mention my last reproduction used 1.4.6 source.

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[edlinger at gcc dot gnu.org]

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

--- Comment #14 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Aug  3 19:05:45 2016
New Revision: 239092

URL: https://gcc.gnu.org/viewcvs?rev=239092=gcc=rev
Log:
2016-08-03  Bernd Edlinger  

PR middle-end/71876
* calls.c (special_function_p): Remove special handling of
"setjmp_syscall", "qsetjmp", "longjmp", "siglongjmp" and the
prefix "__x".  Recognize "savectx", "vfork" and "getcontext" only
without prefix.  Remove potentially unsafe ECF_LEAF and ECF_NORETURN.

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

[Bug rtl-optimization/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Aug  3 18:54:49 2016
New Revision: 239091

URL: https://gcc.gnu.org/viewcvs?rev=239091=gcc=rev
Log:
2016-08-03  Vladimir Makarov  

PR middle-end/72778
* lra-spills.c (regno_in_use_p): Check bb and regno modification.
Don't stop on regular insns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-spills.c

[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers

[ahmad at a3f dot at]

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

--- Comment #2 from Ahmad Fatoum  ---
The write that can't be optimized away is the final assignment to x.
The `movl$1, x(%rip)` prior to the barrier should've been optimized out,
IMO.

[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Peter Cordes  ---
This is not a bug.  Adding int gety(){ return y; }  to the compilation unit
leads to the same asm for f() and g(). (https://godbolt.org/g/4z94YZ).  It can
only be optimized away when there are no observers.

f() and g() have side-effects on global / static variables which of course
can't be optimized away.

BTW, this came up based on http://stackoverflow.com/a/38741832/224132.

[Bug rtl-optimization/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Uroš Bizjak from comment #6)

Hi, Uros. Thanks for reporting this.  It was my mistake that I did not check
bootstrap with GO.  I am going to fix it soon.

> Before the patch, register allocator used to leave self-assignments (e.g.
> insn 20) in the insn stream. Post-reload vzeroupper insertion mode-swithing
> pass depends on these instructions. Self-assignments are later removed by
> subsequent passes.
> 
> 
> Can we have these self-assignments back?

Unfortunately, LRA can produce wrong moves (it was even before I implemented
invariant inheritance which also can do it).  It is important to remove them at
this stage, otherwise GCC crashes on later passes.

[Bug c/72797] New: bogus -Wmisleading-indentation with -ftrack-macro-expansion=0 on a multi-statement macro

[msebor at gcc dot gnu.org]

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

Bug ID: 72797
   Summary: bogus -Wmisleading-indentation with
-ftrack-macro-expansion=0 on a multi-statement macro
   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 invoked with the -ftrack-macro-expansion=0 and -Wmisleading-indentation,
GCC warns on the following program derived from a GCC test suite.  Since the
code is clearly indented and there is no mention of the -ftrack-macro-expansion
option having this effect, the warning is unexpected.

In addition, the documentation for -ftrack-macro-expansion=level says that 

  Value '0' of level de-activates this option just as if no
-ftrack-macro-expansion was present on the command line. 

Contrary to the statement above, GCC output changes and the warning disappears
when the -ftrack-macro-expansion option is removed.

The warning also disappears with -ftrack-macro-expansion=1 and greater, or when
the body of the if statement is encloses in braces.

$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O -S
-Wall -Wextra -Wpedantic -ftrack-macro-expansion=0 xyz.c
int i;

void f (void)
{
#define T() \
  do {  \
if (i)  \
  i = 0;\
i++;\
  } while (0)

  T ();
}
xyz.c: In function ‘f’:
xyz.c:12:3: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
   T ();
   ^
xyz.c:12:3: note: ...this statement, but the latter is misleadingly indented as
if it is guarded by the ‘if’

[Bug c++/72759] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, tree_class_check, ocp_convert)

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00116.html

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 js % cat jsarray.ii
struct a;
template  struct b { typedef a c; };
struct d {
  void e(int);
};
struct a : d {
  void e(int) = delete;
};
template  struct g : b::c {
  g(int) { this->d::e(0); }
};
struct h : g<0> {
  using i = g;
  h() : i(0) {}
};

markus@x4 js % g++ -c jsarray.ii
jsarray.ii: In instantiation of ‘g::g(int) [with int f = 0]’:
jsarray.ii:14:12:   required from here
jsarray.ii:10:12: error: use of deleted function ‘void a::e(int)’
   g(int) { this->d::e(0); }
^~~~
jsarray.ii:7:8: note: declared here
   void e(int) = delete;
^

[Bug c++/71748] [5 Regression] ICE on valid (?) C++ template code invoking a base destructor: in build_base_path, at cp/class.c:304

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
*** Bug 70616 has been marked as a duplicate of this bug. ***

[Bug c++/70616] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Nathan Sidwell  ---
Fixed by Jason's commit r238681

2016-07-22  Jason Merrill  

PR c++/71748
PR c++/52746
* pt.c (tsubst_baselink): Call
adjust_result_of_qualified_name_lookup for unqualified
destructors.

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

[Bug c++/72796] New: [7 Regression] Firefox build error: use of deleted function

[trippels at gcc dot gnu.org]

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

Bug ID: 72796
   Summary: [7 Regression] Firefox build error: use of deleted
function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

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

markus@x4 js % clang++ -w -std=c++11 -c jsarray.ii
markus@x4 js % icpc -w -std=c++11 -c jsarray.ii
markus@x4 js % g++-6 -w -std=c++11 -c jsarray.ii
markus@x4 js % g++-trunk -w -std=c++11 -c jsarray.ii
In file included from /var/tmp/gecko-dev/js/src/vm/Runtime.h:48:0,
 from /var/tmp/gecko-dev/js/src/jscntxt.h:17,
 from /var/tmp/gecko-dev/js/src/jsarray.cpp:19:
/var/tmp/gecko-dev/js/src/vm/Stack.h: In instantiation of
‘js::detail::FixedArgsBase::FixedArgsBase(JSContext*) [with
js::MaybeConstruct Construct = (js::MaybeConstruct)1u; long unsigned int N =
1ul]’:
/var/tmp/gecko-dev/js/src/vm/Stack.h:1028:57:   required from
‘js::FixedConstructArgs::FixedConstructArgs(JSContext*) [with long unsigned
int N = 1ul]’
/var/tmp/gecko-dev/js/src/jsarray.cpp:3075:39:   required from here
/var/tmp/gecko-dev/js/src/vm/Stack.h:987:13: error: ‘void
js::AnyConstructArgs::setThis(JS::Value)’ is private within this context
 this->CallArgs::setThis(MagicValue(JS_IS_CONSTRUCTING));
 ^~~~
/var/tmp/gecko-dev/js/src/vm/Stack.h:942:10: note: declared private here
 void setThis(Value v) = delete;
  ^~~
/var/tmp/gecko-dev/js/src/vm/Stack.h:987:13: error: use of deleted function
‘void js::AnyConstructArgs::setThis(JS::Value)’
 this->CallArgs::setThis(MagicValue(JS_IS_CONSTRUCTING));
 ^~~~
/var/tmp/gecko-dev/js/src/vm/Stack.h:942:10: note: declared here
 void setThis(Value v) = delete;
  ^~~

Reducing...

[Bug middle-end/72795] New: Missed optimization of external-linkage variables in presence of barriers

[ahmad at a3f dot at]

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

Bug ID: 72795
   Summary: Missed optimization of external-linkage variables in
presence of barriers
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ahmad at a3f dot at
  Target Milestone: ---

Godbolt link: https://godbolt.org/g/egb73f

 int x;
  static int y;

  int f() { x = 1; asm volatile("":::"memory"); x = 2; return x; }
  int g() { y = 1; asm volatile("":::"memory"); y = 2; return y; }
  int h() { int z = 1; asm volatile("":::"memory"); z = 2; return z; }

on GCC 6.1 with -O2 for AMD64 generates following assembly:

  f():
movl$1, x(%rip)
movl$2, x(%rip)
movl$2, %eax
ret
  g():
movl$2, %eax
ret
  h():
movl$2, %eax
ret

The question is: Was optimizing the non-volatile write in g() and h() the
intended behavior?
And if so, shouldn't same optimization be applied when the variable is of
external linkage (f)?

Replacing the compiler barrier with a full memory barrier gives same behavior.


I also tried same with clang and icc. Clang does as GCC does, icc doesn't
optimize g(), but optimizes h().

[Bug target/71978] -mrealignstack and the unwinder

[rianquinn at gmail dot com]

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

Rian Quinn  changed:

   What|Removed |Added

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

--- Comment #5 from Rian Quinn  ---
Turns out this was an issue with our unwinder. For whatever reason, I missed
the "DW_OP_deref" opcode in the output which was needed to make all of this
make sense. Our unwinder was missing the last instruction as we were using "<"
instead of "<=". 

I closed this as the bug is invalid.

[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Wed, 3 Aug 2016, torvald at gcc dot gnu.org wrote:

> The difference is unfortunate, but C11 specifies that atomic_is_lock_free is
> *per object*.  I suppose that any change there would have to go through the 
> ISO
> C process.

See DR#465 
.

[Bug c/72794] [7 regression] CF on spec2000/176.gcc after r238862.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Yuri Rumyantsev from comment #2)
> Yes, this option cures CF. Does it mean that we must compile spec2000
> with this flag?

Yes and it should be considered a portability flag.

Basically GNU90 and ISO C99 inline behave slightly different which is why you
are seeing this.

[Bug c/72794] [7 regression'] CF on spec2000/176.gcc after r238862.

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Yes, this option cures CF. Does it mean that we must compile spec2000
with this flag?

2016-08-03 19:08 GMT+03:00 pinskia at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794
>
> --- Comment #1 from Andrew Pinski  ---
> Can you try with -std=gnu90 and see if that fixes the issue.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

[fw at gcc dot gnu.org]

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

--- Comment #1 from Florian Weimer  ---
Martin and I discussed this for a bit.

The %ms hack does not work due to embedded NULs, which are copied to the
destination buffer by scanf, do not terminate the string, and are (in most
cases) detectable by the application.

The new M flag raises POSIX compatibility concerns.

The easiest way seems to warn if the output length cannot be bounded (say, with
sscanf and an input string of limited length) and there are no length
specifiers, and not attempt any format string rewriting or process termination
operation.  If there is a separate warning flag which controls this, maybe we
can compile Fedora with -Werror=scanf-length.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Jim Wilson from comment #13)
> I think it was poc_ref_pic_reorder() in slice.c that triggered the ICE.  I
> don't know if the original code shows the vectorization reduction problem. 
> That might only be present in the reduced testcase.

Thanks very much, that's all I wanted to know.  I found a suspicious reduction
case in but not sure if it's the case.  Will look into details.

[Bug c/72794] [7 regression'] CF on spec2000/176.gcc after r238862.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you try with -std=gnu90 and see if that fixes the issue.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[wilson at gcc dot gnu.org]

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

--- Comment #13 from Jim Wilson  ---
I think it was poc_ref_pic_reorder() in slice.c that triggered the ICE.  I
don't know if the original code shows the vectorization reduction problem. 
That might only be present in the reduced testcase.

[Bug c/72794] New: [7 regression'] CF on spec2000/176.gcc after r238862.

[ysrumyan at gmail dot com]

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

Bug ID: 72794
   Summary: [7 regression'] CF on spec2000/176.gcc after r238862.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

We noticed that after this commit benchmark is failed with message:
/tmp/cchqWD0Q.ltrans0.ltrans.o: In function `yylex':
:(.text+0x566e): undefined reference to `is_reserved_word'
/tmp/cchqWD0Q.ltrans8.ltrans.o: In function `compile_file':
:(.text+0xb1fe): undefined reference to `is_reserved_word'
:(.text+0xb22b): undefined reference to `is_reserved_word'
:(.text+0xb248): undefined reference to `is_reserved_word'
:(.text+0xb265): undefined reference to `is_reserved_word'

i.e. function is_reserved_word with attribute "inline" was deleted but its
calls were not inlined. To reproduce bench spec must be compiled with
-Ofast -funroll-loops -flto -static  -DSPEC_CPU2000_LP64 options.
I did not try to prepare test-case to reproduce since assume that spec2000
suite is available.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
I have a prototype that fixes this in the obvious way and it causes both
slsr-35.c and slsr-36.c to pass again without turning off code hoisting.  I'll
do a regstrap and then work on some benchmark testing.  I'll post the patch
here for others to try when I get that far.

[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Aug  3 15:46:11 2016
New Revision: 239080

URL: https://gcc.gnu.org/viewcvs?rev=239080=gcc=rev
Log:
PR 70677
* common/config/avr/avr-common.c (avr_option_optimization_table)
[OPT_LEVELS_ALL]: Turn off -fcaller-saves.


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

[Bug middle-end/70920] if ((intptr_t)ptr == 0) doesn't get simplified to if (ptr == 0)

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #4 from mwahab at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #3)
> Fixed on trunk.

I think that this is the cause of a failure in gcc.dg/tree-ssa/pr22051-2.c for
arm-none-linux-gnueabihf and arm-none-eabi. 

With the patch, the scan-tree-dump match in the test file fails because the
conditional becomes

if (q_2(D) != 0B)

rather than the expected

if (r_3 != 0)


The comment in the test file suggests that the optimization might be wrong.

Matthew

[Bug libfortran/72790] MOVE_ALLOC() of character looses content data

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This bug is fixed on at least the 5-branch (5.4.1, 20160729),
6-branch (6.1.1, 20160515), and trunk (7.0.0 20160730).

[Bug fortran/72791] Internal compiler error for reshape intrinsic

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Patrick Seewald from comment #0)
> I get an internal compiler error (Segmentation fault) when compiling the
> following program
> 
> program reshape_bug
>integer, dimension(2) :: order1
>integer, dimension(1) :: order2
>real, dimension(2,2,2) :: arr1, arr2
> 
>order1 = [1,2]
>order2 = [3]
> 
>arr2 = reshape(arr1, shape=shape(arr2), order=[order1,order2])
> end program
>

This bug is fixed on trunk (aka gfortran 7.0).
I have no cycles to backport the patch 
to any branch.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
Hi Jim,
May I ask which function in h264ref also shows this issue?  I instrumented GCC
and could not found a case in it.  Thanks.

[Bug tree-optimization/72787] Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[ranjan.winner at gmail dot com]

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

--- Comment #5 from martin  ---
(In reply to rguent...@suse.de from comment #4)
> On Wed, 3 Aug 2016, ranjan.winner at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72787
> > 
> > --- Comment #2 from martin  ---
> > (In reply to Richard Biener from comment #1)
> > > You can't rely on __builtin_object_size this way, please look up its
> > > documentation.
> > 
> > Hi Richard,
> >  Sorry, can you kindly throw some more pointers over this.
> >  Here is the link for gcc document on object-size-Checking:
> > https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
> > 
> > 
> > Also some pointer over my Query:-
> > 
> > Why for gcc-4.6  changes with tree-ssa.c file are omitted but not in gcc-4.7
> > branch 
> 
> Because the change is intrusive and not strictly required.

Thanks:)

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed|2015-12-23 00:00:00 |2016-8-3

--- Comment #22 from Martin Liška  ---
Ok, I can confirm that I can see a profile corruption even with:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00060.html

../src/luajit2/src/lj_meta.c: In function ‘lj_meta_tget’:
../src/luajit2/src/lj_meta.c:465:1: error: corrupted profile info: edge from 21
to 3 exceeds maximal count
 }

I'll continue on that tomorrow.

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Most of the fallout is doing more jump-threading.  It looks like threading was
also confused by the extra degenerate PHIs.

The two ICEs are selective scheduling messing up the loop structure somehow.

[Bug libstdc++/72792] New: allocator_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

Bug ID: 72792
   Summary: allocator_traits is too strict about rebinding
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

template
struct Alloc {
  using value_type = T;

  T* allocate(std::size_t n) { throw std::bad_alloc(); }
  void deallocate(T*, std::size_t n) { }
};

std::allocator_traits::pointer p;


/home/jwakely/gcc/7/include/c++/7.0.0/bits/alloc_traits.h: In instantiation of
‘struct std::allocator_traits’:
alloc.cc:11:34:   required from here
/home/jwakely/gcc/7/include/c++/7.0.0/bits/alloc_traits.h:187:7: error: static
assertion failed: allocator defines rebind or is like Alloc
   static_assert(!is_same::value,
   ^

The standard says that the instantiation of allocator_traits>::rebind_alloc should be ill-formed, but the assertion fires even when it
isn't instantiated.

[Bug libstdc++/72793] New: pointer_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

Bug ID: 72793
   Summary: pointer_traits is too strict about rebinding
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

template
struct Ptr {
  using element_type = T;
};

std::pointer_traits::element_type e;


/home/jwakely/gcc/7/include/c++/7.0.0/bits/ptr_traits.h: In instantiation of
‘struct std::pointer_traits’:
alloc.cc:8:30:   required from here
/home/jwakely/gcc/7/include/c++/7.0.0/bits/ptr_traits.h:113:7: error: static
assertion failed: pointer type defines rebind or is like SomePointer
   static_assert(!is_same::value,
   ^

The standard says that the instantiation of pointer_traits>::rebind
should be ill-formed, but the assertion fires even when it isn't instantiated.

[Bug tree-optimization/72787] Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 3 Aug 2016, ranjan.winner at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72787
> 
> --- Comment #2 from martin  ---
> (In reply to Richard Biener from comment #1)
> > You can't rely on __builtin_object_size this way, please look up its
> > documentation.
> 
> Hi Richard,
>  Sorry, can you kindly throw some more pointers over this.
>  Here is the link for gcc document on object-size-Checking:
> https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
> 
> 
> Also some pointer over my Query:-
> 
> Why for gcc-4.6  changes with tree-ssa.c file are omitted but not in gcc-4.7
> branch 

Because the change is intrusive and not strictly required.

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The patch has quite some fallout, including ICEs and wrong-code :/

FAIL: c-c++-common/ubsan/pr71403-1.c   -O3 -g  execution test
FAIL: gcc.dg/graphite/pr35356-1.c scan-tree-dump graphite "if (P_9 >= P_10
\
\\\+ 1 && P_10 >= 0) {"
FAIL: gcc.dg/tree-ssa/20030714-2.c scan-tree-dump-times dom2 "if " 3
FAIL: gcc.dg/tree-ssa/ivopt_5.c scan-tree-dump-times ivopts "ivtmp.[0-9_]* =
PHI <[^0]" 0
FAIL: gcc.dg/tree-ssa/loadpre2.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre21.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre22.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/pr21417.c scan-tree-dump-times thread4 "FSM jump thread"
1
FAIL: gcc.dg/tree-ssa/pr59597.c scan-tree-dump vrp1 "Cancelling"
FAIL: gcc.dg/tree-ssa/ssa-pre-23.c scan-tree-dump pre "Eliminated: 3"
FAIL: gcc.target/i386/pr60901.c (internal compiler error)
FAIL: gcc.target/i386/pr60901.c (test for excess errors)

and with -m32 additionally

FAIL: gcc.dg/pr45570.c (internal compiler error)
FAIL: gcc.dg/pr45570.c (test for excess errors)
FAIL: gcc.dg/pr70920-4.c scan-tree-dump forwprop1 "if (_[0-9]* == 0)"
FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of
SCoPs: 1" 1
FAIL: gcc.dg/graphite/scop-dsyrk.c scan-tree-dump-times graphite "number of
SCoPs: 1" 1
FAIL: gcc.dg/tree-ssa/pr22051-2.c scan-tree-dump-times optimized "r_. =
(int) q" 1
FAIL: gcc.dg/tree-ssa/pr71078-3.c scan-tree-dump forwprop1 "__builtin_copysign"


I fixed the PRE testcases sofar, need to investigate the above some more.

The pasted patch contained an error, the if (single_edge) condition has to be
if (nentry == 1).

[Bug tree-optimization/72787] Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[ranjan.winner at gmail dot com]

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

--- Comment #3 from martin  ---
(In reply to Richard Biener from comment #1)
> You can't rely on __builtin_object_size this way, please look up its
> documentation.

Hi Richard,

 Sorry, can you kindly throw some more pointers over this.
 Here is the link for gcc document on object-size-Checking:
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html


Also some pointer over my Query:-

Why for gcc-4.6  changes with tree-ssa.c file are omitted but not in gcc-4.7
branch 

NOTE: For gcc-4_6-branch where change in file "gcc/tree-ssa.c" is not
considered as:
   /* Do not lose casts to restrict qualified pointers.  */
-  if ((TYPE_RESTRICT (outer_type)
-  != TYPE_RESTRICT (inner_type))
-  && TYPE_RESTRICT (outer_type))
-  return false;

Thanks for your reply.


Best Regards,
Martin

[Bug tree-optimization/72787] Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[ranjan.winner at gmail dot com]

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

--- Comment #2 from martin  ---
(In reply to Richard Biener from comment #1)
> You can't rely on __builtin_object_size this way, please look up its
> documentation.

Hi Richard,
 Sorry, can you kindly throw some more pointers over this.
 Here is the link for gcc document on object-size-Checking:
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html


Also some pointer over my Query:-

Why for gcc-4.6  changes with tree-ssa.c file are omitted but not in gcc-4.7
branch 

NOTE: For gcc-4_6-branch where change in file "gcc/tree-ssa.c" is not
considered as:
   /* Do not lose casts to restrict qualified pointers.  */
-  if ((TYPE_RESTRICT (outer_type)
-  != TYPE_RESTRICT (inner_type))
-  && TYPE_RESTRICT (outer_type))
-  return false;

Thanks for your reply.


Best Regards,
Martin

[Bug fortran/72791] New: Internal compiler error for reshape intrinsic

[patrick.seewald at gmail dot com]

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

Bug ID: 72791
   Summary: Internal compiler error for reshape intrinsic
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.seewald at gmail dot com
  Target Milestone: ---

I get an internal compiler error (Segmentation fault) when compiling the
following program

program reshape_bug
   integer, dimension(2) :: order1
   integer, dimension(1) :: order2
   real, dimension(2,2,2) :: arr1, arr2

   order1 = [1,2]
   order2 = [3]

   arr2 = reshape(arr1, shape=shape(arr2), order=[order1,order2])
end program

with

$ gfortran reshape_bug.f90

Complete output:

f951: internal compiler error: Segmentation fault
0xa7040f crash_signal
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/toplev.c:383
0x5fe04f gfc_check_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/check.c:3848
0x62f7b2 check_specific
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/intrinsic.c:4228
0x63d8cd gfc_intrinsic_func_interface(gfc_expr*, int)
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/intrinsic.c:4443
0x67cddf resolve_unknown_f
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:2704
0x67cddf resolve_function
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:2999
0x67cddf gfc_resolve_expr(gfc_expr*)
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:6256
0x6816e1 gfc_resolve_code(gfc_code*, gfc_namespace*)
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:10189
0x684272 resolve_codes
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:15178
0x684361 gfc_resolve
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/resolve.c:15212
0x66fe8a resolve_all_program_units
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/parse.c:5345
0x66fe8a gfc_parse_file()
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/parse.c:5588
0x6aeee5 gfc_be_parse_file
   
/data/software/cp2k/tools/toolchain/build/gcc-5.4.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/72699] [6/7 Regression] ICE in gfc_check_dependency, at fortran/dependency.c:1257

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||pault at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
AFAICT this PR is now fixed on trunk (7.0) and the gcc-5 and 6 branches. Likely
r238822.

I'll close the PR as FIXED in the coming days unless someone object.

[Bug c++/72786] Odd spelling suggestion with later defined macro: Suggestion is identical to unknown identifier

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

A two-liner fix for this would be to detect in
  best_match::get_best_meaningful_candidate
if m_best_distance is 0, and if so return NULL, i.e. to not give a suggestion
if somehow we have suggestion of the goal string.  Doing so would give this
output:

pr72786.C:2:30: error: ‘OVERRIDE’ does not name a type
   virtual void clone() const OVERRIDE  { }
  ^~~~
  OVERRIDE

(i.e. no suggestion).

It would be nice to offer a better error message to the user about the macro
ordering.

It's easy to detect in both C and C++'s implementation of lookup_name_fuzzy if
we have a macro equal to the goal string (look for the best_macro_match having
a best distance of 0).  If we see this , and the macro defn happens after the
macro usage site,  we can suppress the bogus hint, and potentially add a note
or two, giving something like this:

pr72786.C:2:30: error: ‘OVERRIDE’ does not name a type
   virtual void clone() const OVERRIDE  { }
  ^~~~
  OVERRIDE
pr72786.C:2:30: note: the macro ‘OVERRIDE’ had not yet been defined
pr72786.C:4:8: note: it was later defined here:
 #define OVERRIDE override
 ^~~~

or somesuch wording (presumably the 2nd note would typically be in some header
file, and thus typically show the usual info about "in file included from"
etc).

Doing this consistently would require updating all call sites of
lookup_name_fuzzy in the C and C++ frontends, perhaps to use some new common
interface for issuing a diagnostic with an optional suggestion

e.g. have lookup_name_fuzzy return some "class name_hint" or somesuch, with
methods for emitting the appropriate diagnostics.

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL|http://te4.org/dl/t-engine/ |http://te4.org/dl/t-engine/
   |t-engine4-src-1.3.3-nomusic |t-engine4-src-1.4.8-nomusic
   |.tar.bz2|.tar.bz2

--- Comment #21 from Martin Liška  ---
Ok, updating URL to latest 1.4.8 version. Can you please check that the problem
is still reproducible?

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to PeteVine from comment #19)
> Here's what I've been doing to arrive at that profile-use crash:
> 
> In the unpacked archive's top-level directory (see URL), edit premake4.lua

Can you please check the url, I see Page Not Found

Thanks

> to point to your SDL2 includes (instead of /opt) and add
> `-fprofile-generate` to your release CFLAGS. Followed by:
> 
> $ premake4 gmake
>

[Bug rtl-optimization/71984] [7 Regression] wrong code with -O -mavx512cd

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #7 from mwahab at gcc dot gnu.org ---
(In reply to Richard Biener from comment #6)
> Should be fixed.

The test pr71984.c fails for aarch64 big-endian, with x==2. (The test passes
for little-endian.)

Matthew

[Bug libfortran/72790] New: MOVE_ALLOC() of character looses content data

[nathanael.huebbe at informatik dot uni-hamburg.de]

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

Bug ID: 72790
   Summary: MOVE_ALLOC() of character looses content data
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.huebbe at informatik dot uni-hamburg.de
  Target Milestone: ---

Created attachment 39052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39052=edit
Code to reproduced the bug

The following code snippet reproduces the problem:

program move_alloc_test
character(:), allocatable :: srcString, destString
integer, allocatable :: srcArray(:), destArray(:)

srcString = "foo"
call move_alloc(srcString, destString)
write(0,*) "destString = '"//destString//"', &
   (srcString) = ", allocated(srcString), ", &
   (destString) = ", allocated(destString)

srcArray = [1, 2, 3]
call move_alloc(srcArray, destArray)
write(0,*) "destArray = (", destArray, "), &
   (srcArray) = ", allocated(srcArray), ", &
   (destArray) = ", allocated(destArray)
end program

The output of this program, when compiled with either gfortran 4.9.2 or 5.1.0,
shows an empty `destString` after the `move_alloc()` call:

 destString = '', allocated(srcString) =  F , allocated(destString) =  T
 destArray = (   1   2   3 ), allocated(srcArray) =
 F , allocated(destArray) =  T

The output that I would have expected is this:

 destString = 'foo', allocated(srcString) =  F , allocated(destString) =  T
 destArray = (   1   2   3 ), allocated(srcArray) =
 F , allocated(destArray) =  T

Note that this loss of data only happens for `character` allocatables, not for
array allocatables.

[Bug gcov-profile/58250] -fprofile-use causes: "warning: -fprefetch-loop-arrays is not supported with -Os"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
If I see correctly, should be fixed since r222033.

[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed (probably a dup).

[Bug c++/72789] New: add -Wunused-private-field

[tromey at gcc dot gnu.org]

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

Bug ID: 72789
   Summary: add -Wunused-private-field
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

I found out recently that clang has a '-Wunused-private-field'
warning.  E.g., I got:

https://github.com/mozilla/rr/pull/1757#issuecomment-237031428

I think it would be good to add this to gcc.

[Bug target/72771] [6/7 Regression] powerpc64le ICE with -mcpu=power9

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Needs -O3 -mcpu=power9 -mno-lra, and a binutils that supports power9,
to fail.  Same on BE as on LE.

[Bug tree-optimization/72787] Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You can't rely on __builtin_object_size this way, please look up its
documentation.

[Bug regression/67288] [4.9 regression] non optimal simple function (useless additional shift/remove/shift/add)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
It's not fixed.  On trunk we get:

===
flush_dcache_range:
rlwinm 3,3,0,0,27
addi 4,4,15
subf 4,3,4
srwi. 9,4,4
beq 0,.L1
slwi 9,9,4
addi 9,9,-16
srwi 9,9,4
addi 9,9,1
mtctr 9
.p2align 4,,15
.L3:
dcbf 0, 3
addi 3,3,16
bdnz .L3
sync
.L1:
blr
===

(-m32, edited a bit).

The slwi/addi/srwi/addi is unnecessary.

[Bug target/72788] New: Stack unwinding fails since GCC 4.9 on i686 without -fexceptions

[fw at gcc dot gnu.org]

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

Bug ID: 72788
   Summary: Stack unwinding fails since GCC 4.9 on i686 without
-fexceptions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: i686-redhat-linux-gnu

The tst-cleanupx4 test case used to test stack unwinding (for thread
cancellation processing) for code compiled without -fexceptions.  Starting with
GCC 4.9, this no longer works on i686:

  https://www.sourceware.org/ml/libc-alpha/2014-07/msg00299.html
  https://www.sourceware.org/ml/libc-alpha/2015-11/msg00533.html

Is the requirement for -fexceptions expected behavior on the GCC side?

[Bug rtl-optimization/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-03
  Component|middle-end  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #6 from Uroš Bizjak  ---
Before the patch, register allocator used to leave self-assignments (e.g. insn
20) in the insn stream. Post-reload vzeroupper insertion mode-swithing pass
depends on these instructions. Self-assignments are later removed by subsequent
passes.

...
(insn 6 19 20 2 (parallel [
(set (reg:SI 0 ax [orig:88 _5 ] [88])
(unspec_volatile:SI [
(mem/v:SI (reg/v/f:DI 5 di [orig:90 l ] [90]) [-1  S4
A32])
(const_int 32773 [0x8005])
] UNSPECV_XCHG))
(set (mem/v:SI (reg/v/f:DI 5 di [orig:90 l ] [90]) [-1  S4 A32])
(plus:SI (mem/v:SI (reg/v/f:DI 5 di [orig:90 l ] [90]) [-1  S4
A32])
(reg:SI 0 ax [orig:88 _5 ] [88])))
(clobber (reg:CC 17 flags))
]) /home/uros/gcc-svn/trunk/libgo/runtime/sema.goc:345 4933
{atomic_fetch_addsi}
 (nil))
(insn 20 6 7 2 (set (reg:SI 0 ax [orig:88 _5 ] [88])
(reg:SI 0 ax [orig:88 _5 ] [88]))
/home/uros/gcc-svn/trunk/libgo/runtime/sema.goc:345 82 {*movsi_internal}
 (nil))
...

Can we have these self-assignments back?

[Bug c++/72415] [6/7 regression][concepts] ICE in satisfy_predicate_constraint

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Started with r238558.

[Bug tree-optimization/71881] [6 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.2

[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.2

[Bug c++/72415] [7 regression][concepts] ICE in satisfy_predicate_constraint

[lucdanton at free dot fr]

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

--- Comment #2 from lucdanton at free dot fr ---
I completely failed to make note that this used to compile on GCC 6.1, too
(modulo the missing definition, again).

[Bug tree-optimization/72787] New: Query related to gcc-4_6-branch fix for Bug-49279 (Getting issue with __restrict type qualifier)

[ranjan.winner at gmail dot com]

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

Bug ID: 72787
   Summary: Query related to  gcc-4_6-branch  fix for Bug-49279
(Getting issue with __restrict type qualifier)
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ranjan.winner at gmail dot com
  Target Milestone: ---

Created attachment 39051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39051=edit
Test Case

Question : Why for gcc-4.6 changes with tree-ssa.c file are omitted, I am
facing  problem due to this omission.

Link:- https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00468.html

Below is the link of patch submitted for gcc-4.7 branch
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2453d677b3879f218c98812c82c2ca1b2494f694

While below is link for gcc-4.6 branch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=479c60cd6e28540b9af9e0c436921ef23492a06a


Getting issue with gcc-4.6.3 version relating to __restrict qualifier.

While the issue is getting fix for gcc-4.8.1, the patch for both branches are
same, except for gcc-4_6-branch where change in file "gcc/tree-ssa.c" is not
considered as:
   /* Do not lose casts to restrict qualified pointers.  */
-  if ((TYPE_RESTRICT (outer_type)
-  != TYPE_RESTRICT (inner_type))
-  && TYPE_RESTRICT (outer_type))
-  return false;

But if we consider this change then issue is getting resolve with gcc-4.6.3

1) FOR GCC-4.6.3

$ ./x86_64-ran-linux-gcc --version
x86_64-ran-linux-gcc (GCC) 4.6.3

$ ./x86_64-ran-linux-gcc -Wall -O2 -g test_restrict.c -o test_restrict
$ ./test_restrict.c
Case 1: dst size (100) is less than len (12800) //Incorrect Result 
Dest size is 12800 and len is 12800.

2) FOR GCC-4.8.1

$ ./x86_64-ran-linux-gcc --version
x86_64-windriver-linux-gcc (GCC) 4.8.1

$ ./x86_64-ran-linux-gcc -Wall -O2 -g test_restrict.c -o test_restrict
$ ./test_restrict
Case 2: dst size (12800) is equal to or greater than len (12800) //Incorrect
Result 
Dest size is 12800 and len is 12800.

-TESTCASE-

#include  
#include  
#include  

#define DIMENSION_1 128 
#define DIMENSION_2 100 

char a[DIMENSION_1][DIMENSION_2]; 

char b[DIMENSION_1][DIMENSION_2]; 

extern inline __attribute__ ((always_inline)) int 
my_memcpy(void *__restrict dst, const void *__restrict src, size_t len) 
{ 
  size_t _sz = __builtin_object_size(dst, 1); 
  return (((_sz != (size_t) -1) && (_sz != 0)) 
  ? ((_sz < len) 
 ? printf("Case 1: dst size (%zu) is less than len (%zu)\n", _sz, len) 
 : printf("Case 2: dst size (%zu) is equal to or greater than len
(%zu)\n", _sz, len)) 
  : printf("Case 3: dst size is (%zu) and len is (%zu)\n", _sz, len)); 
} 

int main(int argc, char **argv) 
{ 
  my_memcpy(, , (DIMENSION_1*DIMENSION_2)); 

  printf("Dest size is %zu and len is %u.\n", 
 __builtin_object_size(, 1), DIMENSION_1*DIMENSION_2); 

  return 0; 
}

[Bug target/65151] [SH] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[SH][4.9 Regression]|[SH] Internal compiler
   |Internal compiler error |error when trying to build
   |when trying to build libav  |libav 11.2 on sh4
   |11.2 on sh4 |

--- Comment #17 from Oleg Endo  ---
Well, not really fixed.  It just doesn't happen in GCC 5.  Reopening and
adjusting topic.

[Bug c++/72764] [4.9/5/6/7 Regression] ICE on invalid C++11 code instantiating an alias template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in typedef_variant_p, at tree.c:126

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #2 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/72707] [4.9/5/6/7 regression] local anonymous union member hides names in the same scope

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #1 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug fortran/72714] [4.9/5/6/7 Regression] ICE in gfc_array_init_size, at fortran/trans-array.c:5235

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #3 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/72763] [4.9/5/6/7 Regression] incorrectly accepts invalid C++11 code that instantiates a non-template class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #2 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/72786] New: Odd spelling suggestion with later defined macro: Suggestion is identical to unknown identifier

[burnus at gcc dot gnu.org]

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

Bug ID: 72786
   Summary: Odd spelling suggestion with later defined macro:
Suggestion is identical to unknown identifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The suggestion in the error message is odd:

inp5.ii:2:30: error: ‘OVERRIDE’ does not name a type; did you mean ‘OVERRIDE’?
   virtual void clone() const OVERRIDE  { }
  ^~~~
  OVERRIDE


The reason for it is an ordering issue:

class DocTargetDriver {
  virtual void clone() const OVERRIDE  { }
};
#define OVERRIDE override


I am not sure how to best resolve it. Filtering out would be simple (input and
output are identical); however, I wonder whether it makes more sense to
explicitly point out the ordering issue.

[Bug fortran/71860] [4.9/5/6/7 Regression] ICE on pointing to null(mold), verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #2 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/71784] [4.9/5/6/7 Regression] ICE on invalid code in push_access_scope, at cp/pt.c:229

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #13 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/71827] [4.9/5/6/7 Regression] ICE on invalid C++11 code with non constant diff between two labels

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #3 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug fortran/71861] [4.9/5/6/7 Regression] ICE in write_symbol(): bad module symbol

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #4 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug fortran/71795] [4.9/5/6/7 Regression] Two Bugs in array constructors (optimization)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #9 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug middle-end/71762] [4.9/5/6/7 Regression] ~X & Y to X < Y doesn't work for uninitialized values

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #5 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.2
Summary|[4.9/6/7 Regression]|[6/7 Regression] [graphite]
   |[graphite] internal |internal compiler error: in
   |compiler error: in  |copy_cond_phi_nodes, at
   |copy_cond_phi_nodes, at |graphite-isl-ast-to-gimple.
   |graphite-isl-ast-to-gimple. |c:2500
   |c:2500  |

--- Comment #3 from Richard Biener  ---
(In reply to Martin Liška from comment #2)
> Confirmed, I'm adding also GCC 4.9 branches where it:
> sorry, unimplemented: Graphite loop optimizations cannot be used

this just means you didn't have the graphite prerequesites and it was disabled
at compile-time.

[Bug c++/71748] [4.9/5 Regression] ICE on valid (?) C++ template code invoking a base destructor: in build_base_path, at cp/class.c:304

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #6 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/71747] [4.9/5/6 Regression] ICE on invalid C++11 code with misuse of overloaded operator '()': Segmentation fault (program cc1plus)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #3 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug c++/71737] [4.9/5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #4 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug fortran/71723] [4.9/5/6/7 Regression] ICE with attempted pointer initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #2 from Richard Biener  ---
GCC 4.9 branch is being closed

[Bug fortran/71703] [4.9/5/6/7 Regression] ICE in wide_int_to_tree, at tree.c:1488

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #7 from Richard Biener  ---
GCC 4.9 branch is being closed