--- Comment #4 from joachim dot reichel at gmx dot de 2010-07-14 06:22
---
I tested your patch on gcc 4.4.4. I ran into PR 40974 and used the patch in
comment #20.
The full program (and the test case) now compiles fine. Note that I only
compiled the program. I was not able to run it
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-14 07:39 ---
Please submit a fully pre-processed source for someone to look at this as per
comment #2.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-07-14 08:09 ---
Subject: Bug 44925
Author: janus
Date: Wed Jul 14 08:09:05 2010
New Revision: 162169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162169
Log:
2010-07-14 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #10 from janus at gcc dot gnu dot org 2010-07-14 08:15 ---
Fixed with r162169. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-07-14 08:20
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-07-14 08:35
---
Created an attachment (id=21196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21196action=view)
patch
Can you test this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #7 from gnuzip at gmail dot com 2010-07-14 08:39 ---
I can confirm similar problem under openwrt buildroot environment (trunk
r22177) with gcc 4.5.0. The build host is Debian testing, 2.6.32-trunk-686.
reproduced with:
--- Comment #8 from gnuzip at gmail dot com 2010-07-14 08:40 ---
Created an attachment (id=21197)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21197action=view)
recovery.i file (openwrt)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43995
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-14 08:42 ---
Yeah, it looks like so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-14 09:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-14 09:07 ---
Subject: Bug 44930
Author: rguenth
Date: Wed Jul 14 09:06:34 2010
New Revision: 162174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162174
Log:
2010-07-14 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from asche at primion dot de 2010-07-14 09:07 ---
Created an attachment (id=21198)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21198action=view)
see comment
What do you mean preprocessed? What I can offer is in the attachment - a
standalone C file that you can
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44930
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-14 09:12 ---
Only the pointed-to value is volatile. A volatile pointer would be
unsigned char * volatile ptr;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from yottui at yahoo dot co dot jp 2010-07-14 09:22 ---
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
-- begin testcase --
// g++ -O -msse2 test.cpp
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
struct
--- Comment #5 from asche at primion dot de 2010-07-14 09:35 ---
well, in that case we stand revealed as goofballs. Kudos to the team, thanks
for a great turnaround and sincerest apologies for submitting a bogus bug
request. Let us know how we can get a keg of well deserved German
--- Comment #2 from htl10 at users dot sourceforge dot net 2010-07-14
10:05 ---
This seems to have become an regression - it worked in 4.3.3 and failed in
4.3.5 .
--
htl10 at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #17 from jojelino at gmail dot com 2010-07-14 10:07 ---
(In reply to comment #16)
Created an attachment (id=21196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21196action=view) [edit]
patch
Can you test this patch?
yes. attached patch solves ICE. it works well.
--- Comment #7 from victor dot pasko at gmail dot com 2010-07-14 10:11
---
(In reply to comment #6)
Please don't keep reopening this bug.
Why? I disagree with your resolution.
The symbols are weak undefs because libgfortran doesn't require (and shouldn't
require) libpthread, it is
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-14 12:19
---
Subject: Bug 44824
Author: rguenth
Date: Wed Jul 14 12:19:16 2010
New Revision: 162177
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162177
Log:
2010-07-14 Richard Guenther rguent...@suse.de
PR
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-14 12:19
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from yottui at yahoo dot co dot jp 2010-07-14 12:24 ---
This is also the wrong result with MinGW gcc 3.4.5.
I'm expecting that all component of v will be 2500.
4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
worked fine.
This time, I did
$ grep -A11 specifics\[] gcc/opts.c
specifics[] =
{
{ optimizers, CL_OPTIMIZATION },
{ target, CL_TARGET },
{ warnings, CL_WARNING },
{ undocumented, CL_UNDOCUMENTED },
{ params, CL_PARAMS },
--- Comment #17 from sezeroz at gmail dot com 2010-07-14 14:02 ---
(In reply to comment #16)
This is also the wrong result with MinGW gcc 3.4.5.
I'm expecting that all component of v will be 2500.
4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
--- Comment #18 from sezeroz at gmail dot com 2010-07-14 14:05 ---
(In reply to comment #15)
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
This case fails with 4.4 on i686-linux too, printing 16, 16, 14, 14 instead of
16, 15, 14, 13 which 4.3 does.
--
--- Comment #3 from marc dot glisse at normalesup dot org 2010-07-14 14:08
---
Created an attachment (id=21199)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21199action=view)
extra testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
--- Comment #4 from marc dot glisse at normalesup dot org 2010-07-14 14:14
---
The patch (or another one committed recently) seems to have broken the attached
testcase (as you can see from the names, this comes from the same code),
including in C++98 mode. If it is unrelated, sorry for
--- Comment #6 from htl10 at users dot sourceforge dot net 2010-07-14
14:25 ---
4.3.5 also bootstrap4-lean alright (hit bug 40947 later with libjava).
--
htl10 at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2010-07-14 14:30
---
I can confirm the new testcase doesn't compile anymore. Let's re-open this PR
to be safe.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from htl10 at users dot sourceforge dot net 2010-07-14
14:44 ---
4.4.4 (built with 4.3.3) fails at stage 3 and 4 comparison.
Comparing stages 3 and 4
Bootstrap comparison failure!
./crtfastmath.o differs
make[2]: *** [compare3] Error 1
objdump -Dxzs
--- Comment #6 from paolo dot carlini at oracle dot com 2010-07-14 14:45
---
I can also confirm that r162158 accepted zut.cc and r162159 doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
Since at least revision 161984 (r158921 works), the test FM411 of the NIST
suite fails. The following reduced test shows the problem:
[macbook] f90/bug% cat FM411_red.f
PROGRAM FM411
I04 = 8
ENDFILE I04
READ (I04) IVON01
END
[macbook] f90/bug% gfc FM411_red.f
--- Comment #2 from pthaugen at gcc dot gnu dot org 2010-07-14 15:11
---
Created an attachment (id=21200)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21200action=view)
dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44932
--- Comment #3 from pthaugen at gcc dot gnu dot org 2010-07-14 15:12
---
Created an attachment (id=21201)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21201action=view)
dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44932
c++ -fno-rtti -O2 -fwhopr=24 -fuse-linker-plugin -pthread -fPIC ~/f?.ii
-fpermissive -fno-strict-aliasing -fshort-wchar
In file included from ../../../xpcom/glue/nsCOMPtr.h:512:0,
from :110:
../../../xpcom/glue/GenericModule.cpp: In member function ‘GetClassObject’:
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-14 15:37 ---
Created an attachment (id=21202)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21202action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-14 15:38 ---
Created an attachment (id=21203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21203action=view)
testcase 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-14 15:44 ---
Some remarks:
a) The note 9.63 is nonnormative - still one should try to follow it
b) Most of my compilers simply use , ifort uses /dev/pts/3 (for
stdin/out/err), and Portland uses the same as gfortran: stdin,
--- Comment #19 from hjl dot tools at gmail dot com 2010-07-14 15:52
---
(In reply to comment #15)
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
-- begin testcase --
// g++ -O -msse2 test.cpp
typedef long long __m128i __attribute__ ((__vector_size__
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-14 15:56 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-07-14 16:41
---
(In reply to comment #15)
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
I think the code in comment #15 is invalid and voilates C/C++ aliasing rules.
--
--- Comment #21 from pinskia at gcc dot gnu dot org 2010-07-14 16:44
---
(In reply to comment #20)
(In reply to comment #15)
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
I think the code in comment #15 is invalid and voilates C/C++ aliasing rules.
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-07-14 16:50
---
(In reply to comment #21)
Even if it did not voilate aliasing rules, the IR looks good:
The expansion looks incorrect though:
(insn 39 38 40 t.cc:55 (set (reg:DI 107)
(vec_select:DI (reg:V2DI 79 [ D.4999
--- Comment #6 from jason at gcc dot gnu dot org 2010-07-14 17:01 ---
Subject: Bug 44810
Author: jason
Date: Wed Jul 14 17:01:15 2010
New Revision: 162189
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162189
Log:
PR c++/44810
* g++.dg/torture/pr36745.C: Avoid
--- Comment #7 from jason at gcc dot gnu dot org 2010-07-14 17:02 ---
Fixed testcase.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rob1weld at aol dot com 2010-07-14 17:27 ---
Thanks for working on this guys,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-14 17:32 ---
I think we agree that the code is invalid. But I also would prefer a message
such as GCC 4.5 had:
At line 4 of file aa.f90 (unit = 8, file = 'fort.8')
Fortran runtime error: End of file
The commit causing this
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-14 17:42 ---
After PR 44773 has been fixed, we are back to things which failed before. Test
case which has no diagnostic (same as the one in comment 0 but with TARGET
attribute to force the creation of an array temporary)
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-14 17:57 ---
The original code has a line
REWIND I04
after
ENDFILE I04
I have removed it to reduce the test, but adding it does not change the runtime
error. Also I doubt that the NIST suite contains invalid
--- Comment #4 from pthaugen at gcc dot gnu dot org 2010-07-14 18:18
---
Based on the last post in the patch thread should the patch be committed so the
testsuite failures go away and this can be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-14 18:21 ---
(In reply to comment #2)
The original code has a line
REWIND I04
after
ENDFILE I04
I have removed it to reduce the test, but adding it does not change the
runtime
error. Also I doubt
Following the discussion in
http://gcc.gnu.org/ml/fortran/2010-07/msg00174.html
this is a split of a test case I had added to PR42385, taken from 43945, but it
does not quite belong there.
The problem is: the static resolution mechanism that is invoked when the type
is knonwn at compile time
--- Comment #1 from sfilippone at uniroma2 dot it 2010-07-14 18:33 ---
See attachment #21184
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44936
[reg...@gamow tmp420]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r162143-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-07-14 20:23
---
(In reply to comment #11)
I wonder if there is any overlap with this bug and PR29404/42308?
libiberty doesn't use $(toplevel_builddir)/gcc/site.exp, so there is no
direct connection, but libiberty/Makefile.in
--- Comment #11 from jyasskin at gmail dot com 2010-07-14 20:49 ---
Is this the same bug as PR 39284?
--
jyasskin at gmail dot com changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-14 21:43 ---
The test cases in comment 3 (attachment 21184) and comment 4 (attachment 20927)
are now tracked in PR 44936 - and fixed by the draft patch there.
The original test case (comment 0) still generates wrong code and the
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-14 21:45 ---
Draft patch: http://gcc.gnu.org/ml/fortran/2010-07/msg00176.html
Fixes the test cases in comment 2 (attachment 21184) and attachment 20927 (cf.
PR 42385 comment 4 and PR 43945 comment 19).
--
Why does it change the output of the compilation of certain programs? The
documentation implies strongly that it only affects the warnings produced. The
following program demonstrates this.
-
/* Authors: Florian Schanda and Martin Brain */
#include stdio.h
int main(int argc, char ** argv)
{
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-14 23:04 ---
-pedantic should not change the behavior of defined code. This code is
undefined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44939
When compiling a bootloader for the XMEGA128 (starting address 0x2), RAMPZ
is initialized to 2 in the __do_copy_data section. This has the effect that
any indirect register access will fail.
For example the following code extract will result in the register NOT being
set to 0xCB when RAMPZ
Command line:
$ gcc -O[123s] testcase.c
Compiler output:
$ gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:7:7: internal compiler error: RTL check: expected code 'mem', have
'reg' in emit_block_move_hints, at expr.c:1189
Unreduced testcase crashes with:
$ gcc -O rarpd.i
rarpd.c: In
--- Comment #1 from zsojka at seznam dot cz 2010-07-14 23:25 ---
Created an attachment (id=21204)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21204action=view)
reduced testcase (from iptraf sources)
Command line:
$ gcc -O pr44941.c
--
--- Comment #1 from jyasskin at gmail dot com 2010-07-15 00:34 ---
My current guess is that the bug is at parser.c:16741, at the end of
cp_parser_class_head():
DECL_SOURCE_LOCATION (TYPE_NAME (type)) = type_start_token-location;
This updates the template's location, but it doesn't
--- Comment #4 from changpeng dot fang at amd dot com 2010-07-15 01:50
---
Created an attachment (id=21205)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21205action=view)
Do not unroll pre and post loops
I did a quick test on polyhedron before and after applying the preliminary
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-07-15 01:56
---
Caused by my patch -r161020, will fix, subtle
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
On X86-64, the following code demonstrates how passing a long double as a fixed
argument causes corruption of the following variable arguments.
#include stdio.h
#include assert.h
#include stdarg.h
void test(int a, int b, int c, int d, int e, int f, int g, long double h, ...)
{
int i;
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:32
---
Created an attachment (id=21206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21206action=view)
Fix for this regression.
Tobias said:
Another question is why is the file marked as FORMATTED? READ (unit)
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:41
---
Subject: Bug 44934
Author: jvdelisle
Date: Thu Jul 15 03:40:56 2010
New Revision: 162203
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162203
Log:
2010-07-14 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:42
---
Subject: Bug 44934
Author: jvdelisle
Date: Thu Jul 15 03:42:29 2010
New Revision: 162204
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162204
Log:
2010-07-14 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:44
---
Fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from yottui at yahoo dot co dot jp 2010-07-15 03:45 ---
(In reply to comment #22)
Please file that as a different bug.
May I enter comment #15 as a new bug to Bugzilla?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Filing this as gcc 4.4.4 since that is the version of the docs I'm looking at,
however, we care about behavior from gcc 3.4 and onward.]
A major disagreement has developed inside the Linux kernel community about the
semantics that gcc imposes on volatile. One school of thought states that
Using gcc-4.5 (r162000) to build webkit, cc1plus slowly exhausted all my memory
(6gb + 6gb swap) and was OOM killed. Compiling the preprocessed file reduced
the problem to a quick (5 second) segfault.
--
Summary: g++ segfault with -fvisibility-inlines-hidden -O2 -fno-
--- Comment #1 from graham dot gower at gmail dot com 2010-07-15 05:12
---
Created an attachment (id=21207)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21207action=view)
preprocessed file from webkit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
--- Comment #2 from graham dot gower at gmail dot com 2010-07-15 05:13
---
g...@eye7:/tmp$ ~/oe2/tmp/cross/mipsel/bin/mipsel-oe-linux-g++ -c FrameLoader.ii
-fvisibility-inlines-hidden -O2 -fno-exceptions -fPIC
mipsel-oe-linux-g++: Internal error: Segmentation fault (program cc1plus)
77 matches
Mail list logo
