[Bug c/42787] Failed to make all-target
--- Comment #2 from monaka at monami-software dot com 2010-01-18 08:01 --- There has a similar issue under h8300-elf target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug target/42775] sparc-linux 4.4.2 fails to rebuild itself when using STAGE1_CFLAGS=-O1
--- Comment #3 from laurent at guerby dot net 2010-01-18 08:41 --- Same result for me with 4.4.3 RC1. backtrace: Program received signal SIGSEGV, Segmentation fault. 0x004ca580 in copy_virtual_operands () Current language: auto; currently asm (gdb) bt #0 0x004ca580 in copy_virtual_operands () #1 0x003d58a0 in gimple_duplicate_bb () #2 0x0010be80 in duplicate_block () #3 0x0010f5e8 in copy_bbs () #4 0x00118650 in duplicate_loop_to_header_edge () #5 0x004b9350 in gimple_duplicate_loop_to_header_edge () #6 0x004a5458 in canonicalize_loop_induction_variables () #7 0x004a62e8 in tree_unroll_loops_completely () #8 0x004c4d80 in tree_complete_unroll () #9 0x003052b8 in execute_one_pass () #10 0x00305494 in execute_pass_list () #11 0x003054b8 in execute_pass_list () #12 0x003054b8 in execute_pass_list () #13 0x0042ba74 in tree_rest_of_compilation () #14 0x005d05b0 in cgraph_expand_function () #15 0x005d2ab8 in cgraph_optimize () #16 0x00028308 in c_write_global_declarations () #17 0x003cbbb0 in toplev_main () #18 0x000adaf4 in main () -- laurent at guerby dot net changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 08:41:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #10 from ubizjak at gmail dot com 2010-01-18 08:42 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00958.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00958.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode
--- Comment #3 from singler at kit dot edu 2010-01-18 09:08 --- Paolo, you were right, it was just the fallback switch missing for this case. And since this specific test issues many thousands of calls with very small input, the overhead was very noticeable. Patch upcoming... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
[Bug target/42789] New: undefined reference to `__sync_fetch_and_add_4'
When I try to compile the program that
ueses boost, for sh4 target, I am getting
the undefined reference errors.
I'll attach the test-case for that, you
just type make to see the errors.
The makefile greps the output because there
are much more undefined references to the
other components of the program that I have
not included in the archive, hope it is enough
for testing.
$ sh4-linux-gcc -v
Using built-in specs.
Target: sh4-linux
Configured with: ../configure --host=i686-pc-linux-gnu --target=sh4-linux
--prefix=/opt/STM/STLinux-2.2/devkit/sh4
--exec-prefix=/opt/STM/STLinux-2.2/devkit/sh4
--bindir=/opt/STM/STLinux-2.2/devkit/sh4/bin
--sbindir=/opt/STM/STLinux-2.2/devkit/sh4/sbin
--sysconfdir=/opt/STM/STLinux-2.2/devkit/sh4/etc
--datadir=/opt/STM/STLinux-2.2/devkit/sh4/share
--includedir=/opt/STM/STLinux-2.2/devkit/sh4/include
--libdir=/opt/STM/STLinux-2.2/devkit/sh4/lib
--libexecdir=/opt/STM/STLinux-2.2/devkit/sh4/libexec
--localstatedir=/opt/STM/STLinux-2.2/devkit/sh4/var
--sharedstatedir=/opt/STM/STLinux-2.2/devkit/sh4/share
--mandir=/opt/STM/STLinux-2.2/devkit/sh4/man
--infodir=/opt/STM/STLinux-2.2/devkit/sh4/info --program-prefix=sh4-linux-
--with-local-prefix=/opt/STM/STLinux-2.2/devkit/sh4
--with-sysroot=/opt/STM/STLinux-2.2/devkit/sh4/target --enable-languages=c,c++
--enable-threads=posix --enable-nls --enable-c99 --enable-long-long
--with-system-zlib --enable-shared --enable-multilib --enable-symvers=gnu
--enable-__cxa_atexit
--with-gxx-include-dir=${prefix}/target/usr/include/c++/4.1.1
Thread model: posix
gcc version 4.1.1 (STMicroelectronics/Linux Base 4.1.1-23)
--
Summary: undefined reference to `__sync_fetch_and_add_4'
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
GCC host triplet: i686-linux-gnu
GCC target triplet: sh4-linux-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- Comment #1 from stsp at users dot sourceforge dot net 2010-01-18 09:10 --- Created an attachment (id=19645) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19645action=view) test-case untar and type make -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- Comment #2 from stsp at users dot sourceforge dot net 2010-01-18 09:15 --- boost is 1.39.0, other versions may not trigger that problem is seems... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
[Bug fortran/42736] [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #8 from pault at gcc dot gnu dot org 2010-01-18 09:54 --- This PR has me somewhat flummoxed. I have changed the title to reflect the fact that it does not matter if the component is allocatable or a pointer. Also, a component reference of an allocatable array of derived types works correctly. There is no reason whatsoever why a temporary is generated; I just cannot see who is making that happen. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression] |Wrong-code with allocatable |Wrong-code with allocatable |compounds |or pointer components in ||elemental functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug tree-optimization/42781] [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-18 09:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42781
[Bug tree-optimization/42781] [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-18 09:57 --- Subject: Bug 42781 Author: rguenth Date: Mon Jan 18 09:57:11 2010 New Revision: 156006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156006 Log: 2010-01-18 Richard Guenther rguent...@suse.de PR tree-optimization/42781 * tree-ssa-structalias.c (find_what_var_points_to): Skip restrict processing only if the original variable was artificial. * gfortran.fortran-torture/compile/pr42781.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42781
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-18 10:07 --- I'm running into this as well, but with code that clearly compiled fine with gcc 4.4. So maybe it's a slightly different issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug debug/42782] [4.5 Regression] VTA missed location: parameter via stack
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-18 10:13 --- Reproduced. Works with -fno-var-tracking-assignments, and looks to be a var-tracking.c problem - the testcase doesn't contain (and doesn't need to contain) any DEBUG_INSNs. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2010-01-18 10:13:58 date|| Summary|VTA missed location:|[4.5 Regression] VTA missed |parameter via stack |location: parameter via ||stack Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
[Bug libstdc++/42788] Segafult in gcc/unwind-dw2.c
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-18 10:20 --- First, try with a current, maintained GCC, gcc4.3.x or better, gcc.4.4.x. If the problem persists to these days, we need a self-contained reproducer. Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42788
[Bug libstdc++/42788] Segafult in gcc/unwind-dw2.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-18 10:21 --- You certainly want to report this to redhat instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42788
[Bug c/42787] Failed to make all-target
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-18 10:23 --- It rather seems you do not have proper target headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail|4.3.4 4.4.3 |4.3.4 4.4.3 4.5.0 Target Milestone|4.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c/42790] New: ICE on building libgcc.c __muldi3.
$ cc1 -msx _muldi3.i -g __muldi3 Analyzing compilation unit Performing interprocedural optimizations visibility *free_lang_data early_local_cleanups whole-program inlineAssembling functions: __muldi3 ../../../../../../../libgcc/../gcc/libgcc2.c: In function e__muldi3f: ../../../../../../../libgcc/../gcc/libgcc2.c:562:1: internal compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2845 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE on building libgcc.c __muldi3. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: monaka at monami-software dot com GCC build triplet: i386-apple-darwin10.2.0 GCC host triplet: i386-apple-darwin10.2.0 GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42790
[Bug target/42779] extremely poor code quality, aliasing issues with __m128i
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-18 10:46 --- If I understand correctly (thanks Richard for the quick and detailed analysis) there is nothing C++0x specific in this target/optimization issue. Thus, I'm removing the marker from the Summary and cleaning it. If I'm wrong please tweak it back, adjust it, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|[C++0x] Variadic templates +|extremely poor code quality, |lambdas = extremely poor|aliasing issues with __m128i |code quality, __m128i and | |aliasing sucks | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
[Bug c++/42697] ice-on-legal-code: template class template function local objects
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-18 10:47 --- It may cause *anything*, in any case inappropriate at this stabilization Stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
[Bug debug/42782] [4.5 Regression] VTA missed location: parameter via stack
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-18 10:57 --- The problem is that dataflow_set_preserve_mem_locs and/or dataflow_set_remove_mem_locs removes all MEMs (with the exception of those referring to decl with 0 MEM_OFFSET in the first function) upon encountering a CALL. For parameters (ARG_POINTER_REGNUM based, or even HARD_FRAME_POINTER_REGNUM based ones I believe) we don't need to remove them, as long as the decl isn't addressable and thus the call shouldn't have modified them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-01-18 11:02 --- (In reply to comment #1) work in progress patch This seems to cause *** No rule to make target `lto/@lto_binary_rea...@.o', needed by `lto1'. error when build = host = target = i686-pc-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-18 11:05 --- (In reply to comment #3) (In reply to comment #1) work in progress patch This seems to cause *** No rule to make target `lto/@lto_binary_rea...@.o', needed by `lto1'. error when build = host = target = i686-pc-linux-gnu There's no diffs for the generated files in there; did you run autoconf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-01-18 11:12 --- Testing a patch to do minimal surgery to restore previous behavior (thus, fix this regression but not the fundamental frontend / middle-end problem). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-17 20:37:33 |2010-01-18 11:12:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 11:21 --- Excellent. If possible, I would suggest removing my temporary hack from the testcase together with the parallel-mode patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
[Bug c++/42780] Incorrect warning message
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-18 11:23 --- N.B. the Host/Target/Target fields are meant for the host triplet such as i686-pc-cygwin Feel free to include the snapshot date and OS details in the main report, but putting them in the Host field just makes it harder to search bug reports. As it says at http://gcc.gnu.org/bugs/ the system type is output by 'gcc -v' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42780
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-01-18 11:24 --- Btw, get_pointer_alignment should get passed an access type to put it into context. For alignment of say INDIRECT_REFs it would be the pointed-to type but for function arguments in general it needs to be 'char' if you don't know anything about the kind of the accesses the function does. That would be the default/fallback align get_pointer_alignment has to assume. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #11 from dodji at gcc dot gnu dot org 2010-01-18 11:24 --- It looks like the fix for PR42761 made the previous fix for this one (the one I reverted) acceptable now. I am waiting for Jason's comment at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00964.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug c++/42697] ice-on-legal-code: template class template function local objects
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 11:25 --- Subject: Re: ice-on-legal-code: template class template function local objects Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new regressions? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-16 12:57:39 |2010-01-18 11:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2010-01-18 11:51 --- did you run autoconf? Forgot to run it, to my disgrace. :) Sorry, false alarm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-01-18 11:43
---
(In reply to comment #28)
Btw, get_pointer_alignment should get passed an access type to put it into
context. For alignment of say INDIRECT_REFs it would be the pointed-to type
but for function arguments in general it needs to be 'char' if you don't know
anything about the kind of the accesses the function does. That would be
the default/fallback align get_pointer_alignment has to assume.
Which, if you look at all current callers, boils down to effectively
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 156006)
+++ gcc/builtins.c (working copy)
@@ -369,8 +369,7 @@ get_pointer_alignment (tree exp, unsigne
if (!POINTER_TYPE_P (TREE_TYPE (exp)))
return 0;
- align = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp)));
- align = MIN (align, max_align);
+ align = BITS_PER_UNIT;
while (1)
{
@@ -380,9 +379,6 @@ get_pointer_alignment (tree exp, unsigne
exp = TREE_OPERAND (exp, 0);
if (! POINTER_TYPE_P (TREE_TYPE (exp)))
return align;
-
- inner = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp)));
- align = MIN (inner, max_align);
break;
case POINTER_PLUS_EXPR:
which of course will regress generated code quite a bit (even though it's
correct). We might be able to recover some bits by walking SSA defs
here but we'll still lose when reaching function arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug c++/42791] New: boost[1.33.1]::spirit depends on optimization level
Hello,
i posted a problem against boost::serialization.
(http://article.gmane.org/gmane.comp.lib.boost.user/54935).
But now i could track it down to boost::spirit.
I have extracted boost::serialization stuff , which is dealing with boost
spirit, in a mini demo program
(will attach tar file next).
It accepts XML input if compiled with -O0 or -O1 and returns #1 (hit) for it:
|hpux03 407 make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 408 ./sample
test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0'
parse_start_tag('pDeleteHlrSubscriberIn class_id=0 tracking_level=0
version=0') returned 1
But it fails (return #0 no hit), if i use -O2 or -O3:
|hpux03 411 make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 412 ./sample
test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0'
parse_start_tag('pDeleteHlrSubscriberIn class_id=0 tracking_level=0
version=0') returned 0
Is it a bug of gcc-3.4.4? (for HP-UX B11.31 ia64?)
Or boost::spirit using experimental C++ feature (for level of gcc-3.4.4)?
- many thanks!
Frank Bergemann
--
Summary: boost[1.33.1]::spirit depends on optimization level
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: FBergemann at web dot de
GCC build triplet: ia64 hp-ux B11.31
GCC host triplet: ia64 hp-ux B11.31
GCC target triplet: ia64 hp-ux B11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug tree-optimization/42652] vectorizer created unaligned vector insns
--- Comment #13 from irar at il dot ibm dot com 2010-01-18 12:17 ---
Does something like this make sense? (With this patch we will never use peeling
for function parameters, unless the builtin returns OK to peel for packed
types).
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 155880)
+++ tree-vect-data-refs.c (working copy)
@@ -1010,10 +1010,29 @@ vector_alignment_reachable_p (struct dat
tree type = (TREE_TYPE (DR_REF (dr)));
tree ba = DR_BASE_OBJECT (dr);
bool is_packed = false;
+ tree tmp = TREE_TYPE (DR_BASE_ADDRESS (dr));
if (ba)
is_packed = contains_packed_reference (ba);
+ is_packed = is_packed || contains_packed_reference (DR_BASE_ADDRESS
(dr));
+
+ if (!is_packed)
+{
+ while (tmp)
+{
+ is_packed = TYPE_PACKED (tmp);
+ if (is_packed)
+break;
+
+ tmp = TREE_TYPE (tmp);
+}
+}
+
+ if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
+ TREE_CODE (SSA_NAME_VAR (DR_BASE_ADDRESS (dr))) == PARM_DECL)
+is_packed = true;
+
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Unknown misalignment, is_packed = %d,is_packed);
if (targetm.vectorize.vector_alignment_reachable (type, is_packed))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #1 from FBergemann at web dot de 2010-01-18 12:18 --- Created an attachment (id=19646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19646action=view) tar file with mini program sources Makefile Pls change the optimization level in Makefile to see the differences. To successfully compile it requires -I for the boost include files. Remember i uses boost 1.33.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-18 12:20 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap --- Comment #16 from hubicka at gcc dot gnu dot org 2010-01-16 14:54 --- Created an attachment (id=19623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view) patch I am testing Unfortunately, this (together with Eric's addition) fails in alpha-dec-osf testing: % /vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/xgcc -B/vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem /vol/gcc/alpha-dec-osf4.0f/include -isystem /vol/gcc/alpha-dec-osf4.0f/sys-include-c -g -O2 -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I/vol/gcc/src/hg/trunk/osf/gcc/ada -I/vol/gcc/src/hg/trunk/osf/gcc/ada/gcc-interface /vol/gcc/src/hg/trunk/osf/gcc/ada/a-except.adb -o ada/a-except.o raised CONSTRAINT_ERROR : SIGSEGV Both gdb 6.6 and 7.0 segv when loading gnat1 on Tru64 UNIX V4.0F, so it's hard to debug from here. On V5.1B, gdb doesn't work properly either: Reading symbols from /vol/gcc/obj/gcc-4.5.0-20100111/5.1b-gcc/gcc/gnat1...Error reading symbol table: Memory exhausted No symbol table is loaded. Use the file command. If I use ladebug instead, I miss the symbolic debug information (ladebug cannot deal with stabs-in-ecoff), but at least I get a stack trace: Thread received signal SEGV stopped at [void _GLOBAL__FD_gnat1(void) 0x121847f58] (ladebug) where 0 0x121847f58 in _GLOBAL__FD_gnat1() in ./gnat1 #1 0x121848b20 in _GLOBAL__FD_gnat1() in ./gnat1 #2 0x12184adfc in _GLOBAL__FD_gnat1() in ./gnat1 #3 0x12184ba6c in _GLOBAL__FD_gnat1() in ./gnat1 #4 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #5 0x12184be88 in _GLOBAL__FD_gnat1() in ./gnat1 #6 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #7 0x120daed08 in _GLOBAL__FD_gnat1() in ./gnat1 #8 0x120dafa98 in _GLOBAL__FD_gnat1() in ./gnat1 #9 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #10 0x120dafbc4 in _GLOBAL__FD_gnat1() in ./gnat1 #11 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #12 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #13 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #14 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #15 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #16 0x12184a090 in _GLOBAL__FD_gnat1() in ./gnat1 #17 0x12184a104 in _GLOBAL__FD_gnat1() in ./gnat1 #18 0x12184a6d8 in _GLOBAL__FD_gnat1() in ./gnat1 #19 0x1218556c0 in _GLOBAL__FD_gnat1() in ./gnat1 #20 0x12144f8a0 in _GLOBAL__FD_gnat1() in ./gnat1 #21 0x121450dc0 in _GLOBAL__FD_gnat1() in ./gnat1 #22 0x121451510 in _GLOBAL__FD_gnat1() in ./gnat1 More (n if no)? n #23 0x121451b34 in _GLOBAL__FD_gnat1() in ./gnat1 #24 0x1204e5e68 in _GLOBAL__FD_gnat1() in ./gnat1 #25 0x120f52a74 in _GLOBAL__FD_gnat1() in ./gnat1 #26 0x120f55fe8 in _GLOBAL__FD_gnat1() in ./gnat1 #27 0x120f56138 in _GLOBAL__FD_gnat1() in ./gnat1 #28 0x120c156c4 in _GLOBAL__FD_gnat1() in ./gnat1 #29 0x120382b98 in __start(...) in ./gnat1 This is really messy: maybe I'll have some more luck with a cross compiler. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 12:27 --- Please, try to reproduce the problem for a currently maintained GCC, thuse either 4.3.x or, better, 4.4.x. In case, please provide a self-contained reproducer in the form of a pre-processed file. For details see: http://gcc.gnu.org/bugs/ Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-03 06:41:47 |2010-01-18 12:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-18 12:54 --- (In reply to comment #5) did you run autoconf? Forgot to run it, to my disgrace. :) Sorry, false alarm. No need to apologise, thanks for testing on linux for me! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #3 from FBergemann at web dot de 2010-01-18 12:55 --- Hi Paolo, i tested again with 1) gcc-4.1.2 package delivered from HP (installed at /opt/hp-gcc-4.1.2/) - it works (no such problem) But there were some warning for compilation /var/tmp//ccgkYSFL.s: Assembler messages: /var/tmp//ccgkYSFL.s:1057: Warning: Use of 'add' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 44 /var/tmp//ccgkYSFL.s:1057: Warning: Only the first path encountering the conflict is reported /var/tmp//ccgkYSFL.s:1056: Warning: This is the location of the conflicting usage 2) gcc-4.3.1 package delivered from HP (installed at /opt/hp-gcc-4.3.1/) - it works (no such problem, also no warnings during compilation) 3) self-compiled /usr/local/gcc-4.3.3/ - it works (no such problem) To make it compile for gcc versions 3.4.4, i just needed to fix the fbe_xml_grammar.hpp to drop extra qualification 'basic_xml_grammarCharType::' on member 'parse_start_tag' respectively 'parse_end_tag' and 'parse_string'. shall i attach again the modified source.tar.gz for this? - thanks! rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #20 from hubicka at ucw dot cz 2010-01-18 12:57 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap This is really messy: maybe I'll have some more luck with a cross compiler. Indeed it is. I will try, but I had problem building the cross because of missing a.out headers. Can you, please, try the change to ada directory itself? That alone should be enough to cure the bootstrap failure (not the C version of testcase). So I am testing it now and intend to commit it ahead of rest of changes. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-01-18 12:59 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-18 13:00 --- Subject: Bug 39954 Author: rguenth Date: Mon Jan 18 12:59:50 2010 New Revision: 156008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156008 Log: 2010-01-18 Richard Guenther rguent...@suse.de PR middle-end/39954 * cfgexpand.c (expand_call_stmt): TER pointer arguments in builtin calls. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug tree-optimization/42728] -fcompare-debug failure (length) at -O1
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-18 13:03 ---
This is a fwprop.c bug. In particular, that the
797 /* If target_insn comes right after def_insn, which is very common
798 for addresses, we can use a quicker test. */
799 if (NEXT_INSN (def_insn) == target_insn
800 REG_P (SET_DEST (def_set)))
shortcut in all_uses_available_at has different behavior depending from the
following code. We have def_insn:
(insn 15 14 18 4 pr42728.c:6 (parallel [
(set (reg/v/f:DI 60 [ b ])
(plus:DI (reg/v/f:DI 60 [ b ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 252 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(as b is uninitialized, this is the only definition of b) and target_insn is
(insn 21 19 22 4 pr42728.c:5 (set (reg:CCZ 17 flags)
(compare:CCZ (mem:QI (reg/v/f:DI 60 [ b ]) [0 S1 A8])
(const_int 0 [0x0]))) 0 {*cmpqi_ccno_1} (nil))
(the only use of it besides debug_insns with -g).
If def_insn and target_insn are adjacent (-g0), then this returns false, as
one of the uses (the only one actually) in def_insn is the target of that insn.
If there are any debug insns in between (or any other), it returns true, as
/* Check if the reg in USE has only one definition. We already
know that this definition reaches use, or we wouldn't be here.
However, this is invalid for hard registers because if they are
live at the beginning of the function it does not mean that we
have an uninitialized access. */
regno = DF_REF_REGNO (use);
def = DF_REG_DEF_CHAIN (regno);
if (def
DF_REF_NEXT_REG (def) == NULL
regno = FIRST_PSEUDO_REGISTER)
return false;
shortcut applies and thus local_ref_killed_between_p is not allowed to return
true (because of the def in def_insn).
To fix this, we could either ensure the shortcut is run regardless of any debug
insns in between (next_nondebug_insn isn't probably usable, as target_insn may
be a debug_insn):
--- fwprop.c.jj 2009-12-10 19:19:08.0 +0100
+++ fwprop.c 2010-01-18 13:55:57.0 +0100
@@ -791,13 +791,16 @@ all_uses_available_at (rtx def_insn, rtx
df_ref *use_rec;
struct df_insn_info *insn_info = DF_INSN_INFO_GET (def_insn);
rtx def_set = single_set (def_insn);
+ rtx next;
gcc_assert (def_set);
/* If target_insn comes right after def_insn, which is very common
for addresses, we can use a quicker test. */
- if (NEXT_INSN (def_insn) == target_insn
- REG_P (SET_DEST (def_set)))
+ next = NEXT_INSN (def_insn);
+ while (next next != target_insn DEBUG_INSN_P (next))
+next = NEXT_INSN (next);
+ if (next == target_insn REG_P (SET_DEST (def_set)))
{
rtx def_reg = SET_DEST (def_set);
or we could do something like:
--- fwprop.c.xx2009-12-10 19:19:08.0 +0100
+++ fwprop.c2010-01-18 14:02:32.0 +0100
@@ -818,17 +818,23 @@ all_uses_available_at (rtx def_insn, rtx
}
else
{
+ rtx def_reg = REG_P (SET_DEST (def_set)) ? SET_DEST (def_set) :
NULL_RTX;
+
/* Look at all the uses of DEF_INSN, and see if they are not
killed between DEF_INSN and TARGET_INSN. */
for (use_rec = DF_INSN_INFO_USES (insn_info); *use_rec; use_rec++)
{
df_ref use = *use_rec;
+ if (def_reg rtx_equal_p (DF_REF_REG (use), def_reg))
+return false;
if (use_killed_between (use, def_insn, target_insn))
return false;
}
for (use_rec = DF_INSN_INFO_EQ_USES (insn_info); *use_rec; use_rec++)
{
df_ref use = *use_rec;
+ if (def_reg rtx_equal_p (DF_REF_REG (use), def_reg))
+return false;
if (use_killed_between (use, def_insn, target_insn))
return false;
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-01-18 13:03:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42728
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 13:05 --- Excellent that it works fine with current GCCs. Frankly, I'm thinking that as far as GCC is concerned the issue can be closed here, maybe you should consider pointing out to the spirit project the little tweak you needed: you know recent GCCs implements the C++ Standard much better, for sure that tweak is needed for any good modern compiler. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.3.3 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
--- Comment #10 from carlr at freemail dot gr 2010-01-18 13:14 --- Please note that computed gotos are factored out because they are a hell to deal with in tree-cfg.c:build_gimple_cfg(). This means that they MUST be unfactored out as promised in the comment without leaving this to another optimization step that may or may not be enabled. Also, for our product there are 97 extra jumps and 95 of them are long jumps, i.e: 12be0: ff e1 jmp *%ecx ... 12dda: e9 01 fe ff ff jmp 12be0 main_loop+0x220 ... so this is a serious both speed and size pessimisation :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #5 from FBergemann at web dot de 2010-01-18 13:31 --- Hi Paolo, well switching to more recent version might be a solution - but unfortunately not that easy to implement for me. It's a big project i am working in. Switching the compiler means invoking our release management to re-create the application release. For this they need to re-create all binary components it depends on, before. Then we have to re-start entire system tests, rollout to customers, etc, ... Before i consider this i need to know where the problem is actually. Is it possible to get a confirmation, that gcc-3.4.4 has some deficit(s) on hp-ux ia64 B11.31? Because it might affect some or all our products on HP-UX. Is there a deficit list for gcc-3.4.4 for HP-UX ia64 B11.31? I tried to look it up on this bug system - but couldn't find such kind of summary. We are also involving HP for this now. And a request to boost.org is also pending. One important thing: The reason, why we are stuck to 3.4.4 here is, that in the past this was a well-optimized compiler (performance). We have been told that newer versions are slower. Now for gcc.4.3.x i am not sure, if this argument is still valid?! Can you gimme some help in that - about performance impacts from switching from 3.4.4 to 4.3.x? - many thanks! best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-18 13:38 --- Very hard to answer all those questions and for an architecture which I don't know well, and for an application which I don't know (of course). For sure here, in the FSF GCC community, 3.4.x is considered a very, very, old release branch, completely unmaintained by now. Thus, my general advice: the sooner you update your tools the better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-18 13:46 --- (In reply to comment #3) Here is a simple patch for setting the parent component accessibility: [...] This is probably not enough, since the access. specification of the parent type may come after the daughter type definition. But this already fixes the exmple in comment #2. This version should be better: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 155994) +++ gcc/fortran/resolve.c (working copy) @@ -10494,6 +10494,12 @@ resolve_fl_derived (gfc_symbol *sym) resolve_typespec_used (c-ts, c-loc, c-name) == FAILURE) return FAILURE; + /* If this type is an extension, set the accessibility of the parent +component. */ + if (super_type c == sym-components + strcmp (super_type-name, c-name) == 0) + c-attr.access = super_type-attr.access; + /* If this type is an extension, see if this component has the same name as an inherited type-bound procedure. */ if (super_type It sets the accessibility at resolution time and makes the following variant of comment #2 work: module mo implicit none type :: tt integer :: i = 1 end type type, extends(tt) :: ttt real :: x = 2.0 end type private :: tt end module program pr use mo implicit none type(ttt) :: obj print *,obj%tt%i end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #7 from FBergemann at web dot de 2010-01-18 14:16 --- Hi Paolo, shouldn't it be WONTFIX then? (as it is against 3.4.4) best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-18 14:25 --- Whatever you prefer. As a matter of fact, now, a PR vs 3.4.4 should be invalid, essentially. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-18 14:36 --- (In reply to comment #5) It sets the accessibility at resolution time and makes the following variant of comment #2 work: That variant works for me already with the trunk, i.e. it is not rejected which is (for me) the expected result. * * * As it took me a while to see whether the various examples are valid or not. (Comment 0 is quite unrelated as it about TBP vs. component accessibility while the rest is about accessibility of inherited components.) Fortran 2003 has in 4.5.6.1 Inheritance: An extended type includes all of the type parameters, all of the components, and the nonoverridden (4.5.6.2) nonfinal procedure bindings of its parent type. These are said to be inherited by the extended type from the parent type. They retain all of the attributes that they had in the parent type. Additional type parameters, components, and procedure bindings may be declared in the derived-type definition of the extended type. An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and type parameters of the parent type. The name of this component is the parent type name. It has the accessibility of the parent type. Note 4.51: Inaccessible components and bindings of the parent type are also inherited, but they remain inaccessible in the extended type. Inaccessible entities occur if the type being extended is accessed via use association and has a private entity. Thus the crucial part is: a) For components they retain all of the attributes that they had in the parent type -- thus the PRIVATE statement which only changes the default has no influence. b) For the parent type: If it is PRIVATE then also extended%parent%par_comp is only accessible in the module per It has the accessibility of the parent type in the second paragraph. But what about: extended%par_comp ? par_comp is PUBLIC while its TYPE is PRIVATE. Just from reading the standard, it looks valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #7 from burnus at gcc dot gnu dot org 2010-01-18 14:39 --- (In reply to comment #6) It sets the accessibility at resolution time and makes the following variant of comment #2 work: That variant works for me already with the trunk, i.e. it is not rejected which is (for me) the expected result. Actually, I misread makes ... work: It is seemingly rejected with the patch and - after (re)reading the standard (see quote in comment 6), I think rejecting is indeed correct. Sorry for not checking that part of my comment before hitting Commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug target/40332] [4.5 Regression] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #11 from jv244 at cam dot ac dot uk 2010-01-18 14:41 --- after the previous comment, marking this as a regression, confirm it, and set P1 as suggest by Ian on the list. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 14:41:59 date|| Summary|(.eh_frame); no |[4.5 Regression] |.eh_frame_hdr table will be |(.eh_frame); no |created.|.eh_frame_hdr table will be ||created. Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:16 --- And a fix along comment #14 would be (untested, but of course fixes the testcase): Index: gcc/fold-const.c === --- gcc/fold-const.c(revision 156009) +++ gcc/fold-const.c(working copy) @@ -1129,10 +1129,14 @@ negate_expr_p (tree t) TYPE_OVERFLOW_WRAPS (type)); case FIXED_CST: -case REAL_CST: case NEGATE_EXPR: return true; +case REAL_CST: + /* We want to canonicalize to positive real constants. Pretend + that only negative ones can be easily negated. */ + return REAL_VALUE_NEGATIVE (TREE_REAL_CST (t)); + case COMPLEX_CST: return negate_expr_p (TREE_REALPART (t)) negate_expr_p (TREE_IMAGPART (t)); looks appealing, but let's check for fallout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #21 from hubicka at gcc dot gnu dot org 2010-01-18 15:42 --- Subject: Bug 42068 Author: hubicka Date: Mon Jan 18 15:42:05 2010 New Revision: 156010 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156010 Log: PR middle-end/42068 (create_var_decl_1): Do not set COMMON flag for unit local variables. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #22 from hubicka at gcc dot gnu dot org 2010-01-18 15:47 --- No longer bootstrap issue, but still ICE on valid. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-06 22:48:22 |2010-01-18 15:47:12 date|| Summary|[4.5 regression] ICE in |[4.5 regression] ICE in |function_and_variable_visibi|function_and_variable_visibi |lity breaks Ada bootstrap |lity with static common ||vars. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:48 --- If it's now middle-end then we need to adjust the priority. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|build |ice-on-valid-code Priority|P4 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-15 18:57:48 |2010-01-18 16:11:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-18 16:18 --- Should we perhaps rename all the lto_elf_ stuff to something else, if all of this also Just Works with COFF? Can we use a similar approach for Mach-O? Big kudos for Dave, btw, for working on this. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 16:18:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug other/42792] New: cc1-dummy link fails with missing tree_ and rtl_ functions
I downloaded a fresh 4.4.2 source distribution and configured and build for x86_64-redhat-linux I'll attach a full build log, but basically the GCC build fails trying to link cc1-dummy with many, many undefined symbols. I've built local copies of GMP, MPFR, MPC in /usr/local (using -fPIC) and did # export LD_LIBRARY_PATH=/usr/local/lib # export LIBRARY_PATH=/usr/local/lib # ./configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local # make and got this error: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -L/usr/local/lib -lmpfr -lgmp i386-c.o: In function `ix86_pragma_target_parse': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:259: undefined reference to `tree_check_failed' /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:271: undefined reference to `tree_check_failed' /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:272: undefined reference to `tree_check_failed' libbackend.a(gtype-desc.o): In function `gt_ggc_mx_rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1477: undefined reference to `rtl_check_failed_flag' libbackend.a(gtype-desc.o): In function `gt_pch_nx_rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:3588: undefined reference to `rtl_check_failed_flag' libbackend.a(gtype-desc.o): In function `gt_pch_p_7rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:6016: undefined reference to `rtl_check_failed_flag' with many more in the log My gcc is # gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) I'll attach a full gcc.log -- Summary: cc1-dummy link fails with missing tree_ and rtl_ functions Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Biesack at sas dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792
[Bug other/42792] cc1-dummy link fails with missing tree_ and rtl_ functions
--- Comment #1 from David dot Biesack at sas dot com 2010-01-18 16:21 --- Created an attachment (id=19647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19647action=view) build log for gcc 4.4.2 build log showing environment, configure, make, and make errors linking cc1-dummy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-01-18 16:29 --- Patch restoring the 4.4 behavior posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00976.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #8 from davek at gcc dot gnu dot org 2010-01-18 16:35 --- (In reply to comment #7) Should we perhaps rename all the lto_elf_ stuff to something else, if all of this also Just Works with COFF? As I said, WIP; I was certainly thinking of renaming it all to lto_objfile_xxx or some similar prefix in time for the final version. Can we use a similar approach for Mach-O? I don't speak Mach-O, but yes, the approach should work. You'd start by saying lto_binary_reader=lto-mach-o in config.gcc and adding a new lto/lto-mach-o.c with the same handful of toplevel functions: open and close file, build section hash, and create section and append binary data to section. Big kudos for Dave, btw, for working on this. Ah, it's nothing - a simple COFF file reader is no BFD... (pun intended) ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug tree-optimization/42642] -fcompare-debug failure with -O1 -fpeel-loops
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 16:57 --- I think this is fixed now, with Alexandre's patch. Could the OP confirm that please? On to the next -fcompare-debug failure :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 17:00 --- This still fails, even with Alexandre's patch for bug 42631. With -fno-web the failure disappears. So this is probably another issue in the webizer. Investigating - mine for now. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:00:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #11 from uros at gcc dot gnu dot org 2010-01-18 17:04 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 17:04:29 2010 New Revision: 156014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156014 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/predicates.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #24 from hubicka at gcc dot gnu dot org 2010-01-18 17:19 --- Subject: Bug 42068 Author: hubicka Date: Mon Jan 18 17:19:13 2010 New Revision: 156016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156016 Log: PR middle-end/42068 * gcc-interface/utils.c (create_var_decl_1): Do not set COMMON flag for unit local variables. Modified: trunk/gcc/ada/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug fortran/42783] [4.5 Regression] Bogus Array bounds violation with optional array argument
--- Comment #2 from pault at gcc dot gnu dot org 2010-01-18 17:31 --- Confirmed. A weird and wonderful feature of this bug is that it disappears for -O2 and higher :-) The problem comes about because fsym-backend_decl is being used, which is incorrect if the argument is missing because this does not correspond to the declaration for the string. Instead, the function gfc_conv_expr_present should be used. A patch is regtesting right now. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:31:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42783
[Bug fortran/42736] [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #9 from pault at gcc dot gnu dot org 2010-01-18 17:32 --- Have posted a fix on the list today. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug tree-optimization/42642] -fcompare-debug failure with -O1 -fpeel-loops
--- Comment #5 from zsojka at seznam dot cz 2010-01-18 17:45 --- $ /mnt/svn/gcc-trunk/binary-155984-lto/bin/g++ -O1 -fpeel-loops -fcompare-debug pr42642.cpp -c g++: pr42642.cpp: -fcompare-debug failure r155984 still fails for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #12 from uros at gcc dot gnu dot org 2010-01-18 17:46 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 17:46:17 2010 New Revision: 156017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156017 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: trunk/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug ada/42793] New: Bug box when using generic package
$ gnatchop unchopped.adb $ gnatmake protocol.adb +===GNAT BUG DETECTED==+ | 4.4.0 (x86_64-unknown-freebsd8.0) Storage_Error stack overflow or erroneous memory access| | Error detected at serial_io.adb:560:3 [protocol.ads:32:3]| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. protocol.adb protocol.ads serial_io.ads serial_io.adb compilation abandoned gnatmake: protocol.adb compilation error It crashes every version of GNAT that I can find on any platform. Unfortunately, I struggled to even write a summary line as I'm not sure what's wrong with the 'Serializable_Enumeration' package. -- Summary: Bug box when using generic package Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at coreland dot ath dot cx GCC host triplet: x86_64-unknown-freebsd8.0, i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug ada/42793] Bug box when using generic package
--- Comment #1 from gcc at coreland dot ath dot cx 2010-01-18 18:13 --- I'm attempting to submit the repro case as an attachment but bugzilla keeps suffering internal errors. Admin contacted... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug ada/42793] Bug box when using generic package
--- Comment #2 from gcc at coreland dot ath dot cx 2010-01-18 18:14 --- Created an attachment (id=19648) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19648action=view) Repro case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug tree-optimization/42642] -fcompare-debug failure with -O1 -fpeel-loops
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2010-01-07 07:17:23 |2010-01-18 18:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #15 from d dot g dot gorbachev at gmail dot com 2010-01-18 18:48 --- Created an attachment (id=19649) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19649action=view) Simple patch It leaves -plugin-opt in LINK_COMMAND_SPEC, but I think it is not quite right, as LIBGCC_SPEC and LIB_SPEC are redefined by many targets (and, for example, choose libc or libc_p depending on -p / -pg / -profile). GCC r155915 bootstrapped with this patch on i686-pc-linux-gnu with and without --disable-shared option. It seems to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-18 18:48 --- This is a bug in boost and not GCC. Not all targets define the __sync_* functions. There is a define for each one saying which one is available. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-18 19:11 --- Subject: Bug 42766 Author: dodji Date: Mon Jan 18 19:11:24 2010 New Revision: 156020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156020 Log: Fix PR c++/42766 gcc/cp/ChangeLog: PR c++/42766 * cvt.c (build_expr_type_conversion): Look through OVERLOAD. gcc/testsuite/ChangeLog: PR c++/42766 * g++.dg/conversion/op6.C: New test. Added: trunk/gcc/testsuite/g++.dg/conversion/op6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-18 19:16 ---
Register number differences appear - again - because a USE operand of a
DEBUG_INSN ends up in a web of its own:
--- R1web/pr42685-2.c.167r.web 2010-01-18 11:11:38.0 -0800
+++ R2web/pr42685-2.c.167r.web 2010-01-18 11:11:38.0 -0800
@@ -7,275 +7,323 @@
df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 108 (
2)
df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 109 (
2)
Web oldreg=386 newreg=401
-Updating insn 82 (386-401)
-deferring rescan insn with uid = 82.
-Web oldreg=371 newreg=402
-Updating insn 63 (371-402)
-deferring rescan insn with uid = 63.
-Web oldreg=375 newreg=403
-Updating insn 394 (375-403)
-deferring rescan insn with uid = 394.
+Updating insn 96 (386-401)
+deferring rescan insn with uid = 96.
+Web oldreg=375 newreg=402
+Updating insn 72 (375-402)
+deferring rescan insn with uid = 72.
+Web oldreg=371 newreg=403
+Updating insn 75 (371-403)
+deferring rescan insn with uid = 75.
+Updating insn 468 (375-402)
+deferring rescan insn with uid = 468.
...
@@ -413,12 +474,19 @@
(label_ref #)
(pc)))# {*br_true} (expr_list:REG_BR_PROB (const_int 7100
[0x1bbc])
(nil))
- - 65)
+ - 77)
(note# # # 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#2 (zero_extend:DI
(reg/v:SI 402 [ i ])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#1 (mult:DI
(debug_expr:DI D#2)
+(const_int 4 [0x4])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI s (clobber (const_int 0
[0x0])))# (nil))
+
(insn# # # 10 pr42685-2.c:10 (set (reg:SI 120 out0)
-(mem/s/j:SI (reg:DI 402 [ ivtmp.5 ]) [0 D.1998-i+0 S4 A32]))#
{movsi_internal} (nil))
+(mem/s/j:SI (reg:DI 403 [ ivtmp.5 ]) [0 D.1998-i+0 S4 A32]))#
{movsi_internal} (nil))
(call_insn# # # 10 pr42685-2.c:10 (parallel [
(call (mem:DI (symbol_ref:DI (baz) [flags 0x41] function_decl
# baz) [0 S8 A64])
This whole compare-debug stuff makes no sense to me, so I'm not even going to
try to come up with a fix. IMHO the proper fix would be to never even try to
rename a web that consists of just a single USE. I don't see how that is any
more right than no debug info at all since no DEF reaches the USE (i.e.
uninitialized) so any value represented in the debug info is fair and
reasonable.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #9 from dodji at gcc dot gnu dot org 2010-01-18 19:17 --- Fixed in 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug tree-optimization/42642] -fcompare-debug failure with -O1 -fpeel-loops
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 --- Same issue: web renaming a single-USE web. *** This bug has been marked as a duplicate of 42685 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 --- *** Bug 42642 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-18 19:55 ---
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 155875)
--- gcc/fortran/trans-decl.c(working copy)
*** gfc_generate_function_code (gfc_namespac
*** 4256,4262
stmtblock_t block;
stmtblock_t body;
tree result;
! tree recurcheckvar = NULL;
gfc_symbol *sym;
int rank;
bool is_recursive;
--- 4257,4263
stmtblock_t block;
stmtblock_t body;
tree result;
! tree recurcheckvar = NULL_TREE;
gfc_symbol *sym;
int rank;
bool is_recursive;
*** gfc_generate_function_code (gfc_namespac
*** 4446,4456
gfc_add_expr_to_block (block, tmp);
/* Reset recursion-check variable. */
if ((gfc_option.rtcheck GFC_RTCHECK_RECURSION) !is_recursive
! !gfc_option.flag_openmp)
! {
! gfc_add_modify (block, recurcheckvar, boolean_false_node);
! recurcheckvar = NULL;
! }
}
--- 4447,4457
gfc_add_expr_to_block (block, tmp);
/* Reset recursion-check variable. */
if ((gfc_option.rtcheck GFC_RTCHECK_RECURSION) !is_recursive
! !gfc_option.flag_openmp recurcheckvar != NULL_TREE)
! {
! gfc_add_modify (block, recurcheckvar, boolean_false_node);
! recurcheckvar = NULL_TREE;
! }
}
Gets rid of the trivial problem reported by Richard.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #25 from simon at pushface dot org 2010-01-18 20:41 --- OK on i86_64-apple-darwin10.2, powerpc-wrs-vxworks (hosted on i366-apple-darwin10.2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #26 from simon at pushface dot org 2010-01-18 20:54 --- (In reply to comment #22) No longer bootstrap issue, but still ICE on valid. The problem is that the ICE-on-valid occurs while building the Ada RTS, and that is a bootstrap issue for Ada (what I mean is, a build configured with --enable-languages=foo,ada will fail). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #12 from dodji at gcc dot gnu dot org 2010-01-18 21:19 --- Subject: Bug 42634 Author: dodji Date: Mon Jan 18 21:18:49 2010 New Revision: 156022 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156022 Log: Fix PR c++/42634 gcc/cp/ChangeLog: PR c++/42634 * error.c (dump_template_parms): Use innermost template arguments before calling count_non_default_template_args. (count_non_default_template_args): We are being called with template innermost arguments now. There is no need to ensure that again. gcc/testsuite/ChangeLog: PR c++/42634 * g++.dg/template/error45.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #13 from uros at gcc dot gnu dot org 2010-01-18 21:44 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 21:44:32 2010 New Revision: 156024 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156024 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/predicates.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #14 from ubizjak at gmail dot com 2010-01-18 21:48 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.3 4.5.0 |4.3.4 4.4.3 4.5.0 Known to work|4.3.4 | Resolution||FIXED Target Milestone|4.4.3 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug c/42790] ICE on building libgcc.c __muldi3.
--- Comment #1 from monaka at monami-software dot com 2010-01-18 22:07 --- Created an attachment (id=19650) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19650action=view) Preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42790
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #21 from anlauf at gmx dot de 2010-01-18 22:18 --- (In reply to comment #19) Regressions on fortran-dev branch fixed. Due to the patch in http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html Jerry, is this patch supposed to be complete for fortran-dev? I still get this failure with the latest fortran-dev on the original testcase: gfcbug96.f90:43.23: use concrete_gradient 1 Error: The element in the derived type constructor at (1), for pointer component '$extends', is DERIVED but should be DERIVED Should I open a new PR for this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)
--- Comment #7 from chris2553 at googlemail dot com 2010-01-18 22:24 --- I can confirm that the patch at comment 4 has fixed the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
[Bug ada/42793] Bug box when using generic package
--- Comment #3 from gcc at coreland dot ath dot cx 2010-01-18 22:46 --- Created an attachment (id=19651) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19651action=view) Another repro This appears to be the same bug but giving a slightly more interesting crash message: $ gnatchop proto1.adb $ gnatmake proto1.adb +===GNAT BUG DETECTED==+ | 4.4.0 (x86_64-unknown-freebsd8.0) GCC error: | | in simplify_subreg, at simplify-rtx.c:4954 | | Error detected around protocol.adb:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. list may be incomplete raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 gnatmake: protocol.adb compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #23 from gcc at coreland dot ath dot cx 2010-01-18 22:51 --- Created an attachment (id=19652) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19652action=view) Another repro A smaller, simpler piece of code that triggers this: $ gnatmake p.adb p.adb:8:70: wrong type for return_subtype_indication gnatmake: p.adb compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #24 from gcc at coreland dot ath dot cx 2010-01-18 22:53 --- Created an attachment (id=19653) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19653action=view) A smaller repro for the _master conflicts with declaration error $ gnatmake arc_dir_003.adb gcc -c arc_dir_003.adb arc_dir_003.adb:29:26: _master conflicts with declaration at line 30 gnatmake: arc_dir_003.adb compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 23:14 --- Subject: Bug 42634 Author: dodji Date: Mon Jan 18 23:14:01 2010 New Revision: 156026 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156026 Log: Revert fix of PR c++/ gcc/cp/ChangeLog: * error.c (dump_template_parms, count_non_default_template_args): Revert fix of PR c++/42634. gcc/testsuite/ChangeLog: * g++.dg/template/error45.C: reverted as part of reverting the fix of PR c++/42634. Removed: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug c/42787] Failed to make all-target
--- Comment #4 from monaka at monami-software dot com 2010-01-18 23:21 --- (In reply to comment #3) It rather seems you do not have proper target headers. What's proper target headers? If it's t-m32r.h, I have it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #2 from monaka at monami-software dot com 2010-01-18 23:29 --- (In reply to comment #1) If you use -arch ppc, then the host/build is really powerpc-apple-darwin so obviously you are configuring GCC incorrectly and the error message is correct as that is x86 inline-asm that is being compiled in that source. There is no need to use -arch option if we use powerpc-apple-darwin host/build. I think it can be resolved by a patch follows. diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c index 17694ef..dc69a80 100644 --- a/gcc/config/i386/driver-i386.c +++ b/gcc/config/i386/driver-i386.c @@ -25,7 +25,7 @@ along with GCC; see the file COPYING3. If not see const char *host_detect_local_cpu (int argc, const char **argv); -#ifdef __GNUC__ +#if defined(__GNUC__) (defined(__i386__) || defined(__x86_64__)) #include cpuid.h struct cache_desc -- monaka at monami-software dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|error: impossible constraint|error: impossible constraint |in �easm�f |in 'asm' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug middle-end/42794] New: PRE produces illegal PHI node
The following (reduced) code:
typedef enum {
TYPE_NON_IDR,
TYPE_IDR,
} NAL_UNIT_TYPE;
typedef struct recordTag
{
} Record;
typedef struct {
unsigned int ActualSize;
unsigned short *Slice;
}Info;
typedef struct {
} Params;
typedef struct {
NAL_UNIT_TYPE unit_type;
} NAL_UNIT;
unsigned int foo( Info *Decode, unsigned int nal_len)
{
NAL_UNIT nal_unit;
unsigned short *Backend;
unsigned char complete;
int *BufLen = (int *)Decode-ActualSize;
do{
*BufLen = *BufLen - nal_len;
if (((nal_unit.unit_type) == TYPE_NON_IDR))
{
Decode-Slice = Backend;
}
}while (*BufLen 0);
Finish( complete);
}
Produces infinite loop with this options: -O2
gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--prefix=/x/x86_gcc_4.4/bin --enable-languages=c,c++ --disable-checking
Thread model: posix
gcc version 4.4.0 (GCC)
The issue first appears in tree PRE (from reduced2.c.084t.pre):
...
bb 2:
D.1896_2 = Decode_1(D)-ActualSize;
BufLen_3 = (int *) D.1896_2;
pretmp.16_34 = Decode_1(D)-ActualSize;
bb 3:
# prephitmp.17_35 = PHI pretmp.16_34(2), D.1905_12(8)
D.1907_14 = prephitmp.17_35;
D.1899_7 = D.1907_14 - nal_len_6(D);
D.1900_8 = (int) D.1899_7;
*BufLen_3 = D.1900_8;
if (nal_unit$unit_type_16(D) == 0)
goto bb 4;
else
goto bb 7;
bb 7:
goto bb 5;
bb 4:
Decode_1(D)-Slice = Backend_10(D);
pretmp.16_36 = Decode_1(D)-ActualSize;
bb 5:
# prephitmp.17_37 = PHI prephitmp.17_35(7), pretmp.16_36(4)
D.1905_12 = prephitmp.17_37;
D.1906_13 = (int) D.1905_12;
if (D.1906_13 0)
goto bb 8;
else
goto bb 6;
The first argument of this PHI: # prephitmp.17_37 = PHI prephitmp.17_35(7),
pretmp.16_36(4) is wrong - instead of decremented value it uses original one.
PRE only makes an earlier DF analysis issue evident. The problem is elsewhere.
Any suggestions are highly appreciated.
--
Summary: PRE produces illegal PHI node
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-18 23:52 --- Works fine for me with current mainline and 4_4-branch. Please, fetch the current sources and try again, if you can still see something wrong re-open, or file a different issue if the problem is different. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.1 4.4.3 4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 23:57 --- I'm sorry, maybe you didn't mean the compiler loops, you mean the code is miscompiled to an infinite loop?!? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
