[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Jakub Jelinek changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #12 from Jakub Jelinek --- *** Bug 70567 has been marked as a duplicate of this bug. ***
[Bug c++/70567] internal compiler error: in retrieve_specialization, at cp/pt.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70567 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- This got fixed with r218955, and the ICE started with r181118 when template aliases have been introduced. In r234337 it has been backported to 4.9, so it is fixed on all currently supported releases. *** This bug has been marked as a duplicate of bug 61198 ***
[Bug c++/70572] New: ICE on code with decltype (auto) on x86_64-linux-gnu in digest_init_r, at cp/typeck2.c:1103 with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70572
Bug ID: 70572
Summary: ICE on code with decltype (auto) on x86_64-linux-gnu
in digest_init_r, at cp/typeck2.c:1103 with -std=c++14
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.
It also affects 4.9.x and later, which support -std=c++14.
$ 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++-trunk -c -std=c++14 small.cpp
small.cpp: In function ‘int foo()’:
small.cpp:3:23: internal compiler error: in digest_init_r, at cp/typeck2.c:1103
decltype (auto) a = foo; // OK: decltype (auto) a = &foo;
^~~
0x6cd59c digest_init_r
../../gcc-source-trunk/gcc/cp/typeck2.c:1099
0x6cf2ea digest_init_flags
../../gcc-source-trunk/gcc/cp/typeck2.c:1168
0x6cf2ea store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc-source-trunk/gcc/cp/typeck2.c:802
0x62fbf4 check_initializer
../../gcc-source-trunk/gcc/cp/decl.c:6162
0x659865 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl.c:6810
0x752f9f cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18658
0x753750 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12379
0x753a61 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12248
0x7544b8 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11860
0x732b7b cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10528
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
0x753750 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12379
0x753a61 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12248
0x75c5d0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12145
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.
$
--
int foo ()
{
decltype (auto) a = foo; // OK: decltype (auto) a = &foo;
return 0;
}
[Bug c++/70571] New: ICE on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2259
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
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
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&action=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
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
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&action=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
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
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
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
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
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&action=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
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&root=gcc&view=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
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&root=gcc&view=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
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
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
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
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
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
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
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&action=edit main.i preprocessed output
[Bug c/70566] Bad ARM code generated for evaluating unsigned int bitfield value
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&action=edit other.c test case source
[Bug c/70566] New: Bad ARM code generated for evaluating unsigned int bitfield value
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&action=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
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
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
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
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&root=gcc&view=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
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&root=gcc&view=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)
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)
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&action=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++' .
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
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++' .
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++' .
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++' .
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
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
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
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&root=gcc&view=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
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 class Dest> struct TestValidBind
{
template> struct toTypesOf : MyFalseType
{};
template class Src, typename... Ts> struct
toTypesOf, void_t>> : MyTrueType
{};
};
template struct OneParamStruct
{
};
template struct TwoParamStruct
{
};
using tmp = TemporaryBindObject;
int main()
{
bool value1 =
TestValidBind::toTypesOf>::value;
bool value2 =
TestValidBind::toTypesOf>::value;
}
vogt@fermi03:~/temp2> g++-5 -std=c++11 test_SFINAE_with_template_binding.ii
test_SFINAE_with_template_binding.cc: In function ‘int main()’:
test_SFINAE_with_template_binding.cc:41:16: error: incomplete type
‘TestValidBind::toTypesOf >’ used in
nested name specifier
bool value2 =
TestValidBind::toTypesOf>::value;
^
vogt@fermi03:~/temp2> g++-5 --version
g++-5 (SUSE Linux) 5.3.1 20160301 [gcc-5-branch revision 233849]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The example works with clang. I am not a standard expert to decide who is
right. Actually, a simplified version works with gcc, however I don't see the
reason why this shouldn't, see http://stackoverflow.com/a/36411945/5085250
Same problem with
vogt@fermi03:~/temp2> g++-6 --version
g++-6 (SUSE Linux) 6.0.0 20160324 (experimental) [trunk revision 234449]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336
Yves Vandriessche changed:
What|Removed |Added
CC||yves.vandriessche at intel dot
com
--- Comment #8 from Yves Vandriessche ---
reconfirming for g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
compiling with -std-gnu++11 -fcilkplus
I did find a workaround: I do not get the error if I avoid using the array
notation extension on a member. Using a local variable that takes on the
pointer value of the member compiles perfectly.
> struct Test {
> int nrows;
> int * rows;
> Test(int _nrows, int * in_rows): nrows(_nrows) {
> rows = new int[nrows + 1];
>
> // internal compiler error: in find_rank, at
> c-family/array-notation-common.c:244
> rows[0:nrows+1] = 0;
>
> // // workaround
> // int * _rows = rows;
> // _rows[0:nrows+1] = 0;
> }
> };
>
> int main() {
> Test t{1024*1024, nullptr};
> }
[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519 --- Comment #6 from Jason Vas Dias --- Yes, Jakub, thanks, I know : > If you link with g++ or xg++ instead of gcc or xgcc, then the driver is > adding > -lstdc++ automatically. But it is not ME linking, it is the gcc-5.3.0 Makefile.in / configure.ac scripts . It seems to me on cursory inspection of these huge scripts that neither of them are explicitly adding '-lstdc' anywhere onto the link lines for xg++ links, nor to LDFLAGS or ALL_LINKERFLAGS or BUILD_LDFLAGS or any link line containing LDFLAGS , as shown by this grep in the unmodified GCC 5.3.0 source directory: [root@localhost:/usr/os_src/gcc-5.3.0 [4360] 16:23:17 #:8!:4399] $ egrep '(LINKER|LD)FLAGS' Makefile.in Makefile.def Makefile.tpl gcc/Makefile.in | egrep -i stdc\\+\\+\|stdc\[xp\]+ [root@localhost:/usr/os_src/gcc-5.3.0 $ ie. no references to 'stdc++' or stdcxx (case insensitive) in any line containing LDFLAGS or LINKER in any make script . So it is very difficult to find the exact line of code that is meant to be adding the '-lstdc++' and somehow failed to do so in my case ! Is it meant to be added to LDFLAGS during the stage2 gcc configure using xg++ as the compiler ($CC) ? A search of the huge configure.ac scripts yields no results : $ egrep '(LINKER|LD)FLAGS' configure.ac gcc/configure.ac | egrep -i stdc\\+\\+\|stdc\[xp]+ configure.ac: LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc" $ So how are the build scripts meant to be adding '-lstdc++' to the link lines of executables produced by the stage2 xg++ ? This is far from clear.
[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #5 from Dominique d'Humieres ---
Note that the following test compiles with gfortran from at least 4.8 up to
trunk (6.0)
PROGRAM ReadMeTwo
IMPLICIT NONE
CHARACTER(10) :: var
READ '('//'A)', var
PRINT *, var
END PROGRAM ReadMeTwo
[Bug fortran/47040] Make error message for empty array constructor more helpful/correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040 --- Comment #6 from Dominique d'Humieres --- Patch submitted at https://gcc.gnu.org/ml/fortran/2016-04/msg00024.html.
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- The #c0 changed behavior with r226652. And the #c2 looks like PR70528.
[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70501 --- Comment #3 from Nathan Sidwell --- https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00191.html but read the thread for why that's not the best patch. Continuing ...
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 Paul Brannan changed: What|Removed |Added CC||curlypaul924 at gmail dot com --- Comment #8 from Paul Brannan --- I am able to reproduce this segfault with the above instructions on gdb 7.11.
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #20 from Dominique d'Humieres --- Fixed on trunk (6.0), closing.
[Bug target/70559] Miscompilation of nsTextFormatter.cpp from Firefox with -Os -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70559 --- Comment #4 from Jakub Jelinek --- Seems this got fixed (or is dup of) PR64905, r220416 in particular, but you want r220414 and r220441 too.
[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- If you link with g++ or xg++ instead of gcc or xgcc, then the driver is adding -lstdc++ automatically.
[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70348 --- Comment #9 from cesar at gcc dot gnu.org --- The patch I posted for PR70289 a couple of days ago also resolves this issue: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00202.html
[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #4 from Jason Vas Dias ---
Thanks for having a look at this, Richard .
Yes, "some weirdness" is definitely going on -
but I'd like to determine precisely which "weirdness".
This occurred when building my new LFS system's system compiler
for the first time, with a GCC-5.2.0 instance built for RHEL-6,
whose installation directories were all mounted with the 'bind'
option ( /usr/lib/gcc/x86_64-redhat-linux/5.2.0 ,
/usr/libexec/gcc/x86_64-redhat-linux/5.2.0 , etc. )
and where $PATH picked up all gcc binaries from a
'bin/' directory containing links like :
gcc -> /${path_to_rhel6_usr_bin}/gcc5.2.0
... etc.
My configure options were :
/usr/os_src/gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared \
--enable-languages=all \
--enable-bootstrap \
--enable-multilib \
--with-cpu-64=haswell \
--with-cpu-32=atom \
--with-arch-64=x86-64 \
--with-tune-64=haswell \
--with-arch-32=i686 \
--with-tune-32=atom \
--enable-targets=all \
--enable-threads=posix \
--enable-lto \
--enable-serial-configure \
--enable-checking=release \
--with-stage1-ldflags='-L/usr/lib64 -L/usr/local/lib64 -L/usr/lib32
-L/usr/local/lib32
-Wl,-R,/usr/lib64:/usr/local/lib64:/usr/lib32:/usr/local/lib32' \
--with-gmp=/usr --with-gmp-lib=/usr/lib64 \
--with-mpfr=/usr --with-mpfr-lib=/usr/lib64 \
--with-mpc=/usr --with-mpc-lib=/usr/lib64 \
--with-isl=/usr --with-isl-lib=/usr/lib64 \
--with-cloog=/usr --with-cloog-lib=/usr/lib64 \
--with-gnu-ld \
--with-gnu-as \
--enable-linker-build-id \
--disable-libunwind-exceptions \
--disable-nls \
--enable-version-specific-runtime-libs \
--enable-__cxa_atexit \
--without-x \
--disable-gtk-cairo \
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre \
--enable-libgcj-multifile \
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar \
--with-system-zlib \
--enable-java-home \
--with-arch-directory=x86_64 \
--disable-libjava-multilib \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu
I had to radically modify the ./gcc/Makefile of the build directory
to add '-static-libstdc++ -lstdc++' to EVERY executable's link command ,
finally the 'make' completed with 0 exit status, and 'make DESTDIR=... install'
created the installation directory , and the test suite passed (with some
expected failures - details on request).
The translated gcc/Makefile.in produced a gcc/Makefile containing :
LDFLAGS = -static-libstdc++ -static-libgcc
Note: no -lstdc++ - I think the '-static-libstdc++' option on its own
does NOT imply '-lstdc++' - you have to add it to actually link against
libstdc++.a .
So that is what I did , modifying the above lines:
NEEDS_STDCXX = -static-libstdc++ -lstdc++
LDFLAGS = -static-libgcc $(NEEDS_STDCXX)
and I had to add this into many other places where an executable
is being produced and LDFLAGS is not referenced:
...
ALL_LINKERFLAGS = $(ALL_CXXFLAGS) -static-libgcc $(NEEDS_STDCXX)
...
# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled. For stage2+ use the host library and
# its dependencies.
ifeq ($(build_objdir),$(build_libobjdir))
BUILD_CPPLIB = $(build_libobjdir)/libcpp/libcpp.a
else
BUILD_CPPLIB = $(CPPLIB) $(LIBIBERTY)
build/genmatch$(build_exeext): BUILD_LIBDEPS += $(LIBINTL_DEP) $(LIBICONV_DEP)
build/genmatch$(build_exeext): BUILD_LIBS += $(LIBINTL) $(LIBICONV)
$(NEEDS_STDCXX)
endif
...
I suggest making the gcc/Makefile.in / $TOPDIR/{configure.ac,Makefile.am}
add '-lstdc++' every time it writes '-static-libstdc++' to the Makefile ,
eg. $TOPDIR/configure.ac @ line 1376:
# Check whether -static-libstdc++ -static-libgcc is supported.
have_static_libs=no
if test "$GCC" = yes; then
saved_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
# ^- add ' -lstdc++' here
@ line 1718:
[stage1_ldflags=
# In stage 1, default to linking libstdc++ and libgcc statically with GCC
# if supported. But if the user explicitly specified the libraries to use,
# trust that they are doing what they want.
if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
stage1_ldflags="-static-libstdc++ -static-libgcc"
# ^- add ' -lstdc++' here
fi])
@ line 1741:
[poststage1_ldflags=
# In stages 2 and 3, default to linking libstdc++ and libgcc
# statically. But if the user explicitly specified the libraries to
# use, trust that they are doing what they want.
if test "$poststage1_libs" = ""; then
poststage1_ldflags="-static-libstdc++ -static-libgcc"
# ^- add ' -lstdc++' here
fi])
I can't put my finger on the component that is meant to add '-lstdc++'
to the poststage1_ldflags if not above modified lines ATM - what is meant
to be doing this ?
I will try building with the configure.ac so modified n
[Bug ipa/70559] Miscompilation of nsTextFormatter.cpp from Firefox with -Os -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70559
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-06
Known to work||5.3.0
Ever confirmed|0 |1
Known to fail||4.8.5, 4.9.3
--- Comment #3 from Richard Biener ---
Confirmed with 4.9.3 and branch head and 4.8.[15].
int dosprintf(SprintfState*, const char16_t*, __va_list_tag*) (struct
SprintfState * aState, const char16_t * aFmt, struct * aAp)
{
..
char16_t c;
..
:
# aFmt_8 = PHI
# DEBUG aFmt => aFmt_8
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857:24] aFmt_95 =
aFmt_8 + 2;
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857:24] # DEBUG aFmt
=> aFmt_95
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857:3] c_96 =
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857] *aFmt_8;
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857:3] # DEBUG c =>
c_96
[/home/glandium/gecko/xpcom/glue/nsTextFormatter.cpp : 857:3] if (c_96 != 0)
so everything fine on GIMPLE. GCC 5 is confirmed fixed.
[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70348 Thomas Schwinge changed: What|Removed |Added Assignee|tschwinge at gcc dot gnu.org |cesar at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- Cesar is now looking into resolving the OpenACC reduction issues.
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- >From the ChangeLogs, one of r219801 (pr61275, pr60357) or r219802 (pr64578) look the most likely to me. Closing the PR Paul
[Bug middle-end/70550] -Wuninitialized false positives in OpenMP code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70550 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug fortran/60853] Failure to disambiguate generic with unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853 Dominique d'Humieres changed: What|Removed |Added CC||baradi09 at gmail dot com --- Comment #2 from Dominique d'Humieres --- *** Bug 70562 has been marked as a duplicate of this bug. ***
[Bug fortran/70562] User defined assignment does not distinguish between ranks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70562 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr60853. *** This bug has been marked as a duplicate of bug 60853 ***
[Bug middle-end/70561] Crash in recog_for_combine_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561 Dominik Vogt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominik Vogt --- Solved with Uli's help by removing the "parallal" from the define_insn_and_split.
[Bug fortran/70562] New: User defined assignment does not distinguish between ranks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70562 Bug ID: 70562 Summary: User defined assignment does not distinguish between ranks Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- User defined assignment for derived types fails to compile, if the signature of the various assignments only differ in their rank. The snippet further below fails to compile with the error message generic :: assignment(=) => assignScalar, assignArray 1 Error: ‘assignscalar’ and ‘assignarray’ for GENERIC ‘=’ at (1) are ambiguous although the two interfaces are not ambiguous, as their differ in ther ranks. Best regards, Bálint module typedefs implicit none type :: tt integer :: data(2) contains procedure :: assignScalar procedure :: assignArray generic :: assignment(=) => assignScalar, assignArray end type tt contains subroutine assignScalar(this, other) class(tt), intent(inout) :: this class(*), intent(in) :: other print *, "assignScalar" end subroutine assignScalar subroutine assignArray(this, other) class(tt), intent(inout) :: this class(*), intent(in) :: other(:) print *, "assignScalar" end subroutine assignArray end module typedefs
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #6 from Jakub Jelinek --- In that case it is a backend enhancement request. Backends have many ways how to deal with this, starting from specialized patterns, or using the lower subreg passes, using their own splitters etc. and many of the actively maintained backends handle this right.
[Bug c++/39159] unhelpful attribute warning on matching declaration after definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159 --- Comment #6 from Gert --- I forgot to mention: the patch is against 5.3.0.
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Dominique d'Humieres changed: What|Removed |Added CC|dominiq at lps dot ens.fr | --- Comment #4 from Dominique d'Humieres --- > This is fixed on trunk and GNU Fortran (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4). > Your example even runs correctly! The ICE is gone with at least 4.9.3, but this leads to wrong code F Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x1026dd7b2 #1 0x1026ddf6e #2 0x7fff8f042529 #3 0x1026d7b38 #4 0x1026d7cd0 Segmentation fault > I have added Dominique to the CC list in the hope that he can pin down > better when it was fixed. He seems to maintain the world's largest collection > of archaic gcc's :-) Well this fall in one my blind spots!-( The ICE disappeared between revisions r201266 (2013-07-26, ICE) and r201631 (2013-08-09, wrong code). In this range, I see r201284 (pr57285), r201286 (pr57991), r201294 (pr58009), r201328 and r201329 (pr57530), r201521 (pr57306), and r201526 (pr57987). I did not look in detail at these PRs, but I think it is related to/duplicate of pr57530. The wrong code has been fixed between revisions r219797 (2015-01-17, wrong code) and r219823 (2015-01-18, expected results). In this range, I see r219798 (pr60334), r219801 (pr61275, pr60357), r219802 (pr64578), r219814 (pr55901), and r219818 (pr57959). I let you pick the candidate. > This can be closed once we pin down approximately when it was fixed.
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557
--- Comment #5 from Albert Cahalan ---
This example shows the most simple form of the problem:
unsigned long long ull;
void simple64(void){
ull = 0;
}
NOTE: In the assembly below, I might have missing/excess parentheses. Assembler
syntax varies.
gcc generates:
clr.L %d0
clr.L %d1
move.L %d0,ull
move.L %d1,ull+4
As you can see, two registers are set to the same value. It's better to set
just one, and even better to directly address memory with a clr.L instruction.
Also, given that this code was optimized for size and there was an address
register free, gcc should have put the address of ull into a register and then
used that, preferably with autoincrement addressing.
I'd like to see something like this:
movea.L ull, %a0
clr.L (%a0)+
clr.L (%a0)
When optimizing for speed and registers are not available, maybe this:
clr.L ull
clr.L ull+4
(the code is larger with those 6-byte instructions though, and it might
actually run slower especially considering the small cache)
[Bug target/67478] gcc-5.1.0/gcc-5.2.0 undefined symbol std::__once_callable in AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478 --- Comment #10 from David Edelsohn --- The libstdc++ build process was updated to recognize LTS symbols. Please use GCC 5.3 or later.
[Bug c++/39159] unhelpful attribute warning on matching declaration after definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159 Gert changed: What|Removed |Added CC||gw.fossdev at gmail dot com --- Comment #5 from Gert --- Created attachment 38202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38202&action=edit Proposed patch to silence the warning if the new attribute is same Hello, I propose the attached patch for this. I'm flying blind here and the patch is not yet tested. The idea is to search whether the attribute to be applied is already set and if this is the case, to not emit a warning, and otherwise to rephrase the warning pointing out that a different attribute was specified. The code was inspired by the lines starting from 589 in the same file gcc/attribs.c. Now since I don't know whether simple_cst_equal really compares the value of the attribute, or just some attribute type, it may be that the code does not do what I hope to achieve. Any comments how to improve the patch are very welcome. Best, Gert
[Bug middle-end/70550] -Wuninitialized false positives in OpenMP code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70550 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Apr 6 12:42:24 2016 New Revision: 234779 URL: https://gcc.gnu.org/viewcvs?rev=234779&root=gcc&view=rev Log: PR middle-end/70550 * tree.h (OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT): Define. * gimplify.c (gimplify_adjust_omp_clauses_1): Set it for implicit firstprivate clauses. * omp-low.c (lower_send_clauses): Set TREE_NO_WARNING for OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT !by_ref vars in task contexts. (lower_omp_target): Set TREE_NO_WARNING for non-addressable possibly uninitialized vars which are copied into addressable temporaries or copied for GOMP_MAP_FIRSTPRIVATE_INT. * c-c++-common/gomp/pr70550-1.c: New test. * c-c++-common/gomp/pr70550-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr70550-1.c trunk/gcc/testsuite/c-c++-common/gomp/pr70550-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #4 from Albert Cahalan --- Mostly it's more like PR58741 because of the long long issue. PR22141 (and PR23684 which is a better match) is about merging small things. Two of the six examples here show that problem, those being the ones with a loop over char. The problem that prompted this bug report and determined the bug title is different. It's in some way the opposite. When I ask gcc to store a 64-bit zero value, gcc makes a 64-bit zero value in memory (two identical 32-bit halves in a pair of 32-bit registers) and then stores that to memory. There are many ways that this is wrong, and I worry that fixing one problem may hide the other problems. Depending on compiler internals that I don't understand, this could perhaps be four bugs: 1. When the two halves of a 64-bit value are identical, there is no need to load values into two different registers. This is true for many constant values, though obviously -1 and 0 would be most popular. Other popular values would be the constants for computing a Hamming weight. AFAIK, this optimization should apply whenever dealing with values that are larger than registers, such as 128-bit values on 64-bit platforms. 2. When the address is to be encoded in the instruction that writes to memory, it is best to directly clear the memory without first generating the constant in registers. AFAIK, this optimization should apply to most CISC machines. The fact that there is a special instruction for storing a 0 makes the optimization more important. 3. When the address is to be encoded in an instruction, sometimes it is best to place the address in a register and then use that register to supply the address for storing to memory. This tends to apply when doing lots of writes, when an address register happens to be available, and when optimizing for size. AFAIK this optimization applies to most machines. 4. When using an address register to supply the location for storing, often it is best to use autoincrement addressing instead of distinct offsets. This usually generates smaller code. AFAIK this applies to many machines, including at least: arm, m68k, and ppc. (and also the store-merge issue, which makes 5)
[Bug middle-end/70561] Crash in recog_for_combine_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561 --- Comment #2 from Dominik Vogt --- (Ah, probably add_clobbers should have added the clobber, but it hasn't. It doesn't have any code for that pattern.)
[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70549 --- Comment #6 from Christophe Lyon --- I've reproduced it too with our latest 4.8, and I confirm it compiles OK with the very first commit in branch 4.9. Since you switched to 4.9, I will not investigate more.
[Bug middle-end/70561] Crash in recog_for_combine_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561 --- Comment #1 from Dominik Vogt --- P.S.: (gdb) p debug_rtx(pat) (set (reg:SI 67 [+4 ]) (and:SI (not:SI (subreg:SI (reg/v:DI 65 [ b+-4 ]) 4)) (mem:SI (plus:DI (reg:DI 2 %r2 [ a ]) (const_int 4 [0x4])) [1 *a_2(D)+4 S4 A32]))) $13 = void (gdb) p debug_rtx(newpat) (parallel [ (set (reg:SI 67 [+4 ]) (and:SI (not:SI (subreg:SI (reg/v:DI 65 [ b+-4 ]) 4)) (mem:SI (plus:DI (reg:DI 2 %r2 [ a ]) (const_int 4 [0x4])) [1 *a_2(D)+4 S4 A32]))) (nil) ]) $14 = void
[Bug middle-end/70561] New: Crash in recog_for_combine_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70561
Bug ID: 70561
Summary: Crash in recog_for_combine_1
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
This code in recog_for_combine_1 doesn't look right:
--
if (num_clobbers_to_add)
{
rtx newpat = gen_rtx_PARALLEL (VOIDmode,
rtvec_alloc (GET_CODE (pat) == PARALLEL
? (XVECLEN (pat, 0)
+ num_clobbers_to_add)
: num_clobbers_to_add + 1));
if (GET_CODE (pat) == PARALLEL)
for (i = 0; i < XVECLEN (pat, 0); i++)
XVECEXP (newpat, 0, i) = XVECEXP (pat, 0, i);
else
XVECEXP (newpat, 0, 0) = pat;
add_clobbers (newpat, insn_code_number);
for (i = XVECLEN (newpat, 0) - num_clobbers_to_add;
i < XVECLEN (newpat, 0); i++)
{
if (REG_P (XEXP (XVECEXP (newpat, 0, i), 0)) <=== crash
&& ! reg_dead_at_p (XEXP (XVECEXP (newpat, 0, i), 0), insn))
return -1;
...
--
For me, there is a crash in the marked line (for some pattern I'm working on)
with "i == 1" because "XVECEXP (newpat, 0, 1)" is "(nil)". If
"num_clobbers_to_add" is > 0, and the original "pat" is not a parallel, only
the first element of newpat is initialised, but the remaining elements are
still accessed. There probably should be something like this in the for loop?
for (...)
{
if (XVECEXP (newpat, 0, i))
/* generate clobber from scratch and store it in XVECEXP (newpat, 0, i)
*/
--
Probably triggered by this splitter:
[(parallel
[(set (match_operand:GPR 0 "nonimmediate_operand" "")
(and:GPR (not:GPR (match_operand:GPR 1 "nonimmediate_operand" ""))
(match_operand:GPR 2 "nonimmediate_operand" "")))
(clobber (reg:CC CC_REGNUM))])]
==>
[
(parallel
[(set (match_dup 3) (and:GPR (match_dup 1) (match_dup 2)))
(clobber (reg:CC CC_REGNUM))])
(parallel
[(set (match_dup 0) (xor:GPR (match_dup 3) (match_dup 2)))
(clobber (reg:CC CC_REGNUM))])]
[Bug target/60290] 32-bit g++.dg/cilk-plus/CK/catch_exc.cc FAILs on Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.1[01] |i386-pc-solaris2.1[012] Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2016-04/msg00292.ht ||ml Last reconfirmed||2016-04-06 Host|i386-pc-solaris2.1[01] |i386-pc-solaris2.1[012] Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 Build|i386-pc-solaris2.1[01] |i386-pc-solaris2.1[012] --- Comment #7 from Rainer Orth --- Mine, patch posted.
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1
[Bug libstdc++/70560] New: Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 Bug ID: 70560 Summary: Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Thomas pointed out at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01159.html that we test for atomics that work on bool, short and int when defining _GLIBCXX_ATOMIC_BUILTINS, and then if that's defined we use atomics on _Atomic_word: # Set atomicity_dir to builtins if all but the long long test above passes. if test "$glibcxx_cv_atomic_bool" = yes \ && test "$glibcxx_cv_atomic_short" = yes \ && test "$glibcxx_cv_atomic_int" = yes; then AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1, [Define if the compiler supports C++11 atomics.]) atomicity_dir=cpu/generic/atomicity_builtins fi But _Atomic_word might not be one of those types, e.g. for sparc: #ifdef __arch64__ typedef long _Atomic_word; #else typedef int _Atomic_word; #endif The choice of atomicity_dir (i.e. whether to use atomics for _Atomic_word or not) should be based on tests that actually use that type, and that type only. I think it should be OK to relax the checks so that atomic builtins are used for _Atomic_word on targets where _GLIBCXX_ATOMIC_BUILTINS previously wasn't defined. In that case new code would use the builtins via the inline functions in , and old code would continue to use the non-inline functions defined in libstdc++.so. Those non-inline functions would now come from cpu/generic/atomicity_builtins/atomicity.h and so would also use atomic builtins. It would not be OK to stop using atomics for _Atomic_word on targets where _GLIBCXX_ATOMIC_BUILTINS was previously defined. In that case, old code would use the inlined builtins but new code would call non-inline functions in cpu/generic/atomicity_mutex/atomicity.h (or a target-specific one) which might expect to be able to use non-atomic operations protected by a critical section. That expectation would not hold if other code is modifying the shared variable directly, outside the critical section. We could also review whether the __atomic_add_dispatch and __exchange_and_add_dispatch functions in really give much benefit for anything except the old COW std::string. For std::shared_ptr, std::future etc. it might make sense to simplify things and use atomics unconditionally without checking __gthread_active_p().
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #11 from Malcolm Parsons --- (In reply to Jonathan Wakely from comment #10) > > The attached patch fixes it for me. > > That seems to be a backport of r223746 from trunk, right? I'll look into > applying that to the gcc-5 branch. It looks like it. Thanks.
[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Apr 6 10:31:27 2016 New Revision: 234776 URL: https://gcc.gnu.org/viewcvs?rev=234776&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-03-11 Jakub Jelinek PR tree-optimization/70177 * gimple-expr.h (extract_ops_from_tree_1): Renamed to ... (extract_ops_from_tree): ... this. In the 2 argument overload remove _1 suffix. * gimple-expr.c (extract_ops_from_tree_1): Renamed to ... (extract_ops_from_tree): ... this. * gimple.c (gimple_build_assign, gimple_assign_set_rhs_from_tree): Adjust callers. * tree-ssa-loop-niter.c (derive_constant_upper_bound): Likewise. * tree-ssa-forwprop.c (defcodefor_name): Call 3 operand extract_ops_from_tree instead of 2 operand one. * gcc.dg/pr70177.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr70177.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimple-expr.c branches/gcc-5-branch/gcc/gimple-expr.h branches/gcc-5-branch/gcc/gimple.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-forwprop.c branches/gcc-5-branch/gcc/tree-ssa-loop-niter.c
[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70513 --- Comment #5 from Marek Polacek --- But unfortunately that patch fixes Comment 3 but not the original testcase...
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #10 from Jonathan Wakely --- (In reply to Malcolm Parsons from comment #9) > Created attachment 38201 [details] > fix undefined behaviour in stl_tree.h > > (In reply to Jonathan Wakely from comment #8) > > I believe all the real problems are fixed now. > > Clang 3.8.0 still reports undefined behaviour in stl_tree.h using GCC 5.3.0: > > lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/ > stl_tree.h:1910:28: runtime error: upcast of address 0x0225d260 with > insufficient space for an object of type 'std::_Rb_tree_node void *const, testing::(anonymous namespace)::MockObjectState> >' > 0x0225d260: note: pointer points here > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 d2 25 02 > 00 00 00 00 60 d2 25 02 > ^ That's expected, as some of the fixes are only on trunk, not the gcc-5 branch. > The attached patch fixes it for me. That seems to be a backport of r223746 from trunk, right? I'll look into applying that to the gcc-5 branch.
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 Malcolm Parsons changed: What|Removed |Added CC||malcolm.parsons at gmail dot com --- Comment #9 from Malcolm Parsons --- Created attachment 38201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38201&action=edit fix undefined behaviour in stl_tree.h (In reply to Jonathan Wakely from comment #8) > I believe all the real problems are fixed now. Clang 3.8.0 still reports undefined behaviour in stl_tree.h using GCC 5.3.0: lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/stl_tree.h:1910:28: runtime error: upcast of address 0x0225d260 with insufficient space for an object of type 'std::_Rb_tree_node >' 0x0225d260: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 d2 25 02 00 00 00 00 60 d2 25 02 ^ The attached patch fixes it for me.
[Bug fortran/65438] Unnecessary ptr check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65438 Thomas Schwinge changed: What|Removed |Added Priority|P3 |P5 Status|RESOLVED|ASSIGNED Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |cesar at gcc dot gnu.org Severity|normal |minor --- Comment #5 from Thomas Schwinge --- (In reply to Dominique d'Humieres from comment #1) > > The function check_array_not_assumed (openmp.c) performs an unnecessary > > check on pointers. > > Does this refer to sym->attr.pointer in the lines > > if (sym->as && sym->as->type == AS_DEFERRED && sym->attr.pointer > && !sym->attr.contiguous) > > ? I have now looked this up in our old internal development tree, and found the patch that I just attached, which goes with a note by Jim stating that it "removes a needless pointer check. Cesar consulted on this patch". Cesar, please resolve this in GCC trunk (low priority).
[Bug fortran/65438] Unnecessary ptr check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65438 --- Comment #4 from Thomas Schwinge --- Created attachment 38200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38200&action=edit patch
[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59093 Paul Thomas changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g, pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #10 from Paul Thomas --- It is the same as PR34640, which was already assigned to me, PR57116 and is related to PR40737. Paul
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Paul Thomas changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #3 from Paul Thomas --- Dear Valery, This is fixed on trunk and GNU Fortran (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4). Your example even runs correctly! I have added Dominique to the CC list in the hope that he can pin down better when it was fixed. He seems to maintain the world's largest collection of archaic gcc's :-) This can be closed once we pin down approximately when it was fixed. Cheers Paul
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- PR22141 ? We really should tackle that as late GIMPLE pass for GCC 7.
[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254 --- Comment #21 from Ramana Radhakrishnan --- (In reply to Nick Clifton from comment #19) > (In reply to Julien Margetts from comment #17) > > The following test case still fails with the patch applied (originally bug > > 70362) > > > > arm-none-eabi-gcc -march=armv3m -c -o c_compat_x_tst.o > > gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c > > > I cannot reproduce this failure. Ie when I compile this test case > everything works, at -O0 all the way up to -O3. > > This is with today's mainline sources, which has *both* of the patches from > this PR applied. These sources no longer contain this assertion: > > gcc_assert (REG_P (operands[0])); > > although they do contain: > > gcc_assert (REG_P (outval) || SUBREG_P (outval)); > > > If the problem really does exist, could someone tell me what outval looks > like when the assertion is triggered ? I can't seem to make this fire on trunk anymore and it does look like I was using a stale build. Sorry about the noise on trunk. Ramana > > Cheers > Nick
[Bug fortran/43207] [OOP] invalid (pointer) assignment to and from abstract non-polymorphic expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|janus at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[OOP] invalid pointer |[OOP] invalid (pointer) |assignment => type%parent |assignment to and from ||abstract non-polymorphic ||expressions --- Comment #12 from Paul Thomas --- Have changed the title to reflect the fact that the original ICE was fixed. Have also unassigned Janus, since he has been inactive for quite a long time. Paul
[Bug middle-end/70550] -Wuninitialized false positives in OpenMP code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70550 Jakub Jelinek changed: What|Removed |Added Attachment #38194|0 |1 is obsolete|| --- Comment #2 from Jakub Jelinek --- Created attachment 38199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38199&action=edit gcc6-pr70550.patch Updated patch to also handle implicit firstprivate on task/taskloop.
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|other |target --- Comment #2 from Richard Biener --- This is a known bug (partly) as GCC currently has no way to combine small stores into a larger one (apart from BB vectorization if the result fits a vector store). Too lazy to find the duplicate but you can search for it yourself. Eventually there's a m68k target piece left, so keeping open as target bug.
[Bug c++/70558] POD datatype array crash in initialization when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70558
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener ---
inline Double &operator =(const double &other) { x = other; }
you fail to return *this:
> g++-5 test.cpp -O -std=c++11 -Wall
In file included from test.cpp:3:0:
Double.h: In member function ‘Double& Double::operator=(const double&)’:
Double.h:24:63: warning: no return statement in function returning non-void
[-Wreturn-type]
inline Double &operator =(const double &other) { x = other; }
[Bug target/67478] gcc-5.1.0/gcc-5.2.0 undefined symbol std::__once_callable in AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478 --- Comment #9 from Qingshan Zhang --- Or do we have any work round for this issue ? Thank you.
[Bug tree-optimization/69760] [4.9/5 Regression] Wrong 64-bit memory address caused by an unneeded overflowing 32-bit integer multiplication on x86_64 under -O2 and -O3 code optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69760 --- Comment #15 from Richard Biener --- Author: rguenth Date: Wed Apr 6 08:09:40 2016 New Revision: 234775 URL: https://gcc.gnu.org/viewcvs?rev=234775&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-02-24 Richard Biener Jakub Jelinek PR middle-end/69760 * tree-scalar-evolution.c (interpret_rhs_expr): Re-write conditionally executed ops to well-defined overflow behavior. * gcc.dg/torture/pr69760.c: New testcase. 2016-03-01 Richard Biener PR tree-optimization/69983 * tree-chrec.c (eq_evolutions_p): Handle conversions, compare types and fall back to operand_equal_p. * gcc.dg/graphite/isl-codegen-loop-dumping.c: Adjust. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69760.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c branches/gcc-5-branch/gcc/tree-chrec.c branches/gcc-5-branch/gcc/tree-scalar-evolution.c
[Bug target/67478] gcc-5.1.0/gcc-5.2.0 undefined symbol std::__once_callable in AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478 Qingshan Zhang changed: What|Removed |Added CC||qshanz at cn dot ibm.com --- Comment #8 from Qingshan Zhang --- Hi, would you please share me how to fix this issue ?
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Apr 6 08:09:40 2016 New Revision: 234775 URL: https://gcc.gnu.org/viewcvs?rev=234775&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-02-24 Richard Biener Jakub Jelinek PR middle-end/69760 * tree-scalar-evolution.c (interpret_rhs_expr): Re-write conditionally executed ops to well-defined overflow behavior. * gcc.dg/torture/pr69760.c: New testcase. 2016-03-01 Richard Biener PR tree-optimization/69983 * tree-chrec.c (eq_evolutions_p): Handle conversions, compare types and fall back to operand_equal_p. * gcc.dg/graphite/isl-codegen-loop-dumping.c: Adjust. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69760.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c branches/gcc-5-branch/gcc/tree-chrec.c branches/gcc-5-branch/gcc/tree-scalar-evolution.c
[Bug tree-optimization/68963] [4.9 Regression] O3 vs. O2 discards part of loop and terminates early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68963 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Apr 6 07:57:47 2016 New Revision: 234774 URL: https://gcc.gnu.org/viewcvs?rev=234774&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-02-24 Richard Biener PR middle-end/68963 * tree-ssa-loop-niter.c (derive_constant_upper_bound_ops): Fix bogus check. (record_nonwrapping_iv): Do not fall back to the low/high bound for non-constant IV bases if the stmt is not always executed. * gcc.dg/torture/pr68963.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68963.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/70115] [5 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.4.0 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug middle-end/70022] [4.9/5 Regression] ICE: in tree_to_shwi, at tree.c:7328 with out-of-bounds vector index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70022 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Apr 6 07:51:19 2016 New Revision: 234773 URL: https://gcc.gnu.org/viewcvs?rev=234773&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-03-01 Richard Biener PR middle-end/70022 * fold-const.c (fold_indirect_ref_1): Fix range checking for vector BIT_FIELD_REF extract. * gcc.dg/pr70022.c: New testcase. 2016-03-07 Richard Biener PR tree-optimization/70115 * tree-ssa-loop-ivcanon.c (propagate_into_all_uses): Remove. (propagate_constants_for_unrolling): Use replace_uses_by. * gcc.dg/torture/pr70115.c: New testcase. 2016-03-29 Richard Biener PR middle-end/70424 * ipa-prop.c (ipa_compute_jump_functions_for_edge): Always use alignment returned by get_pointer_alignment_1 if it is bigger than BITS_PER_UNIT. * builtins.c (get_pointer_alignment_1): Do not return true for alignment extracted from SSA info. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr70022.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr70115.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/builtins.c branches/gcc-5-branch/gcc/ipa-prop.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-loop-ivcanon.c
[Bug middle-end/70424] [4.9/5 Regression] Pointer derived from integer gets reduced alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70424 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Apr 6 07:51:19 2016 New Revision: 234773 URL: https://gcc.gnu.org/viewcvs?rev=234773&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-03-01 Richard Biener PR middle-end/70022 * fold-const.c (fold_indirect_ref_1): Fix range checking for vector BIT_FIELD_REF extract. * gcc.dg/pr70022.c: New testcase. 2016-03-07 Richard Biener PR tree-optimization/70115 * tree-ssa-loop-ivcanon.c (propagate_into_all_uses): Remove. (propagate_constants_for_unrolling): Use replace_uses_by. * gcc.dg/torture/pr70115.c: New testcase. 2016-03-29 Richard Biener PR middle-end/70424 * ipa-prop.c (ipa_compute_jump_functions_for_edge): Always use alignment returned by get_pointer_alignment_1 if it is bigger than BITS_PER_UNIT. * builtins.c (get_pointer_alignment_1): Do not return true for alignment extracted from SSA info. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr70022.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr70115.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/builtins.c branches/gcc-5-branch/gcc/ipa-prop.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-loop-ivcanon.c
[Bug tree-optimization/70115] [5 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Apr 6 07:51:19 2016 New Revision: 234773 URL: https://gcc.gnu.org/viewcvs?rev=234773&root=gcc&view=rev Log: 2016-04-06 Richard Biener Backport from mainline 2016-03-01 Richard Biener PR middle-end/70022 * fold-const.c (fold_indirect_ref_1): Fix range checking for vector BIT_FIELD_REF extract. * gcc.dg/pr70022.c: New testcase. 2016-03-07 Richard Biener PR tree-optimization/70115 * tree-ssa-loop-ivcanon.c (propagate_into_all_uses): Remove. (propagate_constants_for_unrolling): Use replace_uses_by. * gcc.dg/torture/pr70115.c: New testcase. 2016-03-29 Richard Biener PR middle-end/70424 * ipa-prop.c (ipa_compute_jump_functions_for_edge): Always use alignment returned by get_pointer_alignment_1 if it is bigger than BITS_PER_UNIT. * builtins.c (get_pointer_alignment_1): Do not return true for alignment extracted from SSA info. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr70022.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr70115.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/builtins.c branches/gcc-5-branch/gcc/ipa-prop.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-loop-ivcanon.c
[Bug c++/70430] Incorrect result for logical "and" operation with mixed vector and scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70430 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.4.0 Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
