[Bug middle-end/61243] New: [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243 Bug ID: 61243 Summary: [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Recent regression in the one day between good: r210596 bad: r210629 Unfortunately, only happens with -fprofile-use on our large application (CP2K). Any suggestion on how to get this into a testcase ? I can provide unreduced .F, .mod and .gcda files. /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_integrate_potential_low.F:526:0: error: No region crossing jump at section boundary in bb 65 END SUBROUTINE xyz_to_vab ^ /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_integrate_potential_low.F:526:0: internal compiler error: verify_flow_info failed 0x6edead verify_flow_info() ../../gcc/gcc/cfghooks.c:260 0xf60a88 try_optimize_cfg ../../gcc/gcc/cfgcleanup.c:2860 0xf60a88 cleanup_cfg(int) ../../gcc/gcc/cfgcleanup.c:3025 0xf5363b execute ../../gcc/gcc/bb-reorder.c:2353 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. make[2]: *** [qs_integrate_potential_low.o] Error 1
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #9 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com --- The following PR has been opened for Thumb1 problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
[Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- The same failure is triggered with profiledbootstrap build. First recorded bootstrap failure is at r210603 [1]. Last good bootstrap is at r210599 [2]. It looks that r210603 is problematic [3]. Author CC'd. [1] https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00224.html [2] https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01581.html [3] https://gcc.gnu.org/ml/gcc-cvs/2014-05/msg00646.html
[Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #9 from Mukund Sivaraman muks at banu dot com --- Hi Jakub, Markus We discussed this during our daily standup call today, and there are two points we'd like to make: 1. The qsort() defintion in C99 doesn't explicitly state that base must not be NULL, though it seems you are deducing that from the initial element of which is pointed to by base. The POSIX definition of qsort() adds this: If the nel argument has the value zero, the comparison function pointed to by compar shall not be called and no rearrangement shall take place. 2. From our perpective as users of GCC, this kind of agressive optimization seems counter-intuitive. We'd like code to compile to correct object code first before performance. When the compiler knows at that point that base (=x) is NULL as an argument to qsort(), why isn't it warning when the attribute expects it to be non-NULL, esp. as it is using this inferred decision to optimize code down below? The compiler knows x is NULL at this point in this codepath regardless of what qsort()'s attributes say. Why is it using the attribute then? qsort() also does not assert (at runtime) that base is non-NULL. There is no way to detect this for code which used to run correctly before, but doesn't anymore (without it _hopefully_ crashing somewhere). Other similar functions such as memcpy(), etc. also have this annotation in glibc, whereas there is no definition of n=0 case in C99. This example of qsort() is in libc, but imagine a case where a program uses a 3rd party system installed utility shared library. If the library, in a new version, adds a nonnull annotation for a function, but the library function itself continues to work for NULL input, see what happens to the program: The library is not affected, but the pointer in the calling program is affected if the compiler infers that the pointer is non-NULL due to the attribute. The calling program is now buggy due to a change in the library. How do we discover it? It makes sense to just avoid the qsort() in our case and we will update our code to do so, but please consider the arguments above.
[Bug go/61244] New: gccgo: ICE in write_specific_type_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61244 Bug ID: 61244 Summary: gccgo: ICE in write_specific_type_functions Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dvyukov at google dot com Created attachment 32824 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32824action=edit reproducer $ gccgo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap --enable-checking=yes --disable-multilib --prefix=gcc_trunk/install Thread model: posix gcc version 4.10.0 20140516 (experimental) (GCC) The reproducer program is attached. $ go build -compiler=gccgo 0.go go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1819 0x628f2a Type::write_specific_type_functions(Gogo*, Named_type*, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, Function_type*, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, Function_type*) ../../gcc/go/gofrontend/types.cc:1819 0x6276bf Type::specific_type_functions(Gogo*, Named_type*, Function_type*, Function_type*, Named_object**, Named_object**) ../../gcc/go/gofrontend/types.cc:1798 0x627c86 Type::type_functions(Gogo*, Named_type*, Function_type*, Function_type*, Named_object**, Named_object**) ../../gcc/go/gofrontend/types.cc:1675 0x630194 Type::type_descriptor_constructor(Gogo*, int, Named_type*, Methods const*, bool) ../../gcc/go/gofrontend/types.cc:2016 0x6321f3 Array_type::array_type_descriptor(Gogo*, Named_type*) ../../gcc/go/gofrontend/types.cc:6121 0x62a5db Type::make_type_descriptor_var(Gogo*) ../../gcc/go/gofrontend/types.cc:1249 0x62a796 Type::type_descriptor_pointer(Gogo*, Location) ../../gcc/go/gofrontend/types.cc:1206 0x5bf412 Type_descriptor_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:13863 0x5bb6eb Call_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:9425 0x5a23f6 Unary_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:4039 0x607491 If_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:3200 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x60741c Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1811 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x60741c Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1811 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x60741c Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1811 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x60741c Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1811 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- If you believe the nonnull attribute on qsort is incorrect, then you should report that as glibc bug, not gcc bug, the prototype is provided by glibc. The more aggressive GCC optimization is documented e.g. in https://gcc.gnu.org/gcc-4.9/porting_to.html plus we hope to add -fsanitize=undefined instrumentation for this in the upcoming GCC version, so you find it out more easily. When the compiler knows at that point that base (=x) is NULL as an argument to qsort(), why isn't it warning when the attribute expects it to be non-NULL, esp. as it is using this inferred decision to optimize code down below? But the compiler doesn't know there that x is NULL. The compiler sees a call to a function which must not be called with NULL, and from that derives the value range of x to be anything but NULL. Instead of qsort consider here some less controversial function, e.g. memcpy, where the standard is very clear that memcpy (NULL, , 0); or memcpy (, NULL, 0); is invalid despite the length 0.
[Bug tree-optimization/61245] New: ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61245
Bug ID: 61245
Summary: ICE at in expand_ANNOTATE, at internal-fn.c:127 called
from cfgexpand.c
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
apologize for not reducing (trivial reduction (bar below) works)
given
cat NaiveDod.cc
#includearray
#includevector
#includeutility
unsigned int N;
float * a, *b, *c;
void bar() {
#pragma GCC ivdep
for (auto i=0U; iN; ++i)
a[i] = b[i]*c[i];
}
templateint N
struct SoA {
using s_t = unsigned int;
using Ind = unsigned int;
auto size() const { return m_n;}
float operator()(Ind i, Ind j) { return data[j][i];}
float const operator()(Ind i, Ind j) const { return data[j][i];}
std::arraystd::vectorfloat,N data;
s_t m_n=0;
};
templateint N
void doT(SoAN soa) {
#pragma GCC ivdep
for (auto i=0U; isoa.size(); ++i)
soa(i,0) = soa(i,1)*soa(i,2);
}
void doIt(SoA3 soa) {
doT(soa);
}
produces
c++ -std=c++1y -Ofast -Wall -fopt-info-vec -fno-tree-slp-vectorize
-march=nehalem -S NaiveDod.cc
NaiveDod.cc:10:17: note: loop vectorized
NaiveDod.cc:10:17: note: loop peeled for vectorization to enhance alignment
NaiveDod.cc: In function 'void doIt(SoA3)':
NaiveDod.cc:34:17: internal compiler error: in expand_ANNOTATE, at
internal-fn.c:127
for (auto i=0U; isoa.size(); ++i)
^
0x9e9a97 expand_ANNOTATE
../../gcc-trunk/gcc/internal-fn.c:127
0x820a7a expand_call_stmt
../../gcc-trunk/gcc/cfgexpand.c:2236
0x820a7a expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3202
0x820a7a expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3354
0x821aee expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5194
0x823746 execute
../../gcc-trunk/gcc/cfgexpand.c:5803
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.
c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w4/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w4 --enable-languages=c,c++,lto,fortran
-enable-gold=yes --enable-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 -enable-libitm -disable-multilib
Thread model: posix
gcc version 4.10.0 20140520 (experimental) [trunk revision 210630] (GCC)
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #3 from zhenqiang.chen at linaro dot org --- I can not reproduce gcc.dg/guality/pr43051-1.c fail with options -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fomit-frame-pointer -funroll-all-loops -m32 -mtune=core2 What are your final options to build the test case?
[Bug go/61246] New: gccgo: ICE in do_determine_types [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246 Bug ID: 61246 Summary: gccgo: ICE in do_determine_types [GoSmith] Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dvyukov at google dot com $ gccgo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap --enable-checking=yes --disable-multilib --prefix=gcc_trunk/install Thread model: posix gcc version 4.10.0 20140516 (experimental) (GCC) The reproducer is attached. $ go build -compiler=gccgo 0.go go1: internal compiler error: in do_determine_types, at go/gofrontend/statements.cc:400 0x6078ed Temporary_statement::do_determine_types() ../../gcc/go/gofrontend/statements.cc:400 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x6073fa If_statement::do_determine_types() ../../gcc/go/gofrontend/statements.cc:3166 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x6073fa If_statement::do_determine_types() ../../gcc/go/gofrontend/statements.cc:3166 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x6073fa If_statement::do_determine_types() ../../gcc/go/gofrontend/statements.cc:3166 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d2d4b Block::determine_types() ../../gcc/go/gofrontend/gogo.cc:5410 0x5d5ad8 Function::determine_types() ../../gcc/go/gofrontend/gogo.cc:4562 0x5d5ad8 Gogo::determine_types() ../../gcc/go/gofrontend/gogo.cc:2755 0x5cea3c go_parse_input_files(char const**, unsigned int, bool, bool) ../../gcc/go/gofrontend/go.cc:107
[Bug go/61246] gccgo: ICE in do_determine_types [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246 --- Comment #1 from Dmitry Vyukov dvyukov at google dot com --- Created attachment 32825 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32825action=edit reproducer
[Bug tree-optimization/61247] New: vectorization fails if conversion from unsigned int to signed int is involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247
Bug ID: 61247
Summary: vectorization fails if conversion from unsigned int to
signed int is involved
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following example
cat uintLoop.cc
unsigned int N;
float * a, *b, *c;
using Ind = /*unsigned*/ int;
inline
float val(float * x, Ind i) { return x[i];}
inline
float const val(float const * x, Ind i) { return x[i];}
void foo() {
#pragma GCC ivdep
for (auto i=0U; iN; ++i)
val(a,i) = val(b,i)*val(c,i);
}
using Ind = /*unsigned*/ int;
does not vectorize with
c++ -std=c++1y -Ofast -Wall -fopt-info-vec-missed -fno-tree-slp-vectorize
-march=nehalem -S uintLoop.cc
uintLoop.cc:12:17: note: not vectorized: not suitable for gather load _8 =
*_17;
uintLoop.cc:12:17: note: bad data references.
using Ind = unsigned int;
vectorize fine
minor, just annoying
[Bug tree-optimization/61247] vectorization fails if conversion from unsigned int to signed int is involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||LP64 Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is a LP64 issue. In that on x32 or x86 (or ILP32 with AARCH64), we can vectorize this.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) If you believe the nonnull attribute on qsort is incorrect, then you should report that as glibc bug, not gcc bug, the prototype is provided by glibc. The more aggressive GCC optimization is documented e.g. in https://gcc.gnu.org/gcc-4.9/porting_to.html plus we hope to add -fsanitize=undefined instrumentation for this in the upcoming GCC version, so you find it out more easily. It is not incorrect as the C standard says this about qsort: nmemb can have the value zero on a call to that function; the comparison function is not called, a search finds no matching element, and sorting performs no rearrangement. Pointer arguments on such a call shall still have valid values, as described in 7.1.4. POSIX 2008 defers to the C standard now so this is neither a glibc or a GCC bug in the end.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #11) It is not incorrect as the C standard says this about qsort: nmemb can have the value zero on a call to that function; the comparison function is not called, a search finds no matching element, and sorting performs no rearrangement. Pointer arguments on such a call shall still have valid values, as described in 7.1.4. 7.1.4 says this: Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined. So there is not need to say it was detected to be non-null as the null pointer case is mentioned in 7.1.4.
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #19 from Rich Felker bugdal at aerifal dot cx --- Here is the commit that seems to have introduced the bug: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=df8d3e8981a99e264b49876f0f5064bdb30ac981 In the function ctor_for_folding, the following erroneous logic appears: + /* Non-readonly alias of readonly variable is also de-facto readonly, + because the variable itself is in readonly section. + We also honnor READONLY flag on alias assuming that user knows + what he is doing. */ + if (!TREE_READONLY (decl) !TREE_READONLY (real_decl)) +return error_mark_node; This treats the value of an alias as a compile-time constant if either the alias itself or the alias target has TREE_READONLY being true. Replacing the with || seems to make the problem go away in my test case, and makes a bit more sense (perhaps that was the original intent?), but it's only sufficient if TREE_READONLY is always false for weak aliases (since they can always be overridden by a strong symbol from another translation unit, even if the alias is const-qualified). I'm not sure where the value of TREE_READONLY is set for aliases yet but I'll keep looking...
[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61221 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 20 08:16:13 2014 New Revision: 210633 URL: http://gcc.gnu.org/viewcvs?rev=210633root=gccview=rev Log: 2014-05-20 Richard Biener rguent...@suse.de PR tree-optimization/61221 * tree-ssa-pre.c (el_to_update): Remove. (eliminate_dom_walker::before_dom_children): Handle released VDEFs by value-numbering them to the associated VUSE. Update stmt immediately for substituted call address. (eliminate): Remove delayed stmt updating code. * tree-ssa-sccvn.c (vuse_ssa_val): New function valueizing possibly late re-numbered vuses. (vn_reference_lookup_2): Adjust. (vn_reference_lookup_pieces): Likewise. (vn_reference_lookup): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c
[Bug middle-end/61245] ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61245
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-20
CC||burnus at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Component|tree-optimization |middle-end
Ever confirmed|0 |1
Known to fail||4.10.0, 4.9.0
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed. An ANNOTATE survives CFG building:
;; 2 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5
;;
;; Loop 1
;; header 4, latch 3
;; depth 1, outer 0
;; nodes: 4 3
void doT(SoAN) [with int N = 3] (struct SoA soa)
{
...
bb 3:
D.30093 = SoA3::operator() (soa, i, 0);
D.30094 = SoA3::operator() (soa, i, 1);
D.30095 = *D.30094;
D.30096 = SoA3::operator() (soa, i, 2);
D.30097 = *D.30096;
D.30098 = D.30095 * D.30097;
*D.30093 = D.30098;
i = i + 1;
bb 4:
D.30101 = SoA3::size (soa);
D.30102 = D.30101 i;
D.30100 = ANNOTATE (D.30102, 0);
retval.4 = D.30100;
if (retval.4 != 0)
goto bb 3;
else
goto bb 5;
bb 5:
[Bug go/61248] New: gccgo: spurious error: too many arguments [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61248
Bug ID: 61248
Summary: gccgo: spurious error: too many arguments [GoSmith]
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
Program:
package main
func main() {
var f func(int, interface{})
go f(0, recover())
}
$ go build -compiler=gccgo args.go
args.go:5:10: error: too many arguments
go f(0, recover())
[Bug c++/61245] ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61245 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |c++ --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- For some reason we create a temporary, probably because the very specific ANNOTATE is inside a cleanup_point: if (cleanup_point ANNOTATE_EXPR SoA3::size ((struct SoA *) soa) i, ivdep) goto D.28269; else goto D.28267; that is, the wrapped expressions has side-effects. We should build the ANNOTATE_EXPR outside of that cleanup. C++ FE support issue.
[Bug c++/61242] [4.9/4.10 Regression] Bogus no matching function for call to ‘Foo::Create(brace-enclosed initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #20 from Rich Felker bugdal at aerifal dot cx --- On further investigation, it looks like the code I cited deals with strong aliases as well as weak ones, and in the strong alias case, the strong folding behavior might be desirable. A better fix seems to be adding an explicit check for weak aliases (DECL_WEAK(decl)) when an alias is found and returning error_mark_node in that case. Note that prior to the above-mentioned commit, the !TREE_READONLY(decl) case was always treated as non-foldable, so there seems to have been no subtlety to avoiding errors with weak aliases. But the new code performs much more aggressive constant folding and thus needs to avoid stepping on weak aliases.
[Bug rtl-optimization/61241] built-in memset makes the caller function slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Can you please send the patch to gcc-patc...@gcc.gnu.org including a ChangeLog
[Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Target Milestone|--- |4.8.3 Summary|Incorrect warning integer |[4.8/4.9/4.10 Regression] |overflow in expression on |Incorrect warning integer |pointer-pointer subtraction |overflow in expression on ||pointer-pointer subtraction Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- We warn for integer_cst 0x76d54e28 type integer_type 0x76c407e0 long int constant public overflow 1 via c-common.c:overflow_warning called from #1 0x0065b80e in parser_build_binary_op (location=5653, code=MINUS_EXPR, arg1=..., arg2=...) at /space/rguenther/src/svn/trunk/gcc/c/c-typeck.c:3411 #2 0x0068f5ed in c_parser_binary_expression (parser=0x76d67000, after=0x0, omp_atomic_lhs=tree 0x0) at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:6282 #3 0x0068dfee in c_parser_conditional_expression ( parser=0x76d67000, after=0x0, omp_atomic_lhs=tree 0x0) at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:5934 #4 0x0068dd75 in c_parser_expr_no_commas (parser=0x76d67000, after=0x0, omp_atomic_lhs=tree 0x0) at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:5852 when building p - (p + -1U) which gets simplified to - -1U - 1U (with overflow set - as it's sizetype arithmetic). pointer_diff is guilty here which calls /* First do the subtraction as integers; then drop through to build the divide operator. Do not do default conversions on the minus operator in case restype is a short type. */ op0 = build_binary_op (loc, MINUS_EXPR, convert (inttype, op0), convert (inttype, op1), 0); doing 0 - -1U, converting them to inttype (long int) first. I suggest to do that conversion and strip overflow bits in the POINTER_PLUS_EXPR decomposition part.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue May 20 08:37:50 2014 New Revision: 210635 URL: http://gcc.gnu.org/viewcvs?rev=210635root=gccview=rev Log: gcc/ 2014-05-20 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com Backport from mainline r210325 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * config/avr/avr.c (avr_out_store_psi): Use correct constant to restore Y. gcc/testsuite/ 2014-05-20 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com Backport from mainline r210325 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * gcc.target/avr/pr60991.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/avr/pr60991.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61239] [4.10 Regression]: ICE in decompose, at rtl.h when compiling vshuf-v16hi.c using -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61239 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug debug/61237] gcc puts line number 11 ahead of line number 10 in function call in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61237 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, '-foo (2, 3)' _has_ to be executed before the call to foo. line-numbers are a bad representation for C sequence point rules. I would say this is not a bug.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Known to work||4.7.4, 4.8.3, 4.9.1 Keywords||wrong-code Resolution|--- |FIXED Target Milestone|--- |4.9.1 Known to fail|4.7.2, 4.8.1|4.7.3, 4.8.2, 4.9.0 Severity|critical|normal --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 4.7.4, 4.8.3, 4.9.1
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #11) It is not incorrect as the C standard says this about qsort: nmemb can have the value zero on a call to that function; the comparison function is not called, a search finds no matching element, and sorting performs no rearrangement. Pointer arguments on such a call shall still have valid values, as described in 7.1.4. POSIX 2008 defers to the C standard now so this is neither a glibc or a GCC bug in the end. I've missed the Pointer arguments on such a call shall still have valid values, as described in 7.1.4. sentence in C99 7.20.5 (was looking for that in 7.20.5.2), with that it is exactly the same thing in this regard as memcpy etc.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #14 from Mukund Sivaraman muks at banu dot com --- (In reply to Jakub Jelinek from comment #10) But the compiler doesn't know there that x is NULL. The compiler sees a See comment #3. It generates 2 codepaths, one where (nalloc == 0) and another where (nalloc != 0). For the former, it deletes the if statement and isc_mem_put() call at the free_rdatas label completely: free_rdatas: if (x != NULL) isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata)); return (result); } and instead reduces free_rdata's definition to: free_rdatas: return (result); } How does the compiler do that if it has not inferred that x is NULL there? OTOH, you're the compiler developers, so if you say it doesn't know that x is NULL, then that is that. :) Maybe the part of compiler code that does this doesn't know it. Note that despite all this discussion of correctness, this optimization is counter intuitive and will bite developers. There should at least be warnings where they could be generated. The point about correctness with C standards is taken and agreed. See what is happening from a programmer's point of view: an explicit NULL check is deleted. There are no warnings about qsort() used with NULL arguments where it seems the compiler could warn (see above). Also consider the use of notnull as an API annotation change by 3rd party libraries, which can make caller code buggy without any way to notice it. At the very least, if it is possible to detect that the pointer is NULL by static analysis and it is being passed to a function that has the notnull attribute, please warn mentioning inferences being made.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #15 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Mukund Sivaraman from comment #14) (In reply to Jakub Jelinek from comment #10) But the compiler doesn't know there that x is NULL. The compiler sees a See comment #3. It generates 2 codepaths, one where (nalloc == 0) and another where (nalloc != 0). For the former, it deletes the if statement and isc_mem_put() call at the free_rdatas label completely: free_rdatas: if (x != NULL) isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata)); return (result); } and instead reduces free_rdata's definition to: free_rdatas: return (result); } How does the compiler do that if it has not inferred that x is NULL there? OTOH, you're the compiler developers, so if you say it doesn't know that x is NULL, then that is that. :) Maybe the part of compiler code that does this doesn't know it. Note that despite all this discussion of correctness, this optimization is counter intuitive and will bite developers. There should at least be warnings where they could be generated. The point about correctness with C standards is taken and agreed. See what is happening from a programmer's point of view: an explicit NULL check is deleted. There are no warnings about qsort() used with NULL arguments where it seems the compiler could warn (see above). Also consider the use of notnull as an API annotation change by 3rd party libraries, which can make caller code buggy without any way to notice it. At the very least, if it is possible to detect that the pointer is NULL by static analysis and it is being passed to a function that has the notnull attribute, please warn mentioning inferences being made. The warning did not make it into gcc 4.9 due to the patches to do the warning were not ready. Gcc 4.10 should warn about it. If it does not then that is a bug.
[Bug target/61249] New: _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 Bug ID: 61249 Summary: _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mt at debian dot org Looking at https://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html on the one hand and AMD's AMD64 Architecture Programmer’s Manual Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions on the other hand, vfrczss/vfrczsd require a second argument to specify the destination. Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument is passed to the __builtin_ia32_vfrczss/vfrczsd calls. This was detected at language level (inconsistent types), I can only speculate that this may cause invalid code to be generated (or null operands). Best, Michael PS.: The problem persists in the 4.9 branch as xopintrin.h hasn't been touched since 4.8.
[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Adding -Wall to the dg-options let the test succeed (in line with the gfortran
manual, see comment 21):
--- ../_clean/gcc/testsuite/gfortran.dg/wextra_1.f2012-10-21
13:06:18.0 +0200
+++ gcc/testsuite/gfortran.dg/wextra_1.f2014-05-15 12:05:56.0 +0200
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options -Wextra }
+! { dg-options -Wall -Wextra }
program main
integer, parameter :: x=3 ! { dg-warning Unused parameter }
real :: a
Indeed the questions asked in comment 22 should be answered.
[Bug c/61236] GCC 4.9 generates incorrect object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 --- Comment #16 from Mukund Sivaraman muks at banu dot com --- (In reply to Andrew Pinski from comment #15) At the very least, if it is possible to detect that the pointer is NULL by static analysis and it is being passed to a function that has the notnull attribute, please warn mentioning inferences being made. The warning did not make it into gcc 4.9 due to the patches to do the warning were not ready. Gcc 4.10 should warn about it. If it does not then that is a bug. Thank you for this. :) It should detect at least some cases in that case. If qsort() can cause this sort of disruption to a caller if NULL is passed, I guess a change in glibc to add an assert(base != NULL) or similar abort is also in order given that the caller code becomes buggy otherwise. Do you agree? This would catch remaining cases before any inferred decisions are executed after the qsort().
[Bug pch/61250] New: Random pch failures on x86_64-apple-darwin13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Bug ID: 61250 Summary: Random pch failures on x86_64-apple-darwin13. Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 When running the test suite on x86_64-apple-darwin13 with -j8 (4 cores, 8 threads), I see random failures for the tests g++.dg/pch/pch.C gcc.dg/pch/save-temps-1.c They are either an ICE: Internal compiler error: Error reporting routines re-entered. (may be related to pr59877), or a program timed out leading to an assembly comparison: WARNING: program timed out. FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -g assembly comparison AFAICT these failures occur for any set of options or -m32/-m64. The number of failures ranges from 0 to 4/5 and seems (weakly) correlated to the machine load (-j8+backup).
[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Michael Tautschnig from comment #0) Looking at https://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html on the one hand and AMD's AMD64 Architecture Programmer’s Manual Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions on the other hand, vfrczss/vfrczsd require a second argument to specify the destination. Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument is passed to the __builtin_ia32_vfrczss/vfrczsd calls. You should not use __builtin_* function directly. They are internal implementation details, published interface is in relevant *.h files. This was detected at language level (inconsistent types), I can only speculate that this may cause invalid code to be generated (or null operands). Did you see the runtime tests in the referred commit?
[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #23) Adding -Wall to the dg-options let the test succeed (in line with the gfortran manual, see comment 21): This is enough to make the test pass, but it is not enough to get the correct behavior and it will get broken by other reason. The patch in comment #10 is needed independently of what gfortran chooses.
[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 --- Comment #2 from Michael Tautschnig mt at debian dot org --- Thanks a lot for your quick reply. Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument is passed to the __builtin_ia32_vfrczss/vfrczsd calls. You should not use __builtin_* function directly. They are internal implementation details, published interface is in relevant *.h files. Yes, sure. It would still be nice if they were well typed. This was detected at language level (inconsistent types), I can only speculate that this may cause invalid code to be generated (or null operands). Did you see the runtime tests in the referred commit? Just re-ran those tests and looking at the generated assembly (should have done that before, my apologies) it seems that two operands are generated: vfrczsd %xmm1, %xmm0 and vfrczss %xmm1, %xmm1 So shall I read this as an imprecision in documentation? Best, Michael
[Bug target/61195] single precision fmov does not need to switch mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61195 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from chrbr at gcc dot gnu.org --- in 4.10
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- is test/compile sufficient, or do you have to run it?
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #4 from Frank Ch. Eigler fche at redhat dot com --- is test/compile sufficient, or do you have to run it? Just compile.
[Bug fortran/61251] New: Hang in write from inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61251 Bug ID: 61251 Summary: Hang in write from inside a function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: peter.machon at arcor dot de Writing from a functions stops execution of programs. ** Simple code: program test write(*,*) f(3e0) contains function f(x) real :: f,x write(*,*)x f=2e0*x end function end program * The write function inside the function f(x) causes the hang. Sorry if it is supposed to be like this. But with e.g. the PGI compiler it works fine. I'm working with MacOSX 10.6.8 and a self-build gcc, downloaded from the gnu page. gfortran -v : Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/pm/bin/gcc_4.8.2/libexec/gcc/x86_64-apple-darwin10.8.0/4.8.2/lto-wrapper Target: x86_64-apple-darwin10.8.0 Configured with: ./configure --prefix=/Users/pm/bin/gcc_4.8.2/ Thread model: posix gcc version 4.8.2 (GCC)
[Bug c++/61252] New: Invalid code produced for omp simd reduction(min:var) where var is reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61252
Bug ID: 61252
Summary: Invalid code produced for omp simd reduction(min:var)
where var is reference
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hazeman11 at gmail dot com
Created attachment 32826
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32826action=edit
minimal code with reduce_bad
Invalid code produced ( loop optimized out ) for case when reduction variable
is a reference. I've looked into OpenMP specification but didn't find
requirement for reduction variable to be local ( althought I didn't spend much
time on it :) ).
System: ubuntu 12.04 64bit
GCC -v
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-checking=release
--enable-languages=c,c++ --enable-multiarch --disable-multilib --enable-shared
--enable-threads=posix --with-abi=m64 --program-suffix=-4.9 --with-gmp=/usr/lib
--with-mpc=/usr/lib --with-mpfr=/usr/lib --without-included-gettext
--with-system-zlib --with-tune=generic --prefix=/usr/local
Thread model: posix
gcc version 4.9.1 20140514 (prerelease) (GCC)
Compilation options:
g++ -fopenmp -O3 -g3 -ffast-math -Wall -ftree-vectorize -march=core-avx2 -c
test.cpp -o test.o
-- code --
void reduce_bad( int N, float* a0, float* a1, float maxstep )
{
#pragma omp simd reduction(min:maxstep)
for(int i=0;iN;i++) {
maxstep = std::min(a0[i],a1[i]);
}
}
---
and here is workaround for this bug
-- code --
void reduce_good( int N, float* a0, float* a1, float ret )
{
float maxstep = ret;
#pragma omp simd reduction(min:maxstep)
for(int i=0;iN;i++) {
maxstep = std::min(a0[i],a1[i]);
}
ret = maxstep;
}
--
[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61252 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I see a problem in the OpenMP lowering, that said, I hope you know that your testcase doesn't compute the minimum from all iterations, but just the last few ones (without -fopenmp just the last one, with -fopenmp from one to vectorization factor of the loop). So the value you get doesn't make any sense.
[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61252 --- Comment #2 from hazeman11 at gmail dot com --- Yep sorry for so stupid example. I've reduced it to bare minimum without looking whether it does make sense. Ofcourse something like maxstep = std::min(std::min(a0[i],a1[i]),maxstep); would make much more sense. Inside of my original loop ( where i've spotted the problem ) was much much larger.
[Bug go/61253] New: gccgo: spurious error: expected '-' or '=' [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61253
Bug ID: 61253
Summary: gccgo: spurious error: expected '-' or '='
[GoSmith]
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
c := make(chan int)
v := new(int)
b := new(bool)
select {
case (*v), (*b) = -c:
}
}
$ go build -compiler=gccgo /tmp/switch.go
src.go:8:11: error: expected '-' or '='
case (*v), (*b) = -c:
[Bug target/61223] [gcc-4.10 regression] libstdc++ build fail due to pop lr register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Summary|libstdc++ build fail due to |[gcc-4.10 regression] |pop lr register |libstdc++ build fail due to ||pop lr register Ever confirmed|0 |1
[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61252 --- Comment #3 from hazeman11 at gmail dot com --- Created attachment 32827 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32827action=edit corrected minimal example
[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58664 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 20 13:30:40 2014 New Revision: 210642 URL: http://gcc.gnu.org/viewcvs?rev=210642root=gccview=rev Log: /cp 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58664 * typeck2.c (cxx_incomplete_type_inform): New. (cxx_incomplete_type_diagnostic): Use it. * decl.c (grokdeclarator): Check the element type of an incomplete array type; call the above. * cp-tree.h (cxx_incomplete_type_inform): Declare. /testsuite 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58664 * g++.dg/cpp0x/nsdmi-union6.C: New. * g++.dg/parse/pr58664.C: Likewise. * g++.dg/cpp0x/nsdmi6.C: Tweak. * g++.dg/parse/crash31.C: Likewise. * g++.dg/template/error2.C: Likewise. * g++.dg/template/inherit8.C: Likewise. * g++.dg/template/offsetof2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-union6.C trunk/gcc/testsuite/g++.dg/parse/pr58664.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi6.C trunk/gcc/testsuite/g++.dg/parse/crash31.C trunk/gcc/testsuite/g++.dg/template/error2.C trunk/gcc/testsuite/g++.dg/template/inherit8.C trunk/gcc/testsuite/g++.dg/template/offsetof2.C
[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58664 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug go/61254] New: gccgo: spurious error: slice end must be integer [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61254
Bug ID: 61254
Summary: gccgo: spurious error: slice end must be integer
[GoSmith]
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
((([][]int{})[:])[0])[0]++
}
$ go build -compiler=gccgo /tmp/index.go
src.go:4:15: error: slice end must be integer
((([][]int{})[:])[0])[0]++
gc compiles successfully.
[Bug go/61255] New: gccgo: spurious error: argument 2 has incompatible type [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61255
Bug ID: 61255
Summary: gccgo: spurious error: argument 2 has incompatible
type [GoSmith]
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
append([]byte{}, 0)[0]++
}
$ go build -compiler=gccgo src.go
src.go:4:2: error: argument 2 has incompatible type
append([]byte{}, 0)[0]++
gc compiles successfully.
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||peter.machon at arcor dot de --- Comment #37 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 61251 has been marked as a duplicate of this bug. ***
[Bug fortran/61251] Hang in write from inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61251 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The code is invalid: recursive I/O, see pr30617 for discussion (hanging is darwin specific). *** This bug has been marked as a duplicate of bug 30617 ***
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine. Related to c++/58753 and c++/58930.
[Bug rtl-optimization/61241] built-in memset makes the caller function slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61241 --- Comment #4 from ma.jiang at zte dot com.cn --- (In reply to ktkachov from comment #3) Can you please send the patch to gcc-patc...@gcc.gnu.org including a ChangeLog Done! Thanks.
[Bug bootstrap/61210] [4.10 regression] bootstrap failure with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210 --- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue May 20 14:18:44 2014 New Revision: 210645 URL: http://gcc.gnu.org/viewcvs?rev=210645root=gccview=rev Log: gcc/cp/ PR bootstrap/61210 * pt.c (tsubst_copy, tsubst_omp_for_iterator, tsubst_expr) (tsubst_copy_and_build): Perform recursive substitutions in a deterministic order. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I can not reproduce gcc.dg/guality/pr43051-1.c fail with options ... The patch at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01579.html fixes the issues I saw on x86_64-apple-darwin13 (not an approval). I don't see the other issues at https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00155.html in particular the guality test (not run on darwin): CCing H.J. Lu. Personal opinion: the guality tests are just a mess that should be fixed or removed.
[Bug lto/61256] New: [4.10 regression] Building spec2000/252.eon with LTO got a compfail after r210522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61256 Bug ID: 61256 Summary: [4.10 regression] Building spec2000/252.eon with LTO got a compfail after r210522 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Linking on x86 as follows g++ -m64 -Ofast -flto -funroll-loops -m64 -Ofast -flto -funroll-loops -DSPEC_CPU2000_LP64 ... gives lto1: internal compiler error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:3276 0x730833 gimple_get_virt_method_for_vtable(long, tree_node*, unsigned long, bool*) ../../gcc/gimple-fold.c:3276 0x730a23 gimple_get_virt_method_for_binfo(long, tree_node*, bool*) ../../gcc/gimple-fold.c:3377 0x77a133 record_target_from_binfo ../../gcc/ipa-devirt.c:867 0x77a30f record_target_from_binfo ../../gcc/ipa-devirt.c:884 0x77a9bb possible_polymorphic_call_targets_1 ../../gcc/ipa-devirt.c:931 0x77e609 possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**, int*) ../../gcc/ipa-devirt.c:1743 0x7a46f9 possible_polymorphic_call_targets ../../gcc/ipa-utils.h:121 0x7a46f9 walk_polymorphic_call_targets ../../gcc/ipa.c:177 0x7a46f9 symtab_remove_unreachable_nodes(bool, _IO_FILE*) ../../gcc/ipa.c:407 0x858ec7 execute_todo ../../gcc/passes.c:1843 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. lto-wrapper: g++ returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status specmake: *** [eon] Error 1 Also 471.omnetpp from spec2006 fails with the same error
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557 --- Comment #10 from Chung-Lin Tang cltang at gcc dot gnu.org --- The ICE still happens under -mno-lra (and using reload).
[Bug other/61257] New: configure should check if sys/sdt.h is usable, not just checking the existance of the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257
Bug ID: 61257
Summary: configure should check if sys/sdt.h is usable, not
just checking the existance of the header
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
splitting out to a new issue, this started in PR61231, and it came up before in
https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01122.html
(Note that strictly speaking, systemtap per se doesn't need to support
an architecture for the sys/sdt.h header file to work there. gdb is
a fully independent client of sys/sdt.h markers.)
Perhaps the way to go forward is to have the gcc configury test-compile
some toy sys/sdt.h code [1], and activate the probes only if that works.
[1]
#include sys/sdt.h
int main ()
{
DTRACE_PROBE(foo,bar);
return 0;
}
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #5 from Matthias Klose doko at gcc dot gnu.org --- I was wrong about blaming the sys/sdt.h, header, and filed PR61257 for that. Now I tracked down (with enough coffee I hope) r210519 as the patch introducing the bootstrap failure. Reverting it lets the bootstrap succeed on powerpc64le-linux-gnu. The build is configured with: --enable-secureplt --with-cpu=power7 --with-tune=power8 --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
[Bug c++/60373] half warning: visibility attribute ignored because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60373 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 20 15:16:48 2014 New Revision: 210646 URL: http://gcc.gnu.org/viewcvs?rev=210646root=gccview=rev Log: /cp 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/60373 * decl.c (duplicate_decls): Replace pair of warning_at with warning_at + inform. (maybe_commonize_var): Likewise. /testsuite 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/60373 * g++.dg/cpp0x/Wattributes1.C: New. * g++.dg/ext/visibility/redecl1.C: Adjust. * g++.dg/ext/visibility/visibility-7.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wattributes1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/visibility/redecl1.C trunk/gcc/testsuite/g++.dg/ext/visibility/visibility-7.C
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #26 from Matthias Klose doko at gcc dot gnu.org --- this fix causes PR61231 (bootstrap failure on powerpc64le-linux-gnu).
[Bug c++/60373] half warning: visibility attribute ignored because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60373 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #6 from Peter Bergner bergner at gcc dot gnu.org --- Created attachment 32828 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32828action=edit Test case that errors out with invalid assembly on big-endian [bergner@makalu-lp1 BUGS]$ /home/bergner/gcc/build/gcc-fsf-mainline-r210518/gcc/xg++ -B/home/bergner/gcc/build/gcc-fsf-mainline-r210518/gcc/ -c -O2 -m64 pr61231.ii [bergner@makalu-lp1 BUGS]$ /home/bergner/gcc/build/gcc-fsf-mainline-r210520/gcc/xg++ -B/home/bergner/gcc/build/gcc-fsf-mainline-r210520/gcc -c -O2 -m64 pr61231.ii /tmp/ccNkPBLm.s: Assembler messages: /tmp/ccNkPBLm.s:65: Error: operand out of domain (2 is not a multiple of 4) The problematic assembly is: lwa 3,2(31) The problem is that the offset for the lwa instruction needs to be a multiple of 4. I'm not exactly sure that Vlad's patch is at fault here. It could be that it's just exposing a latent bug?
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org --- I meant to add that the issue I'm seeing on BE is due to the same patch that Matthias is having a problem with, namely 210520 (trunk) 210519 (4.9).
[Bug c++/43113] too long diagnostics in some cases of recursive template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||paolo.carlini at oracle dot com Depends on||16564 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I don't want to mark it as a duplicate because PR16564 is a bit more complex. I think this one should be easier to fix. We could always print: pr43113.C:7:11: error: template instantiation depth exceeds maximum of 10 (use -ftemplate-depth= to increase the maximum) instantiating ‘struct A[...]AB::S[...]::S’ pr43113.C:7:11: recursively instantiated from ‘AAB::S’ pr43113.C:7:11: instantiated from ‘AB’ pr43113.C:10:20: instantiated from here pr43113.C:7:11: error: ‘AS::ht’ has incomplete type
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #8 from Matthias Klose doko at gcc dot gnu.org --- on powerpc64le, the test passes with both the stage2 and stage3 compilers of the problematic build.
[Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Hmm, looks like we have two groups of routines for copying insns and I missed one of them. Testing a patch.
[Bug ada/61201] Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The build of GNAT cross is designed to rely on a matching native, to simplify the set up, so this is really as designed here, and not just a 'search path problem'. More specifically, the gnattools must be compiled by the same version of the compiler; for native, this doesn't depend on the base compiler, since the compiler is bootstrapped but, for cross, the base compiler must be the same version.
[Bug target/61223] [gcc-4.10 regression] libstdc++ build fail due to pop lr register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223 --- Comment #2 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Tue May 20 17:25:26 2014 New Revision: 210650 URL: http://gcc.gnu.org/viewcvs?rev=210650root=gccview=rev Log: 2014-05-20 Alexey Merzlyakov alexey.merzlya...@samsung.com PR libstdc++/61223 Revert: 2014-05-16 Alexey Merzlyakov alexey.merzlya...@samsung.com PR libstdc++/60758 * libsupc++/eh_arm.cc (__cxa_end_cleanup): Change r4 to lr in save/restore and add unwind directives. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_arm.cc
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Even with the patch, I still get (using -m32 on x86_64-pc-linux-gnu) FAIL: gcc.target/i386/pr49095.c scan-assembler-not test[lq]
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #10 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Tue May 20 17:25:26 2014 New Revision: 210650 URL: http://gcc.gnu.org/viewcvs?rev=210650root=gccview=rev Log: 2014-05-20 Alexey Merzlyakov alexey.merzlya...@samsung.com PR libstdc++/61223 Revert: 2014-05-16 Alexey Merzlyakov alexey.merzlya...@samsung.com PR libstdc++/60758 * libsupc++/eh_arm.cc (__cxa_end_cleanup): Change r4 to lr in save/restore and add unwind directives. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_arm.cc
[Bug ada/61201] Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org --- Ah, now that's a good answer. Thanks, Eric.
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Even with the patch, I still get (using -m32 on x86_64-pc-linux-gnu) FAIL: gcc.target/i386/pr49095.c scan-assembler-not test[lq] Confirmed, I have overlooked this failure.
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- This pr is fixed on all open branches, but 4.8. So NEW seems the right status.
[Bug fortran/61234] Warn for use-stmt without explicit only-list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- It would be nice to have a warning (-Wuse-only) for a use-stmt without explicit only-list. It would allow for enforcing this good style with -Werror. Extra useful would be if the warning message would list everything that would be required on the only-list. IMO such a warning will generate zillions of useless diagnostics, especially on codes factored such that most of, if not all, the public objects are supposed to be used.
[Bug middle-end/61252] Invalid code produced for omp simd reduction(min:var) where var is reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61252 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-20 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32829 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32829action=edit gcc49-pr61252.patch Untested fix.
[Bug go/61258] New: gccgo: assertion failure go-map-delete.c:37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61258
Bug ID: 61258
Summary: gccgo: assertion failure go-map-delete.c:37
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
delete(make(map[[0]bool]int), [0]bool{})
}
$ go run -compiler=gccgo crash.go
../../../libgo/runtime/go-map-delete.c:37: libgo assertion failure
Aborted
runtime_sighandler
../../../libgo/runtime/go-signal.c:221
sig_tramp_info
../../../libgo/runtime/go-signal.c:412
__go_assert_fail
../../../libgo/runtime/go-assert.c:18
__go_map_delete
../../../libgo/runtime/go-map-delete.c:37
main.main
/tmp/crash.go:3
runtime_main
../../../libgo/runtime/proc.c:562
[Bug fortran/61234] Warn for use-stmt without explicit only-list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Dominique d'Humieres from comment #1) IMO such a warning will generate zillions of useless diagnostics, especially on codes factored such that most of, if not all, the public objects are supposed to be used. of course, such a code doesn't need to enable the warning. Our code base has the rule that use statements must list explicitly what symbols are imported, I believe this is very useful (for example, it documents from where a symbol is actually coming). Such a warning (together with -Werror), would make it easier to automatically enforce that rule.
[Bug c++/61259] New: Spurious ISO C++ forbids zero-size array warning with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259
Bug ID: 61259
Summary: Spurious ISO C++ forbids zero-size array warning
with -pedantic
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at qult dot net
The following code, when compiled with -pedantic, compiles properly but
produces a warning about zero-sized array 'argv'.
#include iostream
struct Foo {
Foo(const char* s) : p(s) {}
const char*p;
};
int main(int, char* argv[])
{
const char*s(Foo(argv[0]).p);
std::cout s std::endl;
return 0;
}
I understand that const char* s(Foo(argv[0])) is to be understood as being a
declaration of function s taking an array of 0 Foo and returning a const char*,
but with the '.p', apparently the compiler resolves the ambiguity by itself and
the code does build an instance of Foo with argv[0] as an argument.
So in any case, something's wrong: either this code should not compile or it
should not issue the warning.
[Bug c++/61259] Spurious ISO C++ forbids zero-size array warning with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-20 Known to work||4.3.6 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The warning has been given since GCC 4.4 (but not earlier)
[Bug target/61208] armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Patch pending review: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01638.html
[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753 --- Comment #14 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 20 19:20:59 2014 New Revision: 210653 URL: http://gcc.gnu.org/viewcvs?rev=210653root=gccview=rev Log: /cp 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * typeck2.c (digest_nsdmi_init): New. * parser.c (cp_parser_late_parse_one_default_arg): Use it. * init.c (get_nsdmi): Likewise. * cp-tree.h (digest_nsdmi_init): Declare. /testsuite 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * g++.dg/cpp0x/nsdmi-template11.C: New. * g++.dg/cpp0x/nsdmi-template12.C: Likewise. * g++.dg/cpp0x/nsdmi-template13.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template12.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/parser.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58930] [C++11] Bogus error: converting to ... from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 20 19:20:59 2014 New Revision: 210653 URL: http://gcc.gnu.org/viewcvs?rev=210653root=gccview=rev Log: /cp 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * typeck2.c (digest_nsdmi_init): New. * parser.c (cp_parser_late_parse_one_default_arg): Use it. * init.c (get_nsdmi): Likewise. * cp-tree.h (digest_nsdmi_init): Declare. /testsuite 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * g++.dg/cpp0x/nsdmi-template11.C: New. * g++.dg/cpp0x/nsdmi-template12.C: Likewise. * g++.dg/cpp0x/nsdmi-template13.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template12.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/parser.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 20 19:20:59 2014 New Revision: 210653 URL: http://gcc.gnu.org/viewcvs?rev=210653root=gccview=rev Log: /cp 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * typeck2.c (digest_nsdmi_init): New. * parser.c (cp_parser_late_parse_one_default_arg): Use it. * init.c (get_nsdmi): Likewise. * cp-tree.h (digest_nsdmi_init): Declare. /testsuite 2014-05-20 Paolo Carlini paolo.carl...@oracle.com PR c++/58753 PR c++/58930 PR c++/58704 * g++.dg/cpp0x/nsdmi-template11.C: New. * g++.dg/cpp0x/nsdmi-template12.C: Likewise. * g++.dg/cpp0x/nsdmi-template13.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template11.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template12.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/parser.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 58753, which changed state. Bug 58753 Summary: Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug c++/58930] [C++11] Bogus error: converting to ... from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 58930, which changed state. Bug 58930 Summary: [C++11] Bogus error: converting to ... from initializer list would use explicit constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug c++/58761] ICE with a lambda capturing this in a NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk so far.
[Bug c++/60463] Lambda function can call a non-const member function with const this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #21 from Rich Felker bugdal at aerifal dot cx --- Created attachment 32830 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32830action=edit proposed patch patch is generated against the revision that introduced this bug.
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Paul Eggert eggert at gnu dot org changed: What|Removed |Added CC||eggert at gnu dot org --- Comment #6 from Paul Eggert eggert at gnu dot org --- Created attachment 32831 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32831action=edit Clarify documentation for __attribute__ ((malloc)). This topic recently came up on the glibc mailing list and there's clearly a lot of confusion about it. See, for example, https://sourceware.org/ml/libc-alpha/2014-05/msg00519.html. Attaching a proposed patch to the documentation to try to help clear this up.
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #7 from Carlos O'Donell carlos at redhat dot com --- (In reply to Paul Eggert from comment #6) Created attachment 32831 [details] Clarify documentation for __attribute__ ((malloc)). This topic recently came up on the glibc mailing list and there's clearly a lot of confusion about it. See, for example, https://sourceware.org/ml/libc-alpha/2014-05/msg00519.html. Attaching a proposed patch to the documentation to try to help clear this up. s/Ussing/Using/g, otherwise the patch in attachment #32831 looks great to me.
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #8 from Paul Eggert eggert at gnu dot org ---
Comment on attachment 32831
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32831
Clarify documentation for __attribute__ ((malloc)).
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 210629)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2014-05-20 Paul Eggert egg...@cs.ucla.edu
+
+ PR other/56955
+ * doc/extend.texi (Function Attributes): Fix __attribute__ ((malloc))
+ documentation; the old documentation didn't clearly state the
+ constraints on the contents of the pointed-to storage.
+
2014-05-19 David Wohlferd d...@limegreensocks.com
* doc/extend.texi: Create Label Attributes section,
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi(revision 210629)
+++ gcc/doc/extend.texi(working copy)
@@ -3207,15 +3207,20 @@
@item malloc
@cindex @code{malloc} attribute
-The @code{malloc} attribute is used to tell the compiler that a function
-may be treated as if any non-@code{NULL} pointer it returns cannot
-alias any other pointer valid when the function returns and that the memory
-has undefined content.
-This often improves optimization.
-Standard functions with this property include @code{malloc} and
-@code{calloc}. @code{realloc}-like functions do not have this
-property as the memory pointed to does not have undefined content.
+This tells the compiler that a function is @code{malloc}-like, i.e.,
+that if the function returns a non-null pointer @var{P}, then @var{P}
+cannot alias any other pointer valid when the function returns, and
+moreover the contents of any storage addressed by @var{P} cannot
+contain a pointer that aliases any other pointer valid when the
+function returns.
+Ussing this attribute often improves optimization. Functions like
+@code{malloc} and @code{calloc} have this property because they return
+a pointer to uninitialized or zeroed-out storage. However, functions
+like @code{realloc} do not have this property, as they can return a
+pointer to storage containing pointers that alias already-valid
+pointers.
+
@item mips16/nomips16
@cindex @code{mips16} attribute
@cindex @code{nomips16} attribute
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Paul Eggert eggert at gnu dot org changed: What|Removed |Added Attachment #32831|0 |1 is obsolete|| --- Comment #9 from Paul Eggert eggert at gnu dot org --- Created attachment 32832 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32832action=edit Revised documentation patch for __attribute__ ((malloc)) Thanks for the quick review. Revised patch attached. Sorry about the noise in my previous reply, I hit Submit by accident.
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 --- Comment #10 from Rich Felker bugdal at aerifal dot cx --- I don't see how it's at all helpful for GCC to assume that memory obtained by __attribute__((__malloc__)) functions does not contain pointers to anything that existed before the call. This assumption only aids optimization in the case where a pointer residing in the obtained memory is used (e.g. dereferenced or compared with another pointer) before anything is stored to it. But with GCC's assumption, such use would be UB anyway and thus cannot occur in a correct program, so there's no sense in optimizing it. The alternative is much more reasonable: assume that a pointer residing in the obtained memory could alias any object whose address has already escaped (roughly, anything but automatic or static/internal-linkage objects whose addresses were not taken and passed to code the compiler can't see). This allows __attribute__((__malloc__)) to be applied to realloc-like functions as well as functions in third-party libraries which allocate non-opaque structures whose members may point to data that's also accessible via other paths. And as far as I can tell, it doesn't preclude any optimizations that could take place in a code path that doesn't invoke UB.
