îÅÖÎÙÊ ÑÚÙÞÏË ÌÁÓËÁÅÔ ËÉÓËÕ
http://www.calculi15093.chat.ru
Hello Jack,
On 21 Nov 2008, at 18:35, Jack Howarth wrote:
On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
When 'make checking', I conventionally move the built libgcc_s.
1.dylib
and libgcc_s.10.4.dylib to one side prior to testing (so that the
Apple-supplied system version is used).
Hello Richard,
On Sun, Nov 23, 2008 at 05:14:27PM +, Richard Sandiford wrote:
Richard Sandiford [EMAIL PROTECTED] writes:
Manuel Lauss [EMAIL PROTECTED] writes:
Admittedly my understanding of mips assembly is not yet very advanced, am I
missing something or is this a bug?
Well,
2008/11/21 Daniel Jacobowitz [EMAIL PROTECTED]:
No, there's nothing wrong with this. You can even use multiple models
in the same executable for the same symbol. The linker will take care
of everything necessary.
For instance, the executable's TLS block is at a fixed offset from the
DTV
David Edelsohn wrote:
On Thu, Nov 20, 2008 at 7:56 AM, Diego Novillo [EMAIL PROTECTED] wrote:
This option has been problematic and does not seem to be well
maintained. In terms of usefulness, it would also be worth
implementing as a gimple pass, ideally in IPA mode. I propose that we
remove
Paul Brook wrote:
foo (argv[0]);
I'd say it's a broken test then.
It's a broken program, in full generality.
DJ, you could fix this either by checking argc != 0 in the test, or by
adding an effective-target condition that the test be run only on
targets that pass argv[0]. I think
Mark Mitchell [EMAIL PROTECTED] writes:
However, I think an even better fix is just to hard-code the string and
make it volatile. Presumably, the use of argv[0] here is just to keep
the compiler from optimizing the program away. So, I suggest doing
something like:
volatile char *x =
On Mon, Nov 24, 2008 at 12:23, Mark Mitchell [EMAIL PROTECTED] wrote:
David Edelsohn wrote:
It currently is broken on many platforms. Why not remove it now? What is
the purpose of keeping a pass that does not work correctly and developers
cannot use?
I agree with David.
Works for me too.
Andreas Schwab wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
However, I think an even better fix is just to hard-code the string and
make it volatile. Presumably, the use of argv[0] here is just to keep
the compiler from optimizing the program away. So, I suggest doing
something like:
Mark Mitchell [EMAIL PROTECTED] writes:
Andreas Schwab wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
However, I think an even better fix is just to hard-code the string and
make it volatile. Presumably, the use of argv[0] here is just to keep
the compiler from optimizing the program
On Mon, Nov 24, 2008 at 03:27:55PM +0100, Joel Porquet wrote:
And the related reloc symbols are:
5ffe14b0 0026 R_MIPS_TLS_DTPMOD
5ffe14b8 0026 R_MIPS_TLS_DTPMOD
Still, is R_MIPS_TLS_DTPMOD a correct symbol ?
In the document you wrote about NPTL for mips
How about this?
--- gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36321.c 2008-07-23
00:21:31.0 -0400
+++ ./pr36321.c 2008-11-24 13:46:04.0 -0500
@@ -17,7 +17,9 @@
}
+static char * volatile argp = pr36321.x;
+
int main(int argc, char **argv)
{
- foo (argv[0]);
+ foo
DJ Delorie wrote:
How about this?
OK.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
OK.
Thanks, committed.
Manuel Lauss [EMAIL PROTECTED] writes:
On Sun, Nov 23, 2008 at 05:14:27PM +, Richard Sandiford wrote:
Richard Sandiford [EMAIL PROTECTED] writes:
Manuel Lauss [EMAIL PROTECTED] writes:
Admittedly my understanding of mips assembly is not yet very advanced, am
I
missing something or
Timo Kreuzer wrote:
I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
codes to mark the code positions where the try block starts / ends and
of the except landing pad. The emitted .eh_frame section is parsed after
linking and converted into Windows compatible unwind info /
--- Comment #1 from jakub at gcc dot gnu dot org 2008-11-24 09:01 ---
Smaller testcase:
static inline int
f1 (int si1, int si2)
{
return si2 == 0 ? si1 : si1 / si2;
}
static inline unsigned long long
f2 (unsigned long long ui1, unsigned long long ui2)
{
return ui1 % ui2;
}
--- Comment #1 from schwab at suse dot de 2008-11-24 09:06 ---
*** Bug 38246 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
--- Comment #1 from schwab at suse dot de 2008-11-24 09:06 ---
*** This bug has been marked as a duplicate of 38243 ***
--
schwab at suse dot de changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-24 10:07 ---
Y is also not a template-id (?)
Confirmed. EDG rejects this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-24 10:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from hackbunny at reactos dot com 2008-11-24 10:24 ---
Created an attachment (id=16756)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16756action=view)
Smaller test case
gcc -c -v -funit-at-a-time -nostdinc testcase.c
Using built-in specs.
Target: mingw32
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 10:21
---
This is essentially a defect in DR 778:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778
I'll see what we can do for now.
--
paolo dot carlini at oracle dot com changed:
--- Comment #8 from hackbunny at reactos dot com 2008-11-24 10:29 ---
I have added a test case that shows a closely related issue with nested
functions, -funit-at-a-time and unreferenced file-scope externs (yes, if you
remove int x = 0; the warning goes away)
The %D renamed after being
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Summary|bitset initialization from 0|[4.4 Regression] bitset
|rejected.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 11:10
---
The default constructor of pair just implements DR 265, this is *very* old:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265
This is possibly a C++ front-end issue, because lately nothing
--- Comment #4 from paolo at gcc dot gnu dot org 2008-11-24 11:14 ---
Subject: Bug 38244
Author: paolo
Date: Mon Nov 24 11:13:44 2008
New Revision: 142152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142152
Log:
2008-11-24 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-24 11:15
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo at gcc dot gnu dot org 2008-11-24 11:21 ---
Subject: Bug 38244
Author: paolo
Date: Mon Nov 24 11:19:39 2008
New Revision: 142153
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142153
Log:
2008-11-24 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #21 from mikael at gcc dot gnu dot org 2008-11-24 12:15 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:13:59 2008
New Revision: 142154
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142154
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #22 from mikael at gcc dot gnu dot org 2008-11-24 12:25 ---
Argh!!
elemental_dependency_1.f90 was not committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
--- Comment #23 from mikael at gcc dot gnu dot org 2008-11-24 12:38 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:37:25 2008
New Revision: 142155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142155
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #24 from mikael at gcc dot gnu dot org 2008-11-24 12:48 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:46:57 2008
New Revision: 142156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142156
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-24 12:59 ---
Subject: Bug 37135
Author: jakub
Date: Mon Nov 24 12:57:37 2008
New Revision: 142157
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142157
Log:
PR middle-end/37135
* dse.c
--- Comment #25 from mikael at gcc dot gnu dot org 2008-11-24 13:10 ---
(In reply to comment #22)
Argh!!
elemental_dependency_1.f90 was not committed.
Fixed now, sorry for the noise.
(In reply to comment #20)
Mikael, Daniel: Have I missed something or is everything in this PR
--- Comment #4 from domob at gcc dot gnu dot org 2008-11-24 13:12 ---
Subject: Bug 37779
Author: domob
Date: Mon Nov 24 13:10:37 2008
New Revision: 142158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142158
Log:
2008-11-24 Daniel Kraft [EMAIL PROTECTED]
PR
I am using the following gfortran compiler, installed on a 32-bit computer
running Open SUSE 10.0:
[EMAIL PROTECTED]:~/design/linux/gfortran/bug32_1/test gfortran --version
GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]
Copyright (C) 2008 Free Software Foundation, Inc.
--- Comment #1 from clerman at fuse dot net 2008-11-24 14:37 ---
Created an attachment (id=16757)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16757action=view)
archive described in the initial bug report
Pleas see initial bug report.
--
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55
---
*** Bug 38238 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55
---
The problem is the rvalue (2)
*** This bug has been marked as a duplicate of 35569 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2008-11-24 15:05 ---
The sbitmap.i works for me with ~/gcc-build-43/gcc/cc1 -O2 -march=amdfam10
-mcx16 -msahf -fprofile-generate --param l1-cache-size=64 --param
l1-cache-line-size=64
where
GNU C (GCC) version 4.3.3 20081110 (prerelease)
Minimal testcase to `use' some module cannot be compiled.
Compilation works fine on Fedora gcc-gfortran-4.3.2-7.x86_64.
GNU Fortran (GCC) version 4.4.0 20081124 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081124 (experimental), GMP version
4.2.2, MPFR
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-24 15:19 ---
Your shell script contains items of the form
/home/norm/design/numrec/nrTypeM.f90
which of course doesn't exist so the shell script
aborts when executed.
BTW, if it is fixed on amd64, then it is mostlikely
fixed
--- Comment #5 from ubizjak at gmail dot com 2008-11-24 15:29 ---
BTW: You should report this bug to:
with-bugurl=http://bugs.gentoo.org/
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-24 15:29 ---
(In reply to comment #2)
This is probably too old:
GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]
Definitely, the bug is PR37445, which was fixed on 3rd November.
--
--- Comment #6 from special at dereferenced dot net 2008-11-24 15:36
---
I've already spoken to one of the GCC maintainers for gentoo - he advised me to
report the issue directly upstream if I could reproduce it without
gentoo-specific patches (which I have); this could be an issue
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 15:37 ---
Works for me.
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran
--enable-maintainer-mode --disable-multilib :
--- Comment #7 from ubizjak at gmail dot com 2008-11-24 16:00 ---
(In reply to comment #6)
I've already spoken to one of the GCC maintainers for gentoo - he advised me
to
report the issue directly upstream if I could reproduce it without
gentoo-specific patches (which I have); this
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16989
nThis||
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 16:20 ---
The error message looks as if you are mixing a gfortran 4.3 compiled .mod file
with a gfortran 4.4 compiler (or vice versa). While the gfortran 4.3 compiled
*.o/*.so/*.a files are supposed to be compatible with 4.4's
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-24 16:22 ---
To add: There is currently a build problem for the linux 32bit version of the
gfortran nightlies; thus there has been no newer build since about one month.
--
burnus at gcc dot gnu dot org changed:
I have some legacy code that I just tried compiling with gfortan (on a
i686-linux-slackware-12.1 box). There were a large number of warnings of the
type:
Warning: Nonconforming tab character in column 1 of line 69
(These where lines which started with a single tab instead of 7 spaces).
In
GCC ICEs on folowing code with options -O2 -ftree-loop-distribution
typedef long unsigned int size_t;
typedef struct {
long dat[2];
} gsl_complex_long_double;
typedef struct {
size_t size;
size_t stride;
long *data;
} gsl_vector_complex_long_double;
void
--- Comment #1 from tomby at gcc dot gnu dot org 2008-11-24 16:31 ---
Created an attachment (id=16758)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16758action=view)
gcc ICEs on this file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
--- Comment #4 from kargl at gcc dot gnu dot org 2008-11-24 15:32 ---
After removing all of your full path names, I get
REMOVE:kargl[215] gfc4x WinModI.f90 -c -Wall -O3 -ffast-math -funroll-loops
-std=f2003 -fno-backslash -owinmod.o winmod.xyz
WinModI.f90:68: Error: Can't open
--
jan dot kratochvil at redhat dot com changed:
What|Removed |Added
Severity|blocker |normal
Summary|Fatal Error: Reading module |Ignored
--- Comment #2 from tomby at gcc dot gnu dot org 2008-11-24 16:39 ---
In tree-loop-distribution.c (generate_memset_zero) can be DR_STEP(dr) NULL. But
it is passed into fold_build2 that expect two non null expressions.
If program flow goes to end: due to goto then temporary variables
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-11-24 16:40
---
Created an attachment (id=16759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16759action=view)
Check the file manipulations errors.
Thanks Tobias B.,
unlink(mmm.mod) = -1 EPERM
--- Comment #3 from tomby at gcc dot gnu dot org 2008-11-24 16:42 ---
Created an attachment (id=16760)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16760action=view)
This patch fixes problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
--- Comment #9 from uros at gcc dot gnu dot org 2008-11-24 16:57 ---
Subject: Bug 36793
Author: uros
Date: Mon Nov 24 16:55:49 2008
New Revision: 142160
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142160
Log:
* config/i386/i386.md (UNSPECV_CMPXCHG): Rename from
--- Comment #10 from ubizjak at gmail dot com 2008-11-24 16:59 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-24 17:00 ---
(In reply to comment #0)
I have some legacy code that I just tried compiling with gfortan (on a
i686-linux-slackware-12.1 box). There were a large number of warnings of the
type:
Warning: Nonconforming tab
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
--- Comment #4 from sebpop at gmail dot com 2008-11-24 17:27 ---
Subject: Re: ICE with -O2 -ftree-loop-distribution
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
--
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 17:07 ---
Regarding TAB: Standard Fortran does not allow tabs, as extension gfortran
does. Thus you do not need to change the code (though it does not harm to be
standard compliant - that is what the warning tells you). But
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-24 17:46 ---
This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix
the issue?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
As of trunk revision 142086, libgcj doesn't build any longer on Tru64 UNIX
V5.1B:
(cd classes; \
jar cf ../tools.zip `find . -name .svn -prune -o -type f -print`; \
cd ..)
/usr/local/bin/bash: /vol/gnu/bin/jar: Arg list too long
I think such systems still need to be taken into
--- Comment #1 from aph at gcc dot gnu dot org 2008-11-24 17:56 ---
Please try
jar cf ../tools.zip `find . -name .svn -prune -o -type d -print`
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-11-24 17:56
---
Subject: Bug 35018
Author: mkuvyrkov
Date: Mon Nov 24 17:55:35 2008
New Revision: 142161
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142161
Log:
PR target/35018
* config/m68k/m68k.md
This program gives an Internal Error pointing at the CONTAINS:
INTEGER FUNCTION test ()
CONTAINS
END FUNCTION test
It works with gfortran 4.3.1. Replacing the FUNCTION by a SUBROUTINE gets rid
of the error. Additionally, this program also works:
FUNCTION test ()
INTEGER :: test
CONTAINS
END
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-24
18:04 ---
Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short
command lines
aph at gcc dot gnu dot org writes:
Please try
jar cf ../tools.zip `find . -name .svn -prune -o -type d
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-24 18:07 ---
Subject: Bug 38076
Author: janis
Date: Mon Nov 24 18:05:50 2008
New Revision: 142163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142163
Log:
2008-11-24 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #3 from janis at gcc dot gnu dot org 2008-11-24 18:12 ---
Subject: Bug 38241
Author: janis
Date: Mon Nov 24 18:11:12 2008
New Revision: 142164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142164
Log:
2008-11-24 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #7 from aleksi dot nurmi at helsinki dot fi 2008-11-24 18:17
---
(In reply to comment #6)
This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix
the issue?
Nope. I did a little research and it seems that -fno-tree-vrp fixes it.
--
--- Comment #3 from aph at gcc dot gnu dot org 2008-11-24 18:29 ---
Yes, of course.
jar has an update mode that adds files, so I can use that. How long may an
arglist be?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 ---
Created an attachment (id=16761)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761action=view)
drivers/scsi/sd.c
Similar problem with drivers/scsi/sd.c
I can compile the attached preprocessed on x86_64 linux:
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-11-24
18:37 ---
Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short
command lines
aph at gcc dot gnu dot org writes:
jar has an update mode that adds files, so I can use that. How long may an
--- Comment #5 from aph at gcc dot gnu dot org 2008-11-24 18:48 ---
Sure, if you can use zip instead, do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #6 from clerman at fuse dot net 2008-11-24 18:50 ---
Created an attachment (id=16762)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16762action=view)
updated, and corrected (I hope) archive
hello,
Sorry for the mixup on the archive. I've attached a new one,
The test case for g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on
powerpc-apple-darwin9 as follows in current gcc trunk...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/gcc/testsuite/g++/../../g++
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-24
18:52 ---
Created an attachment (id=16763)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16763action=view)
assembly file for g++.dg/ipa/iinline-1.C on powerpc-apple-darwin9
--
--- Comment #6 from aph at gcc dot gnu dot org 2008-11-24 18:52 ---
I suggest
jar cf ... to create it, and
zip u ... to add to it
that way you'll get the correct META-INF directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #7 from clerman at fuse dot net 2008-11-24 18:54 ---
Subject: Re: problem with contained subprocedure.
Hello,
This appears to be the problem. In any case, I just submitted a new archive
file. I hope this one's correct.
Thanks for your help. Let me know when the fix has
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-24 19:06 ---
Subject: Bug 38184
Author: mikael
Date: Mon Nov 24 19:04:34 2008
New Revision: 142168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142168
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:07 ---
OK, here's the information you requested:
gfortran -v:
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr
--with-gnu-as --enable-shared --with-gnu-ld
--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:08 ---
Created an attachment (id=16764)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16764action=view)
sample source and makefile
Running make or make DEBUG=x will generate the program. When you run
--- Comment #26 from pault at gcc dot gnu dot org 2008-11-24 19:14 ---
Subject: Bug 35681
Author: pault
Date: Mon Nov 24 19:13:12 2008
New Revision: 142169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142169
Log:
2008-11-24 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2008-11-24 19:20 ---
Subject: Bug 37926
Author: pault
Date: Mon Nov 24 19:18:39 2008
New Revision: 142171
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142171
Log:
2008-11-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2008-11-24 19:20 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-24 19:14 ---
Subject: Bug 37792
Author: pault
Date: Mon Nov 24 19:13:12 2008
New Revision: 142169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142169
Log:
2008-11-24 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-24 19:21 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2008-11-24 19:22 ---
(In reply to comment #3)
Now for the more difficult part.
I'll attach a tar file containing a sample program and a makefile. It turns
out that the problem isn't with the read at all, rather it arises when I
--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:29 ---
It works without -malign-double, but has worked with it for years. I
understand that all modules (even thouse in MY libraries) have to be compiled
with the same flags, but nothing seems to imply that
On Linux/ia32 SMP, revision 142160
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01194.html
causes
FAIL: PR27908 -O3 execution - source compiled test
FAIL: PR27908 -O3 -findirect-dispatch execution - source compiled test
--
Summary: [4.4 Regression] Revision 142160 causes PR27908
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32
---
The problem still reproduces on the SPARC as of today. When the compiler is
rebuilt at -O0, it goes away; when decl.c and parser.c are rebuilt at -O2, it
comes back.
--
ebotcazou at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-24 19:32 ---
Not just all your modules but libgfortran also and all of glibc etc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.4
Known to work||4.4.0 4.3.0
--- Comment #8 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:36 ---
I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build
with -malign-double, not just fortran programs, then IMHO the flag is useless
and should be removed. I've been using
1 - 100 of 143 matches
Mail list logo
