--- Comment #2 from deligonul at gmail dot com 2010-05-01 07:09 ---
The specialization seems to be causing the problem. If I remove that (and
define a foo() for the original template), it compiles fine.
--
deligonul at gmail dot com changed:
What|Removed
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-01 09:57 ---
I have applied the patch in comment #22 and it fixes all the ICE I have in
store with DATA initialization (including those remaining after the patch in
comment #19: see comment #20).
I have also found that codes suc
--- Comment #24 from dfranke at gcc dot gnu dot org 2010-05-01 10:24
---
(In reply to comment #23)
> are only detected with the -pedantic option.
Or -std=f95; data.c has:
/* Overwriting an existing initializer is non-standard but usually only
provokes a warning from other compil
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 10:36
---
Dominique, if you apply this hunk
Index: data.c
===
--- data.c (revision 158958)
+++ data.c (working copy)
@@ -352,8 +352,10 @@ gfc_assign_
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-01 11:15
---
Undoing the changes of comments #7, #12 and #16, I now (with splay-tree
constructors get):
$ time gfortran-svn -Wall pr40472.f90
real0m2.130s
user0m1.924s
sys 0m0.148s
Instead of those 11 minutes sho
--- Comment #24 from dominiq at lps dot ens dot fr 2010-05-01 12:14 ---
> Undoing the changes of comments #7, #12 and #16, I now (with splay-tree
> constructors get):
> ...
> Dominique, could you apply this patch and check whether you still get an ICE?
Without undoing the changes but wi
--- Comment #26 from dominiq at lps dot ens dot fr 2010-05-01 12:20 ---
> Dominique, if you apply this hunk ...
With the changes in comment #25, I get only warnings/errors along one dimension
(probably the first, but have to check): a(3,3) gives 3 warnings/errors and
a(10,10) gives 10 o
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 12:27
---
(In reply to comment #24)
> Without undoing the changes but with the patch in comment #23, the
> ICE with the test in comment #21 is gone.
The patch in #23 actually reverts the previous changes :)
If I read your
--- Comment #27 from dominiq at lps dot ens dot fr 2010-05-01 12:30 ---
> With the changes in comment #25, I get only warnings/errors along one
> dimension
> (probably the first, but have to check)
Apparently the repetition is along the last dimension:
i(5,10) gives 10 errors/warnings
--- Comment #28 from dfranke at gcc dot gnu dot org 2010-05-01 12:36
---
(In reply to comment #27)
> Apparently the repetition is along the last dimension:
> i(5,10) gives 10 errors/warnings and i(10,5) gives 5 ones.
Could you post the full test? I can't reproduce this?!
--
http:/
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-01 12:39 ---
With gcc version 4.6.0 20100501 (experimental) (GCC)
$ cat unused.c
int main() {
int i;
i = 42;
return 0;
}
$ gcc-svn -Wall unused.c
unused.c: In function 'main':
unused.c:2:7: warning: variable &
--- Comment #26 from dominiq at lps dot ens dot fr 2010-05-01 12:52 ---
> The patch in #23 actually reverts the previous changes :)
I blindly applied the patch without looking at the previous changes!)
> If I read your timing correctly, that's ~4 seconds versus >10 minutes of
> before?
--- Comment #29 from dominiq at lps dot ens dot fr 2010-05-01 12:59 ---
>Could you post the full test? I can't reproduce this?!
[macbook] lin/test% cat ../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90
SUBROUTINE data_init_matrix_invalid()
! full array initializer, re-initialize
--- Comment #27 from dfranke at gcc dot gnu dot org 2010-05-01 13:08
---
(In reply to comment #26)
> Also I see a small slow down for the test in pr34554 (gfc is patched, gfcp
> not):
>
> [macbook] f90/bug% time gfc pr34554.f90
> 259.917u 0.168s 4:20.44 99.8% 0+0k 0+29io 0pf+0w
> [mac
--- Comment #30 from dfranke at gcc dot gnu dot org 2010-05-01 13:13
---
Created an attachment (id=20525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20525&action=view)
updated patch
Updated patch. Fixes the multiplication of errors shown in comment #29. Not yet
regtested.
--
--- Comment #3 from viriketo at gmail dot com 2010-05-01 13:46 ---
I just tested the bootstrap *not profiled*, and it works perfectly. Building a
cross compiler from x86_64-unknown-linux to armv5tel-unknown-linux-gnueabi also
works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-01 13:58 ---
It is caused by revision 157745:
http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00582.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 14:24 ---
This is very close to PR30438.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33884
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-01 14:25 ---
See also PR33884.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2010-05-01 14:37
---
Yes, please leave the limit in and allow users to change the max. This is a
safety net and also communicates to users they have to be careful what they are
doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-01 14:40 ---
Created an attachment (id=20526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20526&action=view)
proof-of-concept patch, with Mach-O writer implemented now
Remaining failures due to missing support for what's
--- Comment #20 from steven at gcc dot gnu dot org 2010-05-01 14:43 ---
On x86_64-unknown-linux-gnu, I see that gcc.dg/lto/20090126 also fails (see
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00031.html). So the test
suite results on x86_64-darwin are the same as on x86_64-linux mo
--- Comment #29 from dfranke at gcc dot gnu dot org 2010-05-01 14:52
---
(In reply to comment #28)
> Yes, please leave the limit in and allow users to change the max.
Ok. Closing this PR as very thoroughly FIXED then :)
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-05-01 14:53
---
+ /* ??? Some targets need to handle LTO assembler output specially.
+ Is this the right place to hanlde that? */
+ if (flag_generate_lto)
yes.
+ if (flag_generate_lto)
+targetm.asm_out.lto_end ();
s
--- Comment #22 from dominiq at lps dot ens dot fr 2010-05-01 15:26 ---
Sorry to bother you, but with the patch in comment #19 bootstrap fails at stage
2 with the infamous "all warnings being treated as errors":
...
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/
--- Comment #8 from gerald at pfeifer dot com 2010-05-01 16:30 ---
This is still the case with a current (2010-04-26) snapshot of GCC 4.6.0.
--
gerald at pfeifer dot com changed:
What|Removed |Added
-
--- Comment #6 from gerald at pfeifer dot com 2010-05-01 16:39 ---
(In reply to comment #0)
> Consider the following code snippet:
> bash-2.05$ cat foo.cc
> struct X { int y; };
>
> void foo() {
> X c;
> X tmp2;
> X d = tmp2;
> }
>
> Both c and d are unused. However, we only ge
--- Comment #7 from gerald at pfeifer dot com 2010-05-01 16:47 ---
(In reply to comment #4)
> I think this applies to 4.3 as well, as the following code does only warn in
> the second function:
The current snapshot mentioned above now warns as follows:
y.c: In function 'oldstyle':
y.c:
--- Comment #7 from pault at gcc dot gnu dot org 2010-05-01 17:16 ---
I do not see any reason not to confirm this one.
This
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 158958)
--- gcc/fortran
Hello,
Like with gcc and g++, for compiling .F sources with gfortran, I
thankfully use automatic dependencies generator built into gcc's cpp.
E.g. for
$ cat test.F
#include "test.h"
program test
print *,'Hello World!'
print *,ZZZ
end
$ cat te
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-01 18:28 ---
You should grep for unused_but_set_, then you'll see also:
c-decl.c:OPT_Wunused_but_set_variable,
c-decl.c: if (warn_unused_but_set_parameter)
c-decl.c: OPT_Wunused_but_set_parameter,
See http://gcc.gnu.org/
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 18:30 ---
How about this?
Index: resolve.c
===
--- resolve.c (revision 158958)
+++ resolve.c (working copy)
@@ -11824,6 +11827,7 @@ traverse_data_list (gfc_d
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 20:15 ---
This was probably fixed when gamma was introduced for F2008.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-01 20:20
---
By now we have proper whole-file checking. Is this PR still relevant?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
SUB(A,I)
1
Warning: Unused dummy argument 'a' at (1)
gcc version 4.6.0 20100501 (experimental) (GCC)
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-01 20:44 ---
(In reply to comment #2)
> I somehow missed that clause. I think one can thus close this bug.
Finally doing so. Please re-open if new information was obtained in the
meantime.
--
dfranke at gcc dot gnu dot org c
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-01 21:30 ---
Subject: Bug 43949
Author: rguenth
Date: Sat May 1 21:30:26 2010
New Revision: 158965
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158965
Log:
2010-05-01 Richard Guenther
PR tree-optimization/
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-01 21:31 ---
Fixed for trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Com
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-01 21:40 ---
After some surgery in gcc/lto/lto-macho.h and gcc/lto/lto-macho.c, I have
managed to bootstrap. Now the full polyhedron test pass without failure. The
timings with my default options, with -fwhole-file, and with -flt
--- Comment #24 from steven at gcc dot gnu dot org 2010-05-01 21:51 ---
Created an attachment (id=20527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20527&action=view)
final patch
I plan to submit this, but with 32 bits disabled because I get failures I don't
understand.
--
With gcc 4.1.x - gcc 4.4.x , on linux-2.6.x (many "x" versions tried over the
last few years) , whenever gcc tries to output to a file on a filesystem that
does not contain sufficient disk space, the linux kernel silently locks up -
I'm not sure if this is a kernel bug or a gcc bug, but a bug it d
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-01 22:08 ---
GCC does not write infinitely. This is a kernel bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-05-01
22:18 ---
Steven,
Do you mean the errors which have "symbol xxx can't be undefined in a
subtraction expression"? A google shows this to look like that discussed
here...
http://gcc.gnu.org/ml/gcc-bugs/2003-11/ms
--- Comment #26 from stevenb dot gcc at gmail dot com 2010-05-01 22:30
---
Subject: Re: Mach-O LTO support needed for darwin
> Do you mean the errors which have "symbol xxx can't be undefined in a
> subtraction expression"?
Yes, exactly those.
> A google shows this to look like t
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-05-01
22:41 ---
This issue also appears to exist in llvm-gcc-4.2-2.7...
llvm-gcc -O3 -fnested-functions pr10901.c
pr10901.c: In function 'main':
pr10901.c:5: sorry, unimplemented: non-local gotos not supported by LLVM
--- Comment #2 from jason dot vas dot dias at gmail dot com 2010-05-01
22:41 ---
OK, but you cannot state "this is a kernel bug" without proving this to be the
case .
Every time I make a mistake about available disk space and start a gcc compile,
and disk space is exhausted, the machine
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-01 22:44 ---
GCC is an user level program. No user program should cause the kernel to lock
up therefore it is a kernel issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #4 from jason dot vas dot dias at gmail dot com 2010-05-01
22:47 ---
Has there been any history of reported linux kernel lock-ups for
gcc compilations outputting to filesystems with insufficient disk space ?
It could be something to do with using "make -j2" on my dual proce
How to reproduce:
g++ -flto -g -c mailtool.i
mailtool.C: In member function doUploadMessage(mail::ACCOUNT*,
mail::folder*)::uploadMessage::getMessageContents():
mailtool.C:493:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #1 from andrej dot gelenberg at udo dot edu 2010-05-01 22:52
---
Created an attachment (id=20528)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20528&action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43956
--- Comment #2 from andrej dot gelenberg at udo dot edu 2010-05-01 22:53
---
Source is from cone-0.82
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43956
--- Comment #5 from jason dot vas dot dias at gmail dot com 2010-05-01
22:55 ---
Sometimes disk space runs out before the machine locks up,
but I get loads of invalid objects ;
I think it is a bug that gcc can continue after producing invalid object files:
gcc -Wp,-MD,arch/x86/po
--- Comment #3 from falk at debian dot org 2010-05-01 23:11 ---
Confirmed. Here is a test case that gives:
mini.cc: In member function uploadMessage:
mini.cc:6:49: internal compiler error: tree check: expected class type, have
declaration (function_decl) in gen_type_die_with_usage,
--- Comment #6 from jason dot vas dot dias at gmail dot com 2010-05-01
23:13 ---
Aha ! I think I see the problem, or at least A problem :
$ strace -f gcc ~jason/t.c -o /tmp/t 2>&1 | grep sync
$
Nothing is doing a fsync(int fd) for any object file written by gcc .
Hence writes by gcc
--- Comment #27 from mrs at gcc dot gnu dot org 2010-05-01 23:22 ---
Ok for all the darwin bits with any necessary mods to turn off or fix the
32-bit port. If you attach the the 32-bit .s file, I can puzzle it out for
you. In short, only - of two defined symbols in the same section wor
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2010-05-01
23:59 ---
Created an attachment (id=20529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20529&action=view)
example 32-bit failing testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:01 ---
Mike,
I've attached one of the failing testcases with all of the files generated
by the commands...
/Users/stevenb/lto_objdir32/gcc/xgcc -B/Users/stevenb/lto_objdir32/gcc/
--save-temps -O0 -fwhopr -
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:07 ---
Created an attachment (id=20530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20530&action=view)
non-failing testcase for 64-bit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #31 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:09 ---
Mike,
I've also attached the same non-failing testcase from the x86_64 build
generated with the commands...
/Users/stevenb/lto_objdir/gcc/xgcc -B/Users/stevenb/lto_objdir/gcc/
--save-temps -O0 -fwhop
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/const-uniq-1.c -Os -fdump-tree-gimple -S
-o const-uniq-1.s(timeout = 300)
PASS: gcc.dg/const-uniq-1.c (test for excess errors)
FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-time
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c -O2 -fipa-pta
-fdump-ipa-
pta-details -lm -o ./ipa-pta-10.exe(timeout = 300)
PASS: gcc.dg/ipa/ipa-pta-10.c (test for excess errors)
Setting LD_LIBRARY_PATH
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/builtin-cproj-1.c -O1-lm -o
builtin-cproj-1.exe(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
link_error (first referenced in /var/tmp//ccKBsQ1R.o) (co
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:47 ---
The failing command out of the log from the 32-bit testcase is...
/Users/stevenb/lto_objdir32/gcc/lto1 -fPIC -quiet -dumpbase
gcc-dg-lto-2008-01.ltrans0 -dumpdir ./ -mmacosx-version-min=10.6.3
-mtune=
This testcase redeclares template H::F with different number of parameters.
This should be illegal, but gcc-4.5.0 passes it.
--- testcase ---
namespace H {
template struct F;
}
;
class Z {
template friend struct H::F;
};
--
Summary: Template redeclaration with different number of
--- Comment #33 from mrs at gcc dot gnu dot org 2010-05-02 01:23 ---
So, mumble isn't defined in the wpa file. The .wpa. file has to be assembled
at the same time as 2008_1.s, or, different code would need to be
generated. darwin.c manages the code gen by asking the question, is th
--- Comment #9 from hjl at gcc dot gnu dot org 2010-05-01 13:53 ---
Subject: Bug 43951
Author: hjl
Date: Sat May 1 13:52:52 2010
New Revision: 158959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158959
Log:
Revert the accidental checkin in revision 158918.
gcc/cp/
2010-05-0
--- Comment #4 from irar at il dot ibm dot com 2010-05-02 05:51 ---
I don't have access to ia64. I tried to change the types in the test to make
the basic blocks vectorizable on x86_64, but didn't get any error. So I still
need SLP dump in order to solve this.
Thanks,
Ira
--
irar at
67 matches
Mail list logo
