--- Comment #2 from daney at gcc dot gnu dot org 2007-06-20 07:11 ---
Created an attachment (id=13739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13739&action=view)
First patch attempt.
I think this patch fixes this bug. The test case looks better from my
cross-compiler. I wi
--- Comment #1 from boris at phidani dot be 2007-06-20 07:18 ---
got same problem with gcc 4.2.0 on suse linux 9.0:
I did:
/opt/gcc-4.2.0/configure --program-suffix=-4.2.0
then:
make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' bootstrap
Here is the la
--- Comment #10 from ubizjak at gmail dot com 2007-06-20 08:23 ---
Confirmed, configure gcc with --enable=checking=fold
--cut here--
typedef union
{
struct {int low, high;} s;
long long ll;
} DWunion;
long long
__muldi3 (long long u, long long v)
{
const DWunion uu = {.ll = u};
sra-bug.C (below) contains a function which stack-allocates a local struct
containing two small arrays. The function depends on SRA to eliminate repeated
memory accesses to the two arrays as it streams over a large, third array.
The performance of the executables resulting from
g++ -Wall -O3 -
svn revision:125876
cc -c -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP
-D_GLIBC
PP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -msse4a -DARCH_IS_IA32 -DARCH_IS_32BIT
-DHA
VE_MMX -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses
-I../ba
seclasses -IimgFilters -I../imgFilte
--- Comment #1 from jojelino at gmail dot com 2007-06-20 08:39 ---
Created an attachment (id=13740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13740&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
--- Comment #19 from jv244 at cam dot ac dot uk 2007-06-20 08:48 ---
(In reply to comment #17)
> Here is the fix which I am testing, basically instead of creating
> (typeof(array[0] "*")&array we create &array[lb]:
did this fix test OK ? Since it fixes the CP2K issue, I would hope that
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-06-20 08:52
---
(In reply to comment #19)
> did this fix test OK ? Since it fixes the CP2K issue, I would hope that it
> could be posted for review soon.
The patch is OK to commit along with a testcase from this PR.
--
htt
--- Comment #11 from ubizjak at gmail dot com 2007-06-20 08:55 ---
backtrace:
(gdb) bt
#0 fancy_abort (file=0x8a02980 "../../gcc-svn/trunk/gcc/fold-const.c",
line=12775, function=0x8a021be "fold_checksum_tree") at
../../gcc-svn/trunk/gcc/diagnostic.c:656
#1 0x08207fc1 in fold_checksum
--- Comment #12 from ubizjak at gmail dot com 2007-06-20 08:59 ---
(In reply to comment #11)
> backtrace:
(gdb) frame 4
#4 0x0823b9f7 in fold_convert (type=0xb7eb5360, arg=0xb7f5b138) at
../../gcc-svn/trunk/gcc/fold-const.c:2281
(gdb) p debug_tree (arg)
unit size
ali
--- Comment #13 from ubizjak at gmail dot com 2007-06-20 09:03 ---
svn blame of tree-chrec.c
114057rakdver /* If we cannot propagate the cast inside the chrec, just
keep the cast. */
114057rakdver keep_cast:
100718 spop res = fold_convert (type, chrec);
97607 ebotca
/* { dg-do compile } */
/* { dg-options "-O2 -m32 -mtune=generic" } */
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
extern int get_src_stride(void);
extern int get_dst_stride(void);
void
foo (uint32_t *pSrc, uint32_t *pDst, uint16_t width, uint16_t height)
{
uint32_t *ds
--- Comment #13 from jakub at gcc dot gnu dot org 2007-06-20 09:24 ---
Fixed in SVN, the performance regression caused by PR25550 patch is still
present though.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-06-20 09:41
---
I can reproduce what you see, nor make any sense of the instructions comparing
the outputs: when I do what you indicate, all I see in the output is a
namelist-type of scalar values:
&INPUT
IDATM= 4,
AM
--- Comment #3 from ro at gcc dot gnu dot org 2007-06-20 09:44 ---
I observe the same problem (also affecting gnu-xml.lo) on
alpha-dec-osf{4.0f,5.1b}.
VM consumption for org-omg.lo is at 1.5 GB now, a machine with 768 MB physical
memory crawls along for hours compiling the file. I had
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-20 09:46 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-20 09:48 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #2 from rask at sygehus dot dk 2007-06-20 11:00 ---
Does it work for you if you apply patch 3 from bug other/32154?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12019
--- Comment #10 from bonzini at gnu dot org 2007-06-20 11:13 ---
DJ, do you think this patch is ok?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #11 from schwab at suse dot de 2007-06-20 11:32 ---
Also broken on ia64.
--
schwab at suse dot de changed:
What|Removed |Added
GCC target triplet|powerpc64-*-
Minimal program in test.c:
int main() {}
Compile:
# /var/scratch/lionelb/usr/gcc-4.1.2/bin/gcc -v test.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /var/scratch/lionelb/usr/src/gcc-4.1.2/configure
--prefix=/var/scratch/lionelb/usr/gcc-4.1.2 --enable-languages=c,c++,f
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-20 12:15 ---
This does the job by detecting the generation of a temporary. In this case the
loop is zero based but the calculated value for the position does not reflect
this.
I'll have a think about whether or not this is the cle
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-20 12:28
---
Don't use fold checking, it's broken.
*** This bug has been marked as a duplicate of 20623 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-20 12:28
---
*** Bug 32024 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
I. CODE SAMPLE
#include
#define SHOWBUG
class A;
class F
{
public:
F(A *x, void (A::*y)()) : m_x(x), m_y(y) {}
void operator()();
private:
A *m_x;
void (A::*m_y)();
};
#ifdef SHOWBUG
void F::operator()() { (m_x->*m_y)(); }
#endif
class A
{
public:
void
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
GCC ta
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 12:55 ---
> The page http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts says libm is being
> replaced with libmpfr.
No it does not say that, please stop reading the changes page incorrectly.
What it is saying is that inside th
--- Comment #3 from richard at codesourcery dot com 2007-06-20 12:56
---
Subject: Re: [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
"daney at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> I don't really like the patch that much though. It forces $gp to be
> loaded in a nonl
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 12:57 ---
wrapper const &w
You are passing via reference which does not break SRA, just changes the ABI
and such.
This is a very very hard problem to solve without the whole program.
I wondering if I should close it as won'
/gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/gfortran -c -o
nmr.fppized.o-O2 -DSPEC_CPU_LP64 -ffixed-form nmr.fppized.f
nmr.fppized.f: In function 'oneints':
nmr.fppized.f:617: internal compiler error: in build2_stat, at tree.c:3074
Please submit a full bug report,
w
Configure gcc like this:
$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java
The attached file fails to compile:
$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In functi
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-20 13:20 ---
Created an attachment (id=13741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13741&action=view)
testcase
Testcase that fails with -O2 -ffixed-form
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-20 13:21 ---
#0 fancy_abort (
file=0xe87fc8 "/space/rguenther/src/svn/pointer_plus/gcc/tree.c",
line=3074, function=0xe893df "build2_stat")
at /space/rguenther/src/svn/pointer_plus/gcc/diagnostic.c:656
#1 0x000
Configure gcc like this:
$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java
The attached file fails to compile:
$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In functi
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:21 ---
Created an attachment (id=13742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13742&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
Configure gcc like this:
$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java
The attached file fails to compile:
$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In functi
--- Comment #21 from pinskia at gmail dot com 2007-06-20 13:22 ---
Subject: Re: [4.3 Regression] Miscompilation with -O1
> did this fix test OK ? Since it fixes the CP2K issue, I would hope that it
> could be posted for review soon.
I can't get to testing this patch fully until Friday
--- Comment #2 from rask at sygehus dot dk 2007-06-20 13:24 ---
*** Bug 32420 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:24 ---
*** This bug has been marked as a duplicate of 32418 ***
--
rask at sygehus dot dk changed:
What|Removed |Added
--
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:25 ---
*** This bug has been marked as a duplicate of 32418 ***
--
rask at sygehus dot dk changed:
What|Removed |Added
--
--- Comment #3 from rask at sygehus dot dk 2007-06-20 13:25 ---
*** Bug 32419 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
Testcase:
int f(int **restrict a, int ** restrict b)
{
int i;
for(i= 0;i<32;i++)
a[i] = b[i] + 1;
}
--
Summary: [4.3 Regression] -ftree-vectorize -msse2 ICEs in
build2_stat when vectorizing POINTER_PLUS_EXPR
Product: gcc
Version: 4.3.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 13:34 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #10 from rask at sygehus dot dk 2007-06-20 13:41 ---
I'm adding the m32c back because the testcase for bug 32069 fails with
optimization turned on:
$ ./xgcc -B./ /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c -S -dp -o
/dev/null -O1
/n/08/rask/src/gcc/gcc/testsuite/gcc.dg
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 13:44 ---
*** This bug has been marked as a duplicate of 15684 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-20 13:44
---
*** Bug 32416 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from rask at sygehus dot dk 2007-06-20 13:52 ---
Ah, notice the mismatch in register sizes between prologue and epilogue:
(insn/f 59 5 60 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:5 (parallel
[
(set/f (mem:HI (plus:HI (reg/f:HI 8 sp)
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-06-20 13:53
---
It would be nice if a fortraner could make the testcase not output to
stdout/err
but to /dev/null instead.
open(6,'/dev/null')
didn't work for me ;)
Just to make a testcase suitable for the testsuite.
--
ht
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-06-20 13:55
---
stupid me. open(6,file='/dev/null') works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
--- Comment #24 from jv244 at cam dot ac dot uk 2007-06-20 14:03 ---
(In reply to comment #22)
> It would be nice if a fortraner could make the testcase not output to
> stdout/err
> but to /dev/null instead.
>
> open(6,'/dev/null')
>
> didn't work for me ;)
>
> Just to make a testcase
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-20 14:03
---
Here is a testcase which also checks the resulting array is correct:
MODULE TEST
CONTAINS
PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3
CHARACTER(LEN=1000),
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-06-20 14:05
---
(In reply to comment #25)
> Here is a testcase which also checks the resulting array is correct:
oh s/eq/ne/ I did not test mine and it is 11pm and I have to get up early in
the morning.
--
http://gcc.gnu.org/
--- Comment #27 from rguenther at suse dot de 2007-06-20 14:07 ---
Subject: Re: [4.3 Regression] Miscompilation with -O1
On Wed, 20 Jun 2007, jv244 at cam dot ac dot uk wrote:
>
>
> --- Comment #24 from jv244 at cam dot ac dot uk 2007-06-20 14:03 ---
> (In reply to comment
--- Comment #11 from dir at lanl dot gov 2007-06-20 14:15 ---
It is easy to make this test case to a completely legal FORTRAN program.
Keeping the BUG and making it into a completely legal FORTRAN program is more
difficult, but likely possible. However, the problem that gfortran is havin
When reading malformed floats like "3.14e" using operator>>, it appears like
the e character is removed from the input stream but the fact that the stream
state does not signal that something went wrong.
$ cat lcast.cpp
#include
#include
using namespace std;
int main()
{
stringstream buf;
gcc.c-torture/compile/20020604-1.c ICEs if compiled with
-O3 -fomit-frame-pointer -mcpu=5485.
Here is a reduced testcase min.c.
unsigned int
foo (unsigned int n)
{
float c[8192];
unsigned int i;
unsigned int d = 0;
union {
float r;
unsigned int i;
} e;
for (i = 0; i < n; i++)
gcc.c-torture/compile/20050303-1.c FAILs like so:
$ ./cc1 -quiet -mcpu=5485 20050303-1.c
20050303-1.c: In function 'crc':
20050303-1.c:10: error: unable to generate reloads for:
(insn 8 7 9 3 20050303-1.c:8 (parallel [
(set (cc0)
(compare (reg:DI 30 [ D.1560 ])
Minimal program file hello.cpp:
#include
int main()
{
std::cout << "hello world\n";
return 0;
}
Compiled as follows:
# /var/scratch/lionelb/usr/gcc-4.2.0/bin/g++ -v -static-libgcc -O hello.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /var/scratch/
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:27 ---
And this is not a bug, you need to setup LD_LIBRARY_PATH correctly to point to
where the latest version of libstdc++ reside which means where
--enable-version-specific-runtime-libs puts the library. Note -static-lib
gcc.c-torture/execute/mayalias-2.c FAILs like so:
$ ./cc1 -quiet -O1 -g -mcpu=5485 mayalias-2.c
mayalias-2.c:2: internal compiler error: in splice_child_die, at
dwarf2out.c:5593
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instruct
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:30 ---
*** This bug has been marked as a duplicate of 28834 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-20 14:30
---
*** Bug 32426 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
gcc.dg/invalid-call-1.c FAILs like so:
$ ./cc1 -quiet -O2 invalid-call-1.c
invalid-call-1.c: In function 'foo':
invalid-call-1.c:16: warning: function called through a non-compatible type
invalid-call-1.c:16: note: if this code is reached, the program will abort
invalid-call-1.c:18: internal compi
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:37 ---
This is most likely the scheduler crashing.
The code is valid but undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from tdragon at tdragon dot net 2007-06-20 14:44 ---
Created an attachment (id=13743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13743&action=view)
Better testcase; compile with -O2, use with alias_main.c
Compiling this file with -O2 and linking with the object f
--- Comment #7 from tdragon at tdragon dot net 2007-06-20 14:46 ---
Created an attachment (id=13744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13744&action=view)
Better testcase pt.2; use with alias1.c
Compile this file with any or no additional options as desired; linking wit
--- Comment #8 from tdragon at tdragon dot net 2007-06-20 14:52 ---
Not seeing any further action or confirmation on this yet, I've gone ahead and
created a simpler testcase. It's plain that, when using -O2, line 14 of
alias1.c is skipped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-20 14:57
---
Subject: Bug 32140
Author: rguenth
Date: Wed Jun 20 14:57:10 2007
New Revision: 125886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125886
Log:
2007-06-20 Andrew Pinski <[EMAIL PROTECTED]>
Rich
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-20 14:59
---
Fixe.d
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from lionelb dot nospam at gmail dot com 2007-06-20 15:01
---
(In reply to comment #1)
> And this is not a bug, you need to setup LD_LIBRARY_PATH correctly to point
> to where the latest version of libstdc++ reside which means where
> --enable-version-specific-runtime-lib
French translations for strict aliasing -related warnings are a bit odd, here
is a patch.
--
Summary: odd french translation of strict aliasing -related
warnings
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: n
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-06-20
15:09 ---
Created an attachment (id=13745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13745&action=view)
better translations for strict aliasing -related warnings
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-20 15:12 ---
Confirmed.
struct barstruct { char const* some_string; };
void changethepointer(struct barstruct**);
void baz()
{
struct barstruct bar1;
struct barstruct* barptr = &bar1;
changethepointer(&
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2007-06-20
15:15 ---
Created an attachment (id=13746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13746&action=view)
yet better translation
Sorry for reposting a patch so soon, but someone told me "enfreindre" is bette
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-06-20 15:16
---
trunk has the same problem, but different constraints:
Constraints:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
barptr = &bar1
barptr.0_1 = barptr
Points-to sets
NULL = { }
ANYTHING = { ANYTHI
A variety of options prepare some additional space on the stack. It isn't
optimized when stack isn't used. Those options are:
version options
3.3 -fpic -fPIC -mabi=altivec
4.1.2 -fpic -fPIC -fpie -fPIE -maltivec
4.2.0 -fpic -fPIC -fpie -fPIE -maltivec
4.3-pre -fpic -fPIC -fpie -fPIE
--- Comment #8 from jv244 at cam dot ac dot uk 2007-06-20 15:20 ---
this really seems a duplicate of PR 31688, so I'll close this PR and reopen
31688. If one wants to get the error message mentioned in comment #6, I
suggest to open a new PR.
*** This bug has been marked as a duplicate
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-20 15:20 ---
*** Bug 31683 has been marked as a duplicate of this bug. ***
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
---
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-20 15:25 ---
Tobias, could you reopen this bug (I can't). This is different from PR 5035.
Whereas PR 5035 warns about variables present in the users code, these warnings
come from frontend generated variables (i.e. offset.7 is nowher
--- Comment #1 from lionelb dot nospam at gmail dot com 2007-06-20 15:31
---
(In reply to comment #0)
I can work around this by symlinking:
to ../lib64/libgcc_s.so from
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2
and:
to ../../lib/libgcc_s.so from
/var/s
--- Comment #11 from tdragon at tdragon dot net 2007-06-20 15:35 ---
Not sure if this is relevant or just GCC working differently on my target
system, but I don't encounter the bug using -fstrict-aliasing, or in fact using
individually the entire set of options under -O and -O2 on
http:/
--- Comment #12 from dominiq at lps dot ens dot fr 2007-06-20 15:43 ---
With the following changes to the original code:
[karma] f90/bug% diff -u pr32393.f pr32393_mod.f
--- pr32393.f Mon Jun 18 16:46:48 2007
+++ pr32393_mod.f Wed Jun 20 17:40:03 2007
@@ -16,7 +16,7 @@
c+--
--- Comment #1 from pcarlini at suse dot de 2007-06-20 15:53 ---
This is a known behavior (we even have testcases for it): the issue is that
(for C++03 at least) we definitely want consistency with "C" scanf, and the
latter in many implementations behaves "incorrectly". See this glibc PR
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
10.8000E+01
row 20.9000E+01 0.1000E+02
row 30.1100E+02 0.1200E+02 0.1300E+02
Thus which compiler is right? Are all right? What exactly is the bug / expected
output? Is it fixed meanwhile as I get for -O3 w/o -ffast-math the same output
as for -O0?
Is it platform dependent? I us
--- Comment #5 from marcus at jet dot franken dot de 2007-06-20 16:21
---
i have tested it and it works.
(i have also fixed the Wine code ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
--- Comment #1 from jakub at gcc dot gnu dot org 2007-06-20 16:23 ---
There is nothing special about ST_OMP_THREADPRIVATE here, the Fortran parser
as whole behaves this way.
You get the same if you write say
subroutine test
integer :: i
i = 1
common /myi/ i
end subroutine test
etc.
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-20 16:25 ---
> Tobias, could you reopen this bug (I can't). This is different from PR 5035.
> Whereas PR 5035 warns about variables present in the users code, these
> warnings
> come from frontend generated variables
Well, for th
--- Comment #11 from mueller at gcc dot gnu dot org 2007-06-20 16:27
---
Subject: Bug 31806
Author: mueller
Date: Wed Jun 20 16:27:23 2007
New Revision: 125887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125887
Log:
2007-06-20 Dirk Mueller <[EMAIL PROTECTED]>
PR c+
--- Comment #11 from mueller at gcc dot gnu dot org 2007-06-20 16:27
---
Subject: Bug 31809
Author: mueller
Date: Wed Jun 20 16:27:23 2007
New Revision: 125887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125887
Log:
2007-06-20 Dirk Mueller <[EMAIL PROTECTED]>
PR c+
--- Comment #12 from mueller at gcc dot gnu dot org 2007-06-20 16:28
---
Fixed.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from mueller at gcc dot gnu dot org 2007-06-20 16:28
---
Fixed
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
program test
implicit none
real, allocatable :: bar(:,:)
print *, bar
end program test
NAG f95:
Error: foo.f90, line 5: ALLOCATABLE array BAR used but never ALLOCATEd
g95:
Warning (147): Variable 'bar' at (1) is used and never allocated
--
Summary: Warn about never allocated vari
--- Comment #2 from rob1weld at aol dot com 2007-06-20 16:31 ---
The failure in gcc.c-torture/execute/20050316-2.c is still present.
The failure in
/root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.c
was broken, prior to and, on 20070611, fixed before 20070613
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-20 16:39 ---
> There is nothing special about ST_OMP_THREADPRIVATE here, the Fortran parser
> as whole behaves this way.
Sorry for missing that.
> what perhaps could be done is e.g. adding something like
> case_decl:
> gfc_erro
--- Comment #2 from rob1weld at aol dot com 2007-06-20 16:46 ---
This bug report is titled 'GCC Collect2 adds extra "-lm"'s to link commands
even when not linking with "-lm".'.
The page http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts says:
The GCC middle-end has been integrated with
I have configured GCC this way:
$ /n/08/rask/src/gcc/configure --target m68hc11-unknown-none --disable-gdb
--disable-nls --with-newlib
The attached testcase causes an ICE:
$ ./xgcc -B./ ~/muldi3.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/n/08/ras
1 - 100 of 218 matches
Mail list logo
