[Bug rtl-optimization/60317] [4.9 Regression] find_hard_regno_for compile time hog in libvpx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60317 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2014-02-22 00:00:00 |2014-02-23 CC||congh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Started with r204229.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-23 CC||janus at gcc dot gnu.org Summary|Incorrect bounds on |[OOP] Incorrect bounds on |polymorphic dummy array |polymorphic dummy array Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Slightly reduced test case (to exclude that the problem is module-related): program main implicit none type Foo end type call copyFromArray([Foo()]) contains subroutine copyFromArray(array) class (Foo), intent(in) :: array(:) print*,'lbound should be 1: ', lbound(array), ubound(array), size(array) end subroutine end When changing 'class(foo)' to 'type(foo)', the expected output is obtained.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 --- Comment #2 from janus at gcc dot gnu.org --- For both cases (TYPE and CLASS), the temporary that is created (to be passed to copyFromArray) has an lbound of zero (as shown by -fdump-tree-original): atmp.6.dim[0].stride = 1; atmp.6.dim[0].lbound = 0; atmp.6.dim[0].ubound = 0; For the TYPE case, additional code (and another temporary) is generated inside of copyFromArray, which resets the bounds: parm.6.dim[0].lbound = 1; parm.6.dim[0].ubound = D.2342; So we just have to make sure that this additional code is also generated for the CLASS case. Or, why not directly start with lbound=1 for the original temporary?
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 --- Comment #3 from janus at gcc dot gnu.org --- Here is a closely-related variant of comment 1: program main implicit none type Foo end type type(foo), dimension(2:2) :: arg call copyFromArray(arg) contains subroutine copyFromArray(array) class (Foo), intent(in) :: array(:) print*,'lbound should be 1: ', lbound(array) end subroutine end This one also yields '1' for a TYPE argument (as expected), but '2' for a CLASS argument. So, we clearly need to add code to reset the bounds inside of 'copyFromArray' (but having the temporary in comment 1 start from 1 won't hurt either, I guess, though I'm not sure if there is a way to detect the difference).
[Bug middle-end/52306] [4.8 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #32 from Mikael Pettersson --- (In reply to Andreas Schwab from comment #31) > After backporting the patch to 4.8 there is still a package that fails with > the same error, though it doesn't fail with 4.9. This ICE stopped on trunk with Bin Cheng's "Compute, cache and use cost of auto-increment rtx patterns in IVOPT" patch in r205015, see also http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00156.html Backporting this too to 4.8 stops the ICE there for this test case. However, this patch is just a missed-optimization tweak in ivopts, so I suspect it hides the underlying bug rather than fixing it.
[Bug c++/60323] New: incorrect usage of designated initializers with struct which includes flexible array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60323
Bug ID: 60323
Summary: incorrect usage of designated initializers with struct
which includes flexible array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: SvartMetal at yandex dot ru
Created attachment 32203
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32203&action=edit
source file which causes the bug
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
System type:
Linux svartmetal 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
Command line:
g++ bug-with-initializer.cpp
Compiler output:
g++ bug-with-initializer.cpp
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Source code:
struct A {
char c;
int data[];
};
struct A a = {.c = 1, .data = 1};
int main() {
return 0;
}
[Bug tree-optimization/57742] memset(malloc(n),0,n) -> calloc(n,1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Marc Glisse changed:
What|Removed |Added
Attachment #30981|0 |1
is obsolete||
Attachment #31003|0 |1
is obsolete||
--- Comment #14 from Marc Glisse ---
Created attachment 32204
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32204&action=edit
New patch
This seems to work. It also handles the fortran example from comment #3. With a
comment before the new function and a testcase, it will be good to go to
gcc-patches.
Side note: at -O3, if I provide an inline version of operator new (see PR
59894), it handles std::vector(n). However, I had to provide a simple one
(call malloc, if null throw). The one in libsupc++ is way too complicated (2
calls to malloc), and if I refactor it slightly so "malloc" only appears once,
I end up with the following. The edge probabilities are strange (malloc fails
in 95% of cases?), but mostly we have a PHI node with a single argument which
hides the fact that the variables are the same. It is far from the first time I
notice this, is there a real reason to keep those unary PHIs, or should we
optimize them more aggressively?
p_24 = mallocD.1405 (sz_20);
if (p_24 == 0B)
goto ;
else
goto ;
;;succ: 7 [95.5%] (TRUE_VALUE,EXECUTABLE)
;;11 [4.5%] (FALSE_VALUE,EXECUTABLE)
;; basic block 11, loop depth 0, count 0, freq 349, maybe hot
;;prev block 10, next block 12, flags: (NEW, REACHABLE)
;;pred: 10 [4.5%] (FALSE_VALUE,EXECUTABLE)
# PT = { D.16587 } (escaped heap)
# ALIGN = 8, MISALIGN = 0
# p_41 = PHI
# .MEM_42 = VDEF <.MEM_34>
MEM[(struct _Vector_baseD.14156 *)p_2(D)]._M_implD.15030._M_startD.15032 =
p_41;
# PT = { D.16587 } (escaped heap)
# ALIGN = 4, MISALIGN = 0
_19 = p_41 + sz_20;
# .MEM_44 = VDEF <.MEM_42>
MEM[(struct _Vector_baseD.14156
*)p_2(D)]._M_implD.15030._M_end_of_storageD.15034 = _19;
# .MEM_8 = VDEF <.MEM_44>
# USE = anything
# CLB = anything
memsetD.1000 (p_41, 0, sz_20);
[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148 --- Comment #8 from Jerry DeLisle --- Running into some snags here: gfc -fdump-tree-original pr60148.f90 pr60148.f90: In function ‘namelistout’: pr60148.f90:38:0: internal compiler error: Segmentation fault end program I will be fixing this while I am at it. Maybe there is a PR for it already.
[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 --- Comment #9 from Paul Thomas --- Hi Tobias, I need to walk away from this one for 24 hours. I have established this chain: (i) We start building decay_t; (ii) During which we have to build decay_gen_t (from trans-types.c:2456); (iii) Followed by decay_term_t; (iv) Which has a decay_t as its only component; (v) Since this is in the process of being built, what is retruned is the backend_decl without any of the fields. Thus the size cannot be determined; (vi) For reasons that I cannot see, since this component is a pointer, indeterminate size this propagates back to the size of the decay_gen_t component in decay_t; and (vii) This I suppose but have not confirmed, clobbers the initialisation of the vtable. This latter is surmise, on the basis that changing the 'term' field to a pointer still causes the size problem but the ICE goes away. The programme even executes! I cannot see why there is a problem in estimating the size, since the relevant components are either allocatable or pointers - thus the size can be determined. Cheers Paul
[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus --- (In reply to Jerry DeLisle from comment #8) > gfc -fdump-tree-original pr60148.f90 > pr60148.f90: In function ‘namelistout’: Cf. PR60147 / http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01360.html
[Bug libfortran/60324] New: Handle arbitrarily long path names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Bug ID: 60324 Summary: Handle arbitrarily long path names Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org libgfortran uses (stack allocated) arrays of size PATH_MAX or smaller in many places, when creating a temporary path name with a trailing NULL from a Fortran string. However, it's possible for the user to create longer paths, and most libc functions and/or syscalls do support longer path names just fine. So PATH_MAX isn't that useful; properly designed software should be able to deal with arbitrarily long path names. Instead of using such temp arrays, we should instead allocate them on the heap, limited in length only by the available memory. Thus, the current unpack_filename() should be replaced with some kind of fc_strdup() (that is, given a Fortran string, return a pointer to a heap allocated NULL terminated duplicate).
[Bug ipa/60325] New: ICE in ipa_modify_formal_parameters, at ipa-prop.c compiling g++.dg/cilk-plus/CK/lambda_spawns.cc with LTO-profiledbootstrap build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60325
Bug ID: 60325
Summary: ICE in ipa_modify_formal_parameters, at ipa-prop.c
compiling g++.dg/cilk-plus/CK/lambda_spawns.cc with
LTO-profiledbootstrap build
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Created attachment 32205
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32205&action=edit
Preprocessed source
When configured --with-build-config=bootstrap-lto, gcc version 4.9.0 20140223
ICEs a couple of cilk-plus c++ testcases, bith 32bit and 64bit
x86_64-pc-linux-gnu targets:
FAIL: g++.dg/cilk-plus/CK/lambda_spawns.cc -O3 -fcilkplus (internal compiler
error)
FAIL: g++.dg/cilk-plus/CK/lambda_spawns.cc -O3 -fcilkplus (test for excess
errors)
UNRESOLVED: g++.dg/cilk-plus/CK/lambda_spawns.cc -O3 -fcilkplus compilation
failed to produce executable
FAIL: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -O3 -fcilkplus (internal
compiler error)
FAIL: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -O3 -fcilkplus (test for
excess errors)
UNRESOLVED: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -O3 -fcilkplus
compilation failed to produce executable
FAIL: g++.dg/cilk-plus/CK/lambda_spawns.cc -g -O2 -fcilkplus (internal
compiler error)
FAIL: g++.dg/cilk-plus/CK/lambda_spawns.cc -g -O2 -fcilkplus (test for excess
errors)
UNRESOLVED: g++.dg/cilk-plus/CK/lambda_spawns.cc -g -O2 -fcilkplus compilation
failed to produce executable
FAIL: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -g -O2 -fcilkplus (internal
compiler error)
FAIL: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -g -O2 -fcilkplus (test for
excess errors)
UNRESOLVED: g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc -g -O2 -fcilkplus
compilation failed to produce executable
$ /ssd/uros/gcc-build-profiled/gcc/cc1plus -std=c++11 -fcilkplus -O2 -quiet
lambda_spawns.ii
lambda_spawns.cc: In function ‘’:
lambda_spawns.cc:236:1: internal compiler error: in
ipa_modify_formal_parameters, at ipa-prop.c:3516
0x9f4bc8 ipa_modify_formal_parameters(tree_node*, vec)
/home/uros/gcc-svn/trunk/gcc/ipa-prop.c:3516
0x114f0b7 modify_function
/home/uros/gcc-svn/trunk/gcc/tree-sra.c:4861
0x114f0b7 ipa_early_sra
/home/uros/gcc-svn/trunk/gcc/tree-sra.c:5009
0x114f0b7 (anonymous namespace)::pass_early_ipa_sra::execute() [clone
.lto_priv.1931]
/home/uros/gcc-svn/trunk/gcc/tree-sra.c:5065
Please submit a full bug report,
...
#2 0x009f4bc9 in ipa_modify_formal_parameters(tree_node*,
vec) (fndecl=0x7170b400,
adjustments=...)
at /home/uros/gcc-svn/trunk/gcc/ipa-prop.c:3516
#3 0x0114f0b8 in modify_function (adjustments=..., node=) at /home/uros/gcc-svn/trunk/gcc/tree-sra.c:4861
#4 ipa_early_sra () at /home/uros/gcc-svn/trunk/gcc/tree-sra.c:5009
#5 (anonymous namespace)::pass_early_ipa_sra::execute() [clone .lto_priv.1931]
() at /home/uros/gcc-svn/trunk/gcc/tree-sra.c:5065
#6 0x00e025bb in execute_one_pass(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2229
#7 0x00ebc2fb in execute_pass_list (pass=0x1db9d60) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2282
#8 execute_pass_list(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2283
#9 0x00e2a7dd in do_per_function_toporder(void (*)(void*), void*) ()
at /home/uros/gcc-svn/trunk/gcc/passes.c:1630
#10 0x00e0131c in execute_ipa_pass_list(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2613
(gdb) list
3511{
3512 last_parm_void = (TREE_VALUE (tree_last (old_arg_types))
3513== void_type_node);
3514 otypes = ipa_get_vector_of_formal_parm_types (orig_type);
3515 if (last_parm_void)
3516gcc_assert (oparms.length () + 1 == otypes.length ());
3517 else
3518gcc_assert (oparms.length () == otypes.length ());
3519}
3520 else
Please note, that the compiler is built with "gmake profiledbootstrap".
[Bug libstdc++/60326] New: Incorrect type from std::make_unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326 Bug ID: 60326 Summary: Incorrect type from std::make_unsigned Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.spangsege at gmail dot com The `std::make_signed` and `std::make_unsigned` templates appear to be incorrectly implemented in GCC 4.8.1. In particular, both `std::make_signed::type` and `std::make_unsigned::type` produces the type `wchar_t`. I don't claim to know what the right behaviour is, but it seems wrong, what is currently done. Clang 3.4 with `libc++` does this on x86_64: std::make_unsigned::type --> int std::make_unsigned::type --> unsigned which seems more reasonable. The most relevant section in the C++11 standard appears to be 20.9.7.3 [meta.trans.sign].
[Bug libstdc++/60326] Incorrect type from std::make_unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326 --- Comment #1 from Kristian Spangsege --- Oops, should have been: Clang 3.4 with `libc++` does this on x86_64: std::make_signed::type --> int std::make_unsigned::type --> unsigned
[Bug c++/60312] [4.9 Regression] [c++1y] ICE using auto as template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60312 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-24 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60268 --- Comment #6 from Andrey Belevantsev --- Author: abel Date: Mon Feb 24 05:57:02 2014 New Revision: 208066 URL: http://gcc.gnu.org/viewcvs?rev=208066&root=gcc&view=rev Log: gcc/ 2014-02-24 Andrey Belevantsev PR rtl-optimization/60268 * sched-rgn.c (haifa_find_rgns): Move the nr_regions_initial variable initialization to ... (sched_rgn_init): ... here. (schedule_region): Check for SCHED_PRESSURE_NONE earlier. testsuite/ 2014-02-24 Andrey Belevantsev PR rtl-optimization/60268 * gcc.c-torture/compile/pr60268.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr60268.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-rgn.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60268 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrey Belevantsev --- Fixed on trunk.
