--- Comment #2 from brian at dessent dot net 2008-09-30 04:41 ---
Subject: Re: -fstrict-aliasing causes omission of double-to-float
conversion
I can confirm that the failure with 4.1.2, however 4.2.4, 4.3.1, and 4.4
all work fine. 4.1 with -fno-tree-salias also works.
Unfortunately
--- Comment #1 from dhatch at ilm dot com 2008-09-30 03:15 ---
Created an attachment (id=16430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16430&action=view)
BUG.cpp: test program to reproduce bug 37679
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37679
The program which will be attached
demonstrates a case where,
when the -fstrict-aliasing optimization is turned on,
the result of the final one of 6 double-to-float conversions
does not get written to memory as it should.
According to valgrind (memory debugging tool), the target memory
gets left un
--- Comment #5 from regehr at cs dot utah dot edu 2008-09-30 03:04 ---
(In reply to comment #3)
> The testcase is invalid, signed integer overflow is undefined behavior.
It still crashes when -fwrapv or -ftrapv is added to the command line.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-30 01:41 ---
Actually my reduced testcase still fails for me on the trunk as of
Mon Sep 29 21:29:02 UTC 2008 (revision 140765)
Stage1's gcc is still fine.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
This is an ia64 performance and code size regression. Consider the following
function:
void sump(int *a, int *b, int *c, int len){
int i;
for(i = 0; i < len; i++){
*a++ = *b++ + *c++;
}
}
GCC 3.4.6 generated the following code. Note that the memory accesses use the
post-increment addr
--- Comment #15 from hjl at gcc dot gnu dot org 2008-09-30 00:38 ---
Subject: Bug 37535
Author: hjl
Date: Tue Sep 30 00:36:48 2008
New Revision: 140775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140775
Log:
2008-09-29 Vladimir Makarov <[EMAIL PROTECTED]>
PR middle
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-30 00:16 ---
Why isD::operator C() weird? The operator is still a template
so is the type C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37677
--- Comment #1 from meheff at gcc dot gnu dot org 2008-09-30 00:10 ---
(In reply to comment #0)
> The following code produces a bad mangled name (or at least a mangled name
> that
> c++filt cannot handle):
>
> template class C { public: C(); };
> class D
> {
> public:
> template
>
The following code produces a bad mangled name (or at least a mangled name that
c++filt cannot handle):
template class C { public: C(); };
class D
{
public:
template
operator C() { return C(); }
};
C foo(D* p) { return *p; }
The final line produces the symbol ZN1Dcv1CIT_EIbEEv. c++filt canno
--- Comment #23 from sherpya at netfarm dot it 2008-09-29 23:22 ---
a printf in the code for ff_cos_16 causes the compiler to align the var,
but at this point it crashes in another place using sse code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
$ nm ffmpeg_g.exe |grep ff_cos_16
00e55c94 B _ff_cos_16
00e185d4 B _ff_cos_16384
not aligned :(
gcc version 4.3.3 20080929 (prerelease) (Sherpya)
GNU assembler version 2.18.91 (i686-pc-mingw32) using BFD version (GNUBinutils)
2.18.91.20080917
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-29 22:46 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from burnus at gcc dot gnu dot org 2008-09-29 22:06 ---
Created an attachment (id=16429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16429&action=view)
Reduced test case which is failing with the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-29 21:45 ---
So maybe someone is violating the PPC ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-29 21:44 ---
CR3 is a caller save register just like R31.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-29 21:40 ---
IIRC cr3 is a volatile conditional register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
--- Comment #13 from burnus at gcc dot gnu dot org 2008-09-29 21:39 ---
> Somehow the patch is not enough to compile program
Actually the situation is worse -- the failure occurs now much earlier:
w/ patch: Failure in errormodM.f90 (43th compiled file)
w/o patch: Failure in cmndtypeM.
--- Comment #6 from sparky at pld-linux dot org 2008-09-29 21:36 ---
I was trying to isolate the code which triggers this bug, but seems like the
code must be very complex to do so. Nevertheless I found exactly how the
resulting assembler code is broken.
Note: files gsignal.s and gsignal
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-29 21:25 ---
Subject: Bug 37669
Author: pinskia
Date: Mon Sep 29 21:23:52 2008
New Revision: 140765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140765
Log:
2008-09-29 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-29 21:24 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-29 21:14 ---
(In reply to comment #3)
> The testcase is invalid, signed integer overflow is undefined behavior.
The code is semantically valid but just runtime undefined ...
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-29 21:12 ---
It fails with "GNU C (GCC) version 4.4.0 20080926 (experimental) [trunk
revision 140710] (i386-apple-darwin8.11.1)" But not with a stage1 compiler so
...
I am going to add this testcase so we don't get the wrong cod
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-29 21:10 ---
Hmm, maybe this was one of the miscompiling that is happening with IRA ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
--- Comment #9 from dominiq at lps dot ens dot fr 2008-09-29 20:25 ---
Although I am not familiar with the gfortran code, gfc_array_size (mold, &tmp)I
think the reason why gfortran.dg/transfer_array_intrinsic_4.f90 fails with the
patch in comment #6,
is because gfc_array_size (mold, &tmp
--- Comment #21 from brian at dessent dot net 2008-09-29 20:06 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
This is an example of what I'm talking about: the bar() function is
optimized away to simply "return 0" because the compiler assu
--- Comment #20 from sherpya at netfarm dot it 2008-09-29 19:33 ---
align testcase looks ok, but anyway I'm mainly interested to have code aligned
to 16. volatile around variables is not enough in my test program.
Nick's testcase is ok even on (local-only align) patched gcc 4.2
I've so
--- Comment #5 from jdemeyer at cage dot ugent dot be 2008-09-29 19:22
---
Created an attachment (id=16428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16428&action=view)
Unified testcase
This testcase exhibits the problem on i386, x86_64, powerpc and powerpc64 using
preprocess
--- Comment #19 from dannysmith at users dot sourceforge dot net
2008-09-29 18:43 ---
Created an attachment (id=16427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427&action=view)
Nick's aligned common testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
As it stands one cannot build a working gcj unless one first gets ecj.jar which
is prebuilt with some other javac. It would be great if there was a way to
build a fully working gcj with ecj without needing this extra step.
--
Summary: Ability to bootstrap a fully working gcj without n
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC|paolo at gcc dot gnu dot org|
AssignedTo|bkoz at gcc dot gnu dot org |paolo dot carli
--- Comment #18 from brian at dessent dot net 2008-09-29 17:58 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
The __to_xstring error is PR37522. You should still be able to
bootstrap with --enable-languages=c for the purposes of testing t
--- Comment #2 from pardo at google dot com 2008-09-29 17:48 ---
How can I prevent relative motion? I tried adding a "memory" constraint to all
asms, but they are still moved past each other. I expected any common
constraint would keep them from crossing.
(Adding "volatile" to all asm
--- Comment #11 from paolo dot carlini at oracle dot com 2008-09-29 17:24
---
Ok, no problem, thanks for your quick feedback. I'll see what I can do...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
--- Comment #10 from bkoz at redhat dot com 2008-09-29 17:17 ---
Sorry P, I have not paid attention to this. I am not likely to work on it this
week, so if you want to work on it feel free.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
--- Comment #17 from sherpya at netfarm dot it 2008-09-29 16:30 ---
with both patches I can achieve align 16
align > 16 on globals still fails
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
the program is:
#include
#include
#include
static int lo
--- Comment #16 from sherpya at netfarm dot it 2008-09-29 15:40 ---
Created an attachment (id=16426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16426&action=view)
lcomm + alignment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #15 from sherpya at netfarm dot it 2008-09-29 15:39 ---
I also got the error on the first patch, gcc 4.4 from svn, binutils
2.18.91.20080917
I still have problems with 2.19 binutils snapshots (unable to correctly create
and link dll)
unfortunately the current gcc svn does no
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
CC||bergner at gcc dot gnu dot
|
--- Comment #2 from ro at gcc dot gnu dot org 2008-09-29 15:14 ---
Both patches have been checked in, so closing as fixed.
(We're back at PR bootstrap/36851 now, though.)
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
---
On Linux/ia32, I got
FAIL: gcc.dg/torture/pr36891.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr36891.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr36891.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/pr36891.c -O3 -fomit-frame-pointer (test for excess
errors)
FAIL: gc
--- Comment #5 from schwab at suse dot de 2008-09-29 14:52 ---
This is causing miscompilation of the stage2 ada compiler.
fatal error: system.ads is incorrectly formatted
unrecognized or incorrect restrictions pragma: No_Implicit_Dynamic_Code
compilation abandoned
make[3]: *** [ada/ada.
--- Comment #9 from spop at gcc dot gnu dot org 2008-09-29 14:50 ---
Subject: Re: [graphite] Disconnecting exit edge in process of code generation
> Commit 140746 should have fixed Bug 3. Can you confirm this?
This is a side effect of your patch. This bug is not yet fixed, and
the pa
--- Comment #8 from sebpop at gmail dot com 2008-09-29 14:46 ---
Subject: Re: [graphite] SCoP detection splits bbs / Define SCoPs with single
entry and exit edge
> --- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14
> ---
> Committed SVN 140746.
I see that in
> --- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14
> ---
> Committed SVN 140746.
I see that in http://gcc.gnu.org/viewcvs?view=rev&revision=140746
you forgot to include in the changelog a line like this:
PR tree-optimization/37372
that would have automatically includ
--- Comment #9 from paolo dot carlini at oracle dot com 2008-09-29 14:36
---
Benjamin, are you actively taking care of this issue?
Otherwise, I can have a look, really we should have the unordered containers
working fine in debug-mode too.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from hadmanysons at gmail dot com 2008-09-29 14:36 ---
That worked all right. Am i just stupid or was there some change to the gcc
package I was unaware of, because gcc used to compile c++ code just fine (at
least in the older version of Fedora and as old as RedHat 6.2), t
--- Comment #2 from ciobi at inbox dot com 2008-09-29 14:30 ---
Sorry. The reason I said that the '0' flag was not actually ignored was that I
was sure that without it the padding would be done with spaces rather than '0'.
I guess some time ago I was using a compiler where the only way
--- Comment #8 from paolo dot carlini at oracle dot com 2008-09-29 14:17
---
*** Bug 37673 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-29 14:17
---
Thanks for your nice, encouraging words. We don't need duplicate reports,
thanks.
*** This bug has been marked as a duplicate of 32254 ***
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #14 from nickc at redhat dot com 2008-09-29 14:16 ---
Hi Guys,
I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
system or a system in which I can bootstrap mingw32. I th
--- Comment #13 from nickc at redhat dot com 2008-09-29 14:13 ---
Created an attachment (id=16425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425&action=view)
Revised patch with correct section switching
--
nickc at redhat dot com changed:
What|Removed
--- Comment #6 from ivranos at freemail dot gr 2008-09-29 13:55 ---
The bug reports you are mentioning combined with 35353
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353), means that the locales
implementation of GCC is a mess.
I think the proper solution is to fix the locale proble
--- Comment #2 from rlnaff at usgs dot gov 2008-09-29 13:54 ---
Subject: Re: compiler Segmentation fault
This was an experiment on the combined usage of Open MP and MPI, and may
not be feasible. However, that the compiler would simply fail... R. Naff
pinskia at gcc dot gnu dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-29 13:37
---
Given the problem you are reporting, the issue is definitely that either the
GNU locale model has not been selected at build time, or the localedata is not
available, please refer to 32254, for example, or many
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-29 13:37
---
*** Bug 37673 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-29 13:28 ---
The testcase is invalid, signed integer overflow is undefined behavior.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from ivranos at freemail dot gr 2008-09-29 13:27 ---
(In reply to comment #2)
> Target? Named locales are supported *only* on GNU/Linux systems.
Ubuntu 8.04 x86.
I am learning the QT package, and for example its QString provides a
toStdString() function that returns a
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-29 13:23 ---
Can't reproduce with current SVN, neither the reduced nor original testcase, on
x86_64, i?86, ppc and ppc64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
--- Comment #8 from grosser at gcc dot gnu dot org 2008-09-29 13:21 ---
Commit 140746 should have fixed Bug 3. Can you confirm this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
--- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14 ---
Committed SVN 140746.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
S
With the patch for PR37535 applied to mainline GCC the bootstrap still fails
due to a miscompilation. The problem is that r52 is assigned to r6 what
collides with an INSN loading r6 with a parameter for a CALL.
I think the problem is created in ira_flattening. Allocno a3 is a parent of
a87. For
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-29 12:48
---
*** This bug has been marked as a duplicate of 32254 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-29 12:48
---
*** Bug 37673 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-29 11:46
---
Target? Named locales are supported *only* on GNU/Linux systems.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #1 from ivranos at freemail dot gr 2008-09-29 11:37 ---
Created an attachment (id=16424)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16424&action=view)
The produced .ii file from code (2.)
The produced .ii file from code (2.) compiled with the options:
g++ -ansi -pe
Programs fail to execute with a runtime error when locale is set.
The following codes fail both for english and greek (haven't checked with other
locales) with the run-time error:
"terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale n
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-29 10:44
---
Indeed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #12 from burnus at gcc dot gnu dot org 2008-09-29 10:25 ---
Somehow the patch is not enough to compile program (see tar.gz / attachment
16266):
gfortran -c syskindsM.f90 formatbankM.f90 charutilM.f90 tinyisetM.f90
timestampmodM.f90 errelmntM.f90 errstackM.f90 debugmodM.f90 p
--- Comment #4 from janus at gcc dot gnu dot org 2008-09-29 09:40 ---
Updated patch: http://gcc.gnu.org/ml/fortran/2008-09/msg00447.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
70 matches
Mail list logo
