[Bug c++/70571] New: ICE on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2259

[su at cs dot ucdavis.edu]

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

Bug ID: 70571
   Summary: ICE on valid code on x86_64-linux-gnu in
verify_ctor_sanity, at cp/constexpr.c:2259
   Product: gcc
   Version: 6.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: ---

The following code causes an ICE when compiled with the current GCC trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 5.3.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/6.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 6.0.0 20160406 (experimental) [trunk revision 234771] (GCC) 
$ 
$ g++-5.3 -c small.cpp
$
$ g++-trunk -c small.cpp
small.cpp: In function ‘void foo(vec, vec, int)’:
small.cpp:4:14: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2348
   x = (z == y);
  ^
0x845da7 verify_ctor_sanity
../../gcc-source-trunk/gcc/cp/constexpr.c:2347
0x85314f cxx_eval_bare_aggregate
../../gcc-source-trunk/gcc/cp/constexpr.c:2382
0x84ddb0 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3862
0x85192d cxx_eval_binary_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1716
0x84d414 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3795
0x854639 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4110
0x855c8b potential_constant_expression_1
../../gcc-source-trunk/gcc/cp/constexpr.c:5093
0x741eb4 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9334
0x742614 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:20793
0x741c91 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9074
0x744329 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9222
0x744a9f cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10683
0x7327eb cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10534
0x73349c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10806
0x73358f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10760
0x751dcf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20653
0x751dcf cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20689
0x752871 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25351
0x753467 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25263
0x753467 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18429
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


typedef int vec __attribute__ ((vector_size (sizeof (int;
void foo (vec x, vec y, int z)
{
  x = (z == y);
}

[Bug libstdc++/51749] Including pollutes global namespace

[yselkowi at redhat dot com]

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

--- Comment #32 from Yaakov Selkowitz  ---
In an effort to enable C99-in-C++ functionality on newlib-based targets
(including Cygwin and RTEMS), we just overhauled our feature test macros to be
functionally compatible with glibc's.  Ignoring the lack of missing long double
real and complex math functions (which are anyways guarded separately), we were
able to thereby enable the rest of _GLIBCXX_USE_C99* functionality without the
-D_GNU_SOURCE hack.

Our approach was (in glibc terms):

* enable __USE_ISOC99 in features.h if defined(__cplusplus), for C99-in-TR1;

* enable __USE_ISOC11 in features.h if __cplusplus >= 201103L, for *quick_exit
in C++11.

* define the _POSIX_* capability macros in  regardless of
__USE_POSIX*, for gthr-posix.h.

Note that the public -D_ISOC*_SOURCE macros were NOT defined in g++.

However, we don't need ftello64 (Cygwin's off_t is naturally 64-bit) nor do we
have the locale_t group of functions, which according to the Linux man-pages
are SUSv4.  These functions may be best served by their own special guards.

[Bug c++/70570] New: Assembler error "symbol already defined" from nested lambdas and function-static variable

[ndkrempel at gmail dot com]

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

Bug ID: 70570
   Summary: Assembler error "symbol already defined" from nested
lambdas and function-static variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndkrempel at gmail dot com
  Target Milestone: ---

Created attachment 38209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38209=edit
Minimal test case, compile with g++ -std=c++14

Referring to a function-static variable from within both of two nested lambda
functions (the outer one being generic/polymorphic) causes an assembler error
(symbol already defined).

Minimal test case attached, tested on g++ 5.3.0.

[Bug bootstrap/70569] configure: error: source directory already configured; run "make distclean" there first

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |bootstrap

--- Comment #1 from Andrew Pinski  ---
Most people don't build in the src directory and it is not supported at least
as far as I know.
Please read the installation directions for more details.

[Bug libstdc++/70569] New: configure: error: source directory already configured; run "make distclean" there first

[mario.silva.costa at gmail dot com]

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

Bug ID: 70569
   Summary: configure: error: source directory already configured;
run "make distclean" there first
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.silva.costa at gmail dot com
  Target Milestone: ---

Created attachment 38208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38208=edit
libstdc++-v3 config.log

on ubuntu 14.04 64 bit.

./configure --disable-multilib && make

fails to compile.

mkdir -p -- x86_64-pc-linux-gnu/libstdc++-v3
Checking multilib configuration for libstdc++-v3...
Configuring stage 1 in x86_64-pc-linux-gnu/libstdc++-v3
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: error: source directory already configured; run "make distclean"
there first
make[2]: *** [configure-stage1-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/home/atritoman/gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/atritoman/gcc'
make: *** [all] Error 2

[Bug target/70568] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
sradi, that is.

[Bug target/70568] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-07
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Still better is

xscvdpspn 0,1
mfvsrd 3,0
srdi 3,3,32

[Bug target/70568] New: PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[anton at samba dot org]

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

Bug ID: 70568
   Summary: PowerPC64: union of floating and fixed doesn't use
POWER8 GPR/VSR moves
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

The following test case from both glibc and openlibm:

typedef union
{
  float value;
  /* FIXME: Assumes 32 bit int.  */
  unsigned int word;
} ieee_float_shape_type;

/* Get a 32 bit int from a float.  */

#define GET_FLOAT_WORD(i,d) \
do {\
  ieee_float_shape_type gf_u;   \
  gf_u.value = (d); \
  (i) = gf_u.word;  \
} while (0)

int foo(float d)
{
int i;

GET_FLOAT_WORD(i, d);

return i;
}

Uses the stack to do the conversion:

foo:
stfs 1,-16(1)
ori 2,2,0
lwa 3,-16(1)

LLVM does what I expect:

foo:
xscvdpspn 0, 1
xxsldwi 0, 0, 0, 3
mfvsrwz 3, 0
extsw 3, 3

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> The patch changes the order of the subscript functions

Oops, that's accesses, actually.

> (that was the easiest
> for me to implement) to:
>   [alias set, first subscript, last subscript]

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 38207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38207=edit
demonstrator patch

In add_pdr_constraints, for the EXTRADIM=0 case we have:
...
accesses: { S_4[i1, i2] -> [1, 1 + i1] }
subscript_sizes: { [1, i1] : i1 >= 0 and i1 <= 3 }
intersection: { S_4[i1, i2] -> [1, 1 + i1] : i1 >= -1 and i1 <= 2 }
...

but for the EXTRADIM=1 case, we have:
...
accesses: { S_4[i1, i2] -> [1, 0, 1 + i1] }
subscript_sizes: { [1, i1, 0] : i1 >= 0 and i1 <= 3 }
intersection: { S_4[-1, i2] -> [1, 0, 0] }
...

Actually, the accesses are ordered:
  [alias set, last subscript, first subscript]
and the subscript sizes are ordered:
  [alias set range, first subscript range, last subscript range]
and that explains why intersection gives unintended results.

The patch changes the order of the subscript functions (that was the easiest
for me to implement) to:
  [alias set, first subscript, last subscript] 
and we get a more reasonable intersection (similar to the EXTRADIM=0 case):
...
accesses: { S_4[i1, i2] -> [1, 1 + i1, 0] }
subscript_sizes: { [1, i1, 0] : i1 >= 0 and i1 <= 3 }
intersection: { S_4[i1, i2] -> [1, 1 + i1, 0] : i1 >= -1 and i1 <= 2 }
...
and consequently, correct dependences, and the wrong-code issue is fixed.

Atm though I've got no clue about the overall effect of this change, or what
the actual fix should look like.

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[ppalka at gcc dot gnu.org]

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

--- Comment #14 from Patrick Palka  ---
Author: ppalka
Date: Wed Apr  6 23:10:14 2016
New Revision: 234802

URL: https://gcc.gnu.org/viewcvs?rev=234802=gcc=rev
Log:
Fix C++ side of PR c/70436 (missing -Wparentheses warnings)

gcc/cp/ChangeLog:

PR c/70436
* parser.c (cp_parser_iteration_statement): New parameter IF_P.
Pass it through to cp_parser_already_scoped_statement.
(cp_parser_already_scoped_statement): New parameter IF_P.  Pass
it through to cp_parser_statement.
(cp_parser_statement): Pass IF_P through to
cp_parser_iteration_statement.
(cp_parser_pragma): Adjust call to
cp_parser_iteration_statement.

gcc/testsuite/ChangeLog:

PR c/70436
* g++.dg/warn/Wparentheses-29.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wparentheses-29.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[ppalka at gcc dot gnu.org]

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

--- Comment #13 from Patrick Palka  ---
Author: ppalka
Date: Wed Apr  6 23:07:21 2016
New Revision: 234801

URL: https://gcc.gnu.org/viewcvs?rev=234801=gcc=rev
Log:
Fix new -Wparentheses warnings encountered during bootstrap

gcc/ChangeLog:

PR c/70436
* gimplify.c (gimplify_omp_ordered): Add explicit braces to
resolve a future -Wparentheses warning.
* omp-low.c (scan_sharing_clauses): Likewise.
* tree-parloops.c (eliminate_local_variables): Likewise.

gcc/cp/ChangeLog:

PR c/70436
* cp-tree.h (FOR_EACH_CLONE): Restructure macro to avoid
potentially generating a future -Wparentheses warning in its
callers.

gcc/fortran/ChangeLog:

PR c/70436
* openmp.c (gfc_find_omp_udr): Add explicit braces to resolve a
future -Wparentheses warning.

gcc/testsuite/ChangeLog:

PR c/70436
* g++.dg/plugin/pragma_plugin.c (handle_pragma_sayhello): Add
explicit braces to resolve a future -Wparentheses warning.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c
trunk/gcc/tree-parloops.c

[Bug c++/70567] internal compiler error: in retrieve_specialization, at cp/pt.c:1020

[pangbw at gmail dot com]

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

--- Comment #1 from baoshan  ---
This issue is seen from 4.8 to 5.0.

[Bug c++/70567] New: internal compiler error: in retrieve_specialization, at cp/pt.c:1020

[pangbw at gmail dot com]

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

Bug ID: 70567
   Summary: internal compiler error: in retrieve_specialization,
at cp/pt.c:1020
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

1. cat y.C:

template < class > struct allocator_traits;
template < class > class allocator;
template < class _Ty > struct allocator_traits  >
{
  typedef _Ty value_type;
  typedef value_type *pointer;
  template < class _Other > using rebind_traits =
allocator_traits < allocator < _Other > >;
};
int test()
{
   allocator_traits::rebind_traits::pointer pt;
}

2. ./xgcc -std=c++11 -S -B. y.c
y.C: In substitution of 'template using rebind_traits =
allocator_traits > [with _Other = int]':
y.C:12:58:   required from here
y.C:8:46: internal compiler error: in retrieve_specialization, at cp/pt.c:1020
 allocator_traits < allocator < _Other > >;
  ^

[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
I am planning to submit the following patch

--- ../_clean/gcc/fortran/intrinsic.texi2016-01-04 19:51:09.0
+0100
+++ gcc/fortran/intrinsic.texi  2016-04-06 17:15:01.0 +0200
@@ -12628,10 +12628,12 @@ Does not return anything.
 See @code{RAND} and @code{IRAND} for examples.

 @item @emph{Notes}:
-The Fortran 2003 standard specifies the intrinsic @code{RANDOM_SEED} to
-initialize the pseudo-random numbers generator and @code{RANDOM_NUMBER}
-to generate pseudo-random numbers. Please note that in
-GNU Fortran, these two sets of intrinsics (@code{RAND},
+The Fortran standard specifies the intrinsic subroutines
+@code{RANDOM_SEED} to initialize the pseudo-random numbers
+generator and @code{RANDOM_NUMBER} to generate pseudo-random numbers.
+These subroutines should be used in new codes.
+
+Please note that in GNU Fortran, these two sets of intrinsics (@code{RAND},
 @code{IRAND} and @code{SRAND} on the one hand, @code{RANDOM_NUMBER} and
 @code{RANDOM_SEED} on the other hand) access two independent
 pseudo-random number generators.

[Bug fortran/52884] double precision constants promoted to 16 byte by -fdefault-real-8

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
I am planning to submit the following patch

--- ../_clean/gcc/fortran/invoke.texi   2016-03-13 09:07:16.0 +0100
+++ gcc/fortran/invoke.texi 2016-04-06 20:44:26.0 +0200
@@ -361,9 +361,10 @@ it does not promote variables with expli
 @opindex @code{fdefault-double-8}
 Set the @code{DOUBLE PRECISION} type to an 8 byte wide type.  Do nothing if
this
 is already the default.  If @option{-fdefault-real-8} is given,
-@code{DOUBLE PRECISION} would instead be promoted to 16 bytes if possible, and
+@code{DOUBLE PRECISION} would instead be promoted to 16 bytes if possible,
+as well as double real constants like @code{1.d0}, and
 @option{-fdefault-double-8} can be used to prevent this.  The kind of real
-constants like @code{1.d0} will not be changed by @option{-fdefault-real-8}
+constants like @code{1.0_8} will not be changed by @option{-fdefault-real-8}
 though, so also @option{-fdefault-double-8} does not affect it.

 @item -finteger-4-integer-8

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> The code in #5 is missing the initial parenthesised expression that exposes
> the flaw in parsing logic - the left hand operand of the string concatenation
> needs to be `('(')`, and not just the string literal.

Indeed! Note that gfortran accepts '(' // ('A)'), or ('(' // 'A)'). AFAICT the
problem occurs only when the first substring is enclosed in parentheses.

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[ian_harvey at bigpond dot com]

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

--- Comment #6 from Ian Harvey  ---
The code in #5 is missing the initial parenthesised expression that exposes the
flaw in parsing logic - the left hand operand of the string concatenation needs
to be `('(')`, and not just the string literal.

[Bug c/70566] Bad ARM code generated for evaluating unsigned int bitfield value

[dan at reactivated dot net]

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

--- Comment #2 from Daniel Drake  ---
Created attachment 38206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38206=edit
main.i preprocessed output

[Bug c/70566] Bad ARM code generated for evaluating unsigned int bitfield value

[dan at reactivated dot net]

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

--- Comment #1 from Daniel Drake  ---
Created attachment 38205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38205=edit
other.c test case source

[Bug c/70566] New: Bad ARM code generated for evaluating unsigned int bitfield value

[dan at reactivated dot net]

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

Bug ID: 70566
   Summary: Bad ARM code generated for evaluating unsigned int
bitfield value
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at reactivated dot net
  Target Milestone: ---

Created attachment 38204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38204=edit
main.c test case source

I have reproduced on gcc-4.9.2, gcc-4.9.3, and gcc-5.3.1 in Debian.

System type: ODROID-U2 (Exynos4412) ARMv7

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-13'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.3.1 20160323 (Debian 5.3.1-13) 



With a struct set up with bitfield values like this:

struct mystruct {
unsigned int uid_set : 1;
unsigned int is_loaded : 1;
unsigned int nonexistent : 1;
};

The following C code is compiled to bad ARMv7 assembly under certain
circumstances at -O2:

if (!user->is_loaded) 
set_is_loaded (user, 1);

The resultant bad assembly is:

  14:   7803ldrbr3, [r0, #0]
  16:   079blslsr3, r3, #30
  18:   d400bmi.n   1c 
  1a:   d000beq.n   1e 
  1c:   4770bx  lr
  1e:   e7efb.n 0 

In the bitfield, uid_set is bit 0 and is_loaded is bit 1.

The assembly loads the bitfield value and shifts left to have the value of
is_loaded at bit 31. So the "bmi" instruction makes perfect sense: if is_loaded
is set, jump to some code that is not going to call set_is_loaded.

The following "beq" instruction is bad. Here we have is_loaded at bit 31, but
we also have uid_set at bit 30. So the value of uid_set is clearly going to
influence the code behaviour here: if uid_set is 1, we will not call
set_is_loaded.

This issue originates from freedesktop's accountsservice where I noticed the
incorrect runtime behaviour.

I am attaching a minimal test case which you can compile with:
gcc -O2 -g -c main.c -o out.o
gcc -c other.c -o other.o
gcc other.o out.o -o prog

Run with:

./prog 0
./prog 1

The argument controls the value of uid_set. It should have no effect on the
runtime behaviour, but you'll notice that myfunc is only called when the arg is
0.

Unfortunately I couldn't figure out how to slim down the test case into a
single file, as that resulted in different (working) asm being generated.

I'm also attaching the preprocessed version of main.c.

[Bug preprocessor/69391] [5 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[5/6 Regression] Incorrect  |[5 Regression] Incorrect
   |__LINE__ expansion with |__LINE__ expansion with
   |-ftrack-macro-expansion=0   |-ftrack-macro-expansion=0
   |on g++5.2   |on g++5.2

--- Comment #7 from Richard Henderson  ---
Fixed for gcc6.

[Bug preprocessor/60723] Line directives with incorrect system header flag

[rth at gcc dot gnu.org]

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

Bug 61817 Summary: Inconsistent location of tokens in the expansion list of a 
built-in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817

   What|Removed |Added

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

[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Henderson  ---
Fixed.

[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro

[rth at gcc dot gnu.org]

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

--- Comment #4 from Richard Henderson  ---
Author: rth
Date: Wed Apr  6 18:35:16 2016
New Revision: 234794

URL: https://gcc.gnu.org/viewcvs?rev=234794=gcc=rev
Log:
PR preprocessor/61817
PR preprocessor/69391

  * internal.h (_cpp_builtin_macro_text): Update decl.
  * macro.c (_cpp_builtin_macro_text): Accept location for __LINE__.
  (builtin_macro): Accept a second location for __LINE__.
  (enter_macro_context): Compute both virtual and real expansion
  locations for the macro.

  * gcc.dg/pr61817-1.c: New test.
  * gcc.dg/pr61817-2.c: New test.
  * gcc.dg/pr69391-1.c: New test.
  * gcc.dg/pr69391-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61817-1.c
trunk/gcc/testsuite/gcc.dg/pr61817-2.c
trunk/gcc/testsuite/gcc.dg/pr69391-1.c
trunk/gcc/testsuite/gcc.dg/pr69391-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/internal.h
trunk/libcpp/macro.c

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Wed Apr  6 18:35:16 2016
New Revision: 234794

URL: https://gcc.gnu.org/viewcvs?rev=234794=gcc=rev
Log:
PR preprocessor/61817
PR preprocessor/69391

  * internal.h (_cpp_builtin_macro_text): Update decl.
  * macro.c (_cpp_builtin_macro_text): Accept location for __LINE__.
  (builtin_macro): Accept a second location for __LINE__.
  (enter_macro_context): Compute both virtual and real expansion
  locations for the macro.

  * gcc.dg/pr61817-1.c: New test.
  * gcc.dg/pr61817-2.c: New test.
  * gcc.dg/pr69391-1.c: New test.
  * gcc.dg/pr69391-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61817-1.c
trunk/gcc/testsuite/gcc.dg/pr61817-2.c
trunk/gcc/testsuite/gcc.dg/pr69391-1.c
trunk/gcc/testsuite/gcc.dg/pr69391-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/internal.h
trunk/libcpp/macro.c

[Bug c++/70565] ICE at gimplify.c:8832 (cilkplus array extension)

[yves.vandriessche at intel dot com]

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

--- Comment #1 from Yves Vandriessche  ---
Additionally, the same internal compile error is produced when substituting:

>  cilk_for ( int row = 0; row < nrows; row++ ) {

with

>#pragma omp parallel scheduler(dynamic, 256)
>  for ( int row = 0; row < nrows; row++ ) {

[Bug c++/70565] New: ICE at gimplify.c:8832 (cilkplus array extension)

[yves.vandriessche at intel dot com]

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

Bug ID: 70565
   Summary: ICE at gimplify.c:8832 (cilkplus array extension)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yves.vandriessche at intel dot com
  Target Milestone: ---

Created attachment 38203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38203=edit
test case producing ICE in gimplify_expr, at gimplify.c:8832

using: gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
running on: Ubuntu-5.10

Attached file produces the following ICE

> test.cpp:11:18: internal compiler error: in gimplify_expr, at 
> gimplify.c:8832

with the guilty code segment in question being:

> cilk_for ( int row = 0; row < nrows; row++ ) {
>   int row_nnz = nrows/2;
>   int col_offsets[row_nnz];
>   col_offsets[:] = __sec_implicit_index(0);
> }

Note that I do not get an ICE when using a regular 'for' instead of the above
'cilk_for'.

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Jason Vas Dias from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Where do you see -nostdlib being used?  I see it neither in your #c0, nor in
> > #c1.
> > Looking at my buildlog, -nostdlib is used to link only some libraries, like
> > libstdc++.so.6 itself, or libvtv, libsanitizer libraries,
> > libcc1/libcc1plugin, libcilkrts, libgcj, libgcj_bc, libgij, libjvm,
> > libgcj-tools, but certainly not when linking build/*, or gcov, or cc1, ...
> 
> Yes, sorry, -nostdlib is not being used explicitly - but we seem to be 
> getting the same effect with xg++ .

Only you seem to be getting that effect, for everybody else it works just fine.
So the question is why it doesn't work for you.

[Bug libstdc++/70564] New: Problem with std::experimental::not_fn

[rcc.dark at gmail dot com]

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

Bug ID: 70564
   Summary: Problem with std::experimental::not_fn
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcc.dark at gmail dot com
  Target Milestone: ---

Hi all. The following code does not compile under MinGW-64 GCC 5.2.0 / Linux-64
GCC 5.3.1:

#include 
#include 

int main( )
{
   auto lambda = [](auto i) {
  return i == 5;
   };

   std::array arr;
   std::find_if(arr.begin( ), arr.end( ), std::experimental::not_fn(lambda));
}

Inside std::find_if, an object of the _Iter_Pred class is created:

  _Iter_pred(_Predicate __pred)
: _M_pred(__pred)
  { }

which calls _Not_fn(_Not_fn&) since __pred is an lvalue. However,
between these _Not_fn constructors:

  template
explicit
_Not_fn(_Fn2&& __fn) : _M_fn(std::forward<_Fn2>(__fn)) { }

_Not_fn(const _Not_fn& __fn) = default;
_Not_fn(_Not_fn&& __fn) = default;

the first one wins and triggers an error.

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

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

--- Comment #9 from Jason Vas Dias  ---
(In reply to Jakub Jelinek from comment #8)
> Where do you see -nostdlib being used?  I see it neither in your #c0, nor in
> #c1.
> Looking at my buildlog, -nostdlib is used to link only some libraries, like
> libstdc++.so.6 itself, or libvtv, libsanitizer libraries,
> libcc1/libcc1plugin, libcilkrts, libgcj, libgcj_bc, libgij, libjvm,
> libgcj-tools, but certainly not when linking build/*, or gcov, or cc1, ...

Yes, sorry, -nostdlib is not being used explicitly - but we seem to be 
getting the same effect with xg++ .

The problem is then that the stage2 xg++ is not adding -lstd++ automatically, 
and the scripts are not adding it to the stage2 configure's LDFLAGS - I think
they should be, or the part of them that is meant to be doing this has failed
to do so in my case . 
Any pointers as to where precisely in the build script code to look for where
-lstdc++ should be being added to the stage2 build LDFLAGS , or is it that 
xg++ should have been adding -lstdc++ if required , but wasn't ? 
Some clarification on that last point would be greatly appreciated.

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Where do you see -nostdlib being used?  I see it neither in your #c0, nor in
#c1.
Looking at my buildlog, -nostdlib is used to link only some libraries, like
libstdc++.so.6 itself, or libvtv, libsanitizer libraries, libcc1/libcc1plugin,
libcilkrts, libgcj, libgcj_bc, libgij, libjvm, libgcj-tools, but certainly not
when linking build/*, or gcov, or cc1, ...

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

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

--- Comment #7 from Jason Vas Dias  ---
So since I've produced a working Stage3 compiler in the build directory, './',
'./prev-gcc' should be the directory containing the Stage2 gcc build, and
it does in my case, with a config.log :


$ grep '^LDFLAGS=' prev-gcc/config.log
LDFLAGS='-static-libstdc++ -static-libgcc '

Now I think that this command should produce the output :


$ grep '^LDFLAGS=' prev-gcc/config.log
LDFLAGS='-static-libstdc++ -static-libgcc -lstdc++'

because we know that all the executables are produced with xg++  
given the '-nostdlib' option, and all C++ executables should be
linked against libstdc++ .

My question is simply why isn't the missing '-lstdc++' there ?

Next question: where is the code that is meant to be adding it somehow ?

[Bug c++/70029] [6 Regression] ICE with C++11 and -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Hmm, both options sounds quite involved. Perhaps for stage4 we can simply drop
the sanity check and add yet another FIXME to the verifier? Alias.c is
relatively robust about walking to main variants so I can't think of wrong code
issue caused by this.

Honza

Index: tree.c
===
--- tree.c  (revision 234761)
+++ tree.c  (working copy)
@@ -13584,7 +13584,8 @@ verify_type (const_tree t)
   debug_tree (ct);
   error_found = true;
 }
-  if (TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VARIANT (ct) != ct)
+  /* FIXME: this is volated by C++ frontend as discussed in PR70029.  */
+  if (TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VARIANT (ct) != ct && 0)
{
   error ("TYPE_CANONICAL of main variant is not main variant");
   debug_tree (ct);
Index: testsuite/g++.dg/torture/pr70029.C
===
--- testsuite/g++.dg/torture/pr70029.C  (revision 0)
+++ testsuite/g++.dg/torture/pr70029.C  (working copy)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++11 -g -flto" } */
+/* { dg-require-effective-target lto } */
+struct A
+{
+  A();
+  int foo() && __attribute__ ((__warn_unused_result__)) { return 0; }
+};
+
+A a;
+

[Bug c++/66487] sanitizer/warnings for lifetime DSE

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-06
Summary|[6 Regression] Firefox  |sanitizer/warnings for
   |segfault with LTO enabled   |lifetime DSE
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #19 from Jan Hubicka  ---
Martin, I suppose the sanitizer bits can be tracked as enhancement and not
regression. It is a firefox bug so I suppose we can declare this a
non-regression.

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Apr  6 16:48:36 2016
New Revision: 234792

URL: https://gcc.gnu.org/viewcvs?rev=234792=gcc=rev
Log:
2016-04-06  Vladimir Makarov  

PR rtl-optimization/70398
* lra-constraints.c (process_address_1): Check zero scale and code
for reloading with zero scale.

2016-04-06  Vladimir Makarov  

PR rtl-optimization/70398
* testsuite/gcc.target/aarch64/pr70398.c: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr70398.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70563] New: SFINEA fails when trying invalid template instantiation

[webmaster at havogt dot de]

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

Bug ID: 70563
   Summary: SFINEA fails when trying invalid template
instantiation
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webmaster at havogt dot de
  Target Milestone: ---

vogt@fermi03:~/temp2> cat test_SFINAE_with_template_binding.ii 
# 1 "test_SFINAE_with_template_binding.cc"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test_SFINAE_with_template_binding.cc"




template using void_t = void;

template struct TemporaryBindObject
{
};

struct MyTrueType
{
 static constexpr bool value = true;
};

struct MyFalseType
{
 static constexpr bool value = false;
};

template