On Mon, 19 Jan 2009, H.J. Lu wrote:
On Mon, Jan 19, 2009 at 1:27 AM, Richard Guenther rguent...@suse.de wrote:
On Sun, 18 Jan 2009, Richard Guenther wrote:
On Sun, 18 Jan 2009, H.J. Lu wrote:
On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenther rguent...@suse.de
wrote:
A
Hi,
I have found the testcase gcc/testsuite/gcc.dg/noncompile/920507-1.c
failing when I was testing my new SRA. The testcase is quite simple,
should error out but no longer does:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error
On Tue, Jan 20, 2009 at 12:06 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
I have found the testcase gcc/testsuite/gcc.dg/noncompile/920507-1.c
failing when I was testing my new SRA. The testcase is quite simple,
should error out but no longer does:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid register
} */
int *v[1] = {a};
return v[1];
}
I think simply scalarizing for the above testcase is ok - the behavior
is
On Tue, Jan 20, 2009 at 2:17 PM, Paolo Bonzini bonz...@gnu.org wrote:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid register
} */
int *v[1] = {a};
return v[1];
}
I
Hi,
Is there any difference between (*(x)).a and (x)-a, if x is an
expression which generates a struct pointer.
I found the assembly code of these two generated by gcc are the same.
But is the implementation compiler dependent? Or do they just have the
same meaning expressed in different syntax?
On Mon, Jan 19, 2009 at 11:27 PM, Ben Elliston b...@au1.ibm.com wrote:
On Mon, 2009-01-19 at 23:20 -0600, Sebastian Pop wrote:
Perhaps we should add a comment to common.opt to explain this?
Yes, we could apply this patch.
Looks good to me (and I think it qualifies as obvious) :-).
I've
Hello Jacque,
Jacques Lefrere wrote:
I thought that the argument of the intrinsic function range
could be integer, real or complex.
But the manual mentions that it should be of type real or complex only.
(see http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gfortran/RANGE.html#RANGE;)
Corrected for
Mark Mitchell wrote:
Joseph S. Myers wrote:
As code shared by GCC and glibc I would suggest the same license notice as
soft-fp (LGPL = 2.1 + exception) to allow an identical file to be shared.
(Indeed, soft-fp uses this header.) The version in GMP diverged long ago
so sharing the file
Hello, my name is Andrey Babanin.
I am working on the remote procedure call system integrated into C
language. System called CRPC,
it consists of C wrapper compiler and shared library. Wrapper compiler
works with GCC.
New RPC system helps you develop socket based applications. With the
system
On Tue, 20 Jan 2009, Mark Mitchell wrote:
Mark Mitchell wrote:
Joseph S. Myers wrote:
As code shared by GCC and glibc I would suggest the same license notice as
soft-fp (LGPL = 2.1 + exception) to allow an identical file to be shared.
(Indeed, soft-fp uses this header.) The
Currently i686-apple-darwin9 appears in very good shape for
gcc 4.4 with the exception of one new set of testsuite failures
related to the new stackalignment changes. These all share the
commmon feature of only failing with the -O3 -g compiler option
flags...
FAIL:
andrew babanin ababa...@gmail.com writes:
I am working on the remote procedure call system integrated into C
language. System called CRPC,
it consists of C wrapper compiler and shared library. Wrapper compiler
works with GCC.
New RPC system helps you develop socket based applications. With
On Tue, Jan 20, 2009 at 3:29 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Currently i686-apple-darwin9 appears in very good shape for
gcc 4.4 with the exception of one new set of testsuite failures
related to the new stackalignment changes. These all share the
commmon feature of only
Hi all,
Not sure if this fits in more with GCC or binutils.
We have amodified binutils/gcc to add a few opcodes to the MIPS-I ISA for a
processor we've designed as part of our academics. One of these opcodes writes
an index into a register we specify.
This works, but we're seeing
1) the
C++ 4.4.0 20090120 (experimental)\0
+ .byte 0x4
+ .ascii throw-1.C\0
+ .ascii /Users/howarth/stackalign\0
+ .long Ltext0
+ .long Letext0
+ .set L$set$161,Ldebug_line0-Lsection__debug_line
+ .long L$set$161
+ .byte 0x2
+ .byte 0x4
On Tue, Jan 20, 2009 at 6:21 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Tue, Jan 20, 2009 at 05:50:35PM -0800, H.J. Lu wrote:
On Tue, Jan 20, 2009 at 3:29 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
Currently i686-apple-darwin9 appears in very good shape for
gcc 4.4 with the
baver ba...@thebeever.com writes:
A sample code listing is at the bottom of the email, as well as the lines
we've added to opcodes/mips-opc.c for our opcodes.
Anyone know how to stop the register from being stored and read from on the
stack? We've defined it as
volatile register
--- Comment #3 from pluto at agmk dot net 2009-01-20 08:22 ---
(In reply to comment #2)
However, if this is a cross compile,
yes, this is a cross compiler: build/host=linux, target=mingw.
then crossconfig.m4 is wrong:
*-mingw32*)
AC_DEFINE(HAVE_STRTOF)
--- Comment #3 from pluto at agmk dot net 2009-01-20 08:41 ---
(In reply to comment #2)
libstdc++ also needs to be built and linked in as dll.
i'm passing --enable-shared to gcc's configure but it only
creates shared libgcc_s_1.dll. libstdc++ is still static.
should i applay some
I discovered that a simple benchmark (SCIMARK2 Montecarlo) runs tree times
slower when compiled with gcc 4.3 w.r.t. 4.1 or 3.4
Code is compiled and run of INTEL core 2 machines running RHEL4, RHEL5 or
fedora10.
below details on fedora 10
compilers used are from fedora distribution
-bash-3.2$ gcc
--- Comment #1 from vincenzo dot innocente at cern dot ch 2009-01-20 08:48
---
Created an attachment (id=17152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17152action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38922
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-20 09:04 ---
4.4.0 is faster for me than 4.2 and 4.3 (4.3 is indeed slower than 4.2, but
my 3.4 (32bit only) is way slower than 4.4 (also 32bit)).
Note that performance of cmov heavily depends on the microarchitecture of your
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.3.3
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-01-20 09:13
---
From tree-inline.c:
case BUILT_IN_LONGJMP:
/* We can't inline functions that call __builtin_longjmp at
all. The non-local goto machinery really requires the
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-20 09:21
---
Should be fixed now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36227
--- Comment #3 from vincenzo dot innocente at cern dot ch 2009-01-20 09:24
---
I confirm that gcc 4.2.3 is as fast as 4.1 and at least twice as slow of gcc
4.3.2
test done on an intel core2 running RHL4 and core i7 with RHL5.
mtune either generic or native (no difference)
--
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-20 09:47 ---
(In reply to comment #2)
http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516 ?
Seems to be my fault, quite plausibly :D I will work on this.
--
domob at gcc dot gnu dot org changed:
What
--- Comment #3 from domob at gcc dot gnu dot org 2009-01-20 09:44 ---
I will work on this.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-20 10:38 ---
To fit in gcc.dg/torture, the test needs a
/* { dg-do run } */
at the top.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
--- Comment #4 from r dot emrich at de dot tecosim dot com 2009-01-20
11:41 ---
I don't think that this has anything to do with the crossconfig.m4
At least until revision 143362 trunk used to build cross compiler from
x86_64-unknown-linux-gnu to both mingw targets x86_64-pc-mingw32
--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-01-20
11:50 ---
Benjamin, I suspect that your changes on the 15th are causing the trouble.
FYI, for libgfortran all the math test are performed at least for the
x86_64-pc-mingw32 target even in a cross build.
--
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-01-20
13:00 ---
Benjamin,
you have only
#include cmath
in both math_stubs_float.cc and math_stubs_long_double.cc.
Then you use something like
#ifndef _GLIBCXX_HAVE_FABSL
I don't see any definition in scope.
--
--- Comment #47 from bonzini at gnu dot org 2009-01-20 13:24 ---
Subject: Bug 38868
Author: bonzini
Date: Tue Jan 20 13:24:25 2009
New Revision: 143513
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143513
Log:
gcc:
2008-01-20 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #48 from bonzini at gnu dot org 2009-01-20 13:25 ---
Fixed; the bug is latent in 4.3.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #9 from rob1weld at aol dot com 2009-01-20 13:54 ---
I was checking my Testsuite Results for UNSUPPORTED tests and arrived here.
I thought I would try the code on i386-pc-solaris2.11 with gcc version 4.4.0 .
When booted 32-bit and using -m64:
# gcc -O2 -m64 -fPIC test.c
--- Comment #23 from hjl dot tools at gmail dot com 2009-01-20 14:24
---
(In reply to comment #22)
From tree-inline.c:
case BUILT_IN_LONGJMP:
/* We can't inline functions that call __builtin_longjmp at
all. The non-local goto machinery really
--- Comment #49 from hjl dot tools at gmail dot com 2009-01-20 14:27
---
(In reply to comment #48)
Fixed; the bug is latent in 4.3.
The testcase should be added to 4.3 to make sure that it remains latent
even with future backports.
--
--- Comment #3 from HMWiesinger at gmx dot at 2009-01-20 14:30 ---
Sorry for the delay. I found out it works for me as well, sometimes. I'll
attach both the output of when it worked and when it failed (on the same
system).
Command:
/usr/bin/g++ -v -ftemplate-depth-128 -O3
--- Comment #12 from hjl at gcc dot gnu dot org 2009-01-20 14:40 ---
Subject: Bug 38902
Author: hjl
Date: Tue Jan 20 14:40:30 2009
New Revision: 143516
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143516
Log:
2009-01-20 Kees Cook k...@ubuntu.com
H.J. Lu
--- Comment #7 from r dot emrich at de dot tecosim dot com 2009-01-20
14:58 ---
(In reply to comment #4)
I don't think that this has anything to do with the crossconfig.m4
At least until revision 143362 trunk used to build cross compiler from
x86_64-unknown-linux-gnu to both mingw
--- Comment #24 from rguenther at suse dot de 2009-01-20 15:01 ---
Subject: Re: [4.4 Regression] psim miscompiled #2
On Tue, 20 Jan 2009, hjl dot tools at gmail dot com wrote:
--- Comment #23 from hjl dot tools at gmail dot com 2009-01-20 14:24
---
(In reply to comment
--- Comment #25 from hjl dot tools at gmail dot com 2009-01-20 15:08
---
(In reply to comment #24)
Subject: Re: [4.4 Regression] psim miscompiled #2
On Tue, 20 Jan 2009, hjl dot tools at gmail dot com wrote:
--- Comment #23 from hjl dot tools at gmail dot com 2009-01-20
--- Comment #8 from r dot emrich at de dot tecosim dot com 2009-01-20
15:12 ---
(In reply to comment #7)
(In reply to comment #4)
I don't think that this has anything to do with the crossconfig.m4
At least until revision 143362 trunk used to build cross compiler from
--- Comment #5 from j dot s dot sebastian at gmail dot com 2009-01-20
15:13 ---
It seems with libstdc++ from svn trunk the bug disappears.
Both
__gnu_parallel::sort(v.begin(), v.end());
and
__gnu_parallel::sort(v.begin(), v.end(),std::lessint());
now compile and run.
At the
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-01-20 15:29
---
Well, ISTR something about local variables need to be marked volatile if you
use setjmp/longjmp. Is psim really in compliance with what the standard says
here? See 7.13.2.1/3 ..., except that the values of
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-20
15:36 ---
Subject: Re: FAIL: abi_check hppa
The float versions were added in r143457
The abi check problem is fixed, and the hpux test results on
hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 are again ok.
Dave
--- Comment #3 from amonakov at gcc dot gnu dot org 2009-01-20 15:45
---
The assert that fails is checking whether an instruction was correctly
disconnected from the insn stream (at its original location) to be inserted on
the scheduling boundary by adjusting PREV_INSN/NEXT_INSN links
--- Comment #4 from amonakov at gcc dot gnu dot org 2009-01-20 15:47
---
Created an attachment (id=17153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17153action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
--- Comment #1 from rob1weld at aol dot com 2009-01-20 15:48 ---
The Environment Variable GCC_EXEC_PREFIX _existed_ since long ago:
http://www.cygwin.com/ml/cygwin/1998-11/msg00777.html but I'm still
looking for the first occurrence of the actual Bug itself.
On Platform
--- Comment #27 from hjl dot tools at gmail dot com 2009-01-20 15:49
---
(In reply to comment #26)
Well, ISTR something about local variables need to be marked volatile if you
use setjmp/longjmp. Is psim really in compliance with what the standard says
here? See 7.13.2.1/3 ...,
libstdc++-v3/configure contains this:
ldver=`$LD --version 2/dev/null | head -1 | \
sed -e 's/GNU \(go\)\{0,1\}ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\4/'`
that sed script fails with /usr/bin/sed on Solaris, disabling symbol
versioning.
Here's an example of
--- Comment #28 from joel at gcc dot gnu dot org 2009-01-20 15:55 ---
I am starting a test sweep with this patch applied.
I will report back when the testing is done.
Thanks.
--joel
(In reply to comment #27)
(In reply to comment #26)
Well, ISTR something about local variables
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-01-20 15:58
---
should head -1 also be replaced by head -n 1 or is that less portable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #29 from schwab at suse dot de 2009-01-20 16:30 ---
(In reply to comment #27)
This patch for sim:
Index: sim/ppc/gen-idecode.c
===
RCS file: /cvs/src/src/sim/ppc/gen-idecode.c,v
retrieving revision 1.4
--- Comment #30 from hjl dot tools at gmail dot com 2009-01-20 16:36
---
(In reply to comment #28)
I am starting a test sweep with this patch applied.
I will report back when the testing is done.
I am not sure if those volatile are really needed. I am trying
to create a
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-20 17:02
---
(In reply to comment #1)
should head -1 also be replaced by head -n 1 or is that less portable?
Isn't this a very old issue? I think you will find a straightforward answer /
rationale in the archive, or, in
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-20 17:10 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-20 17:10 ---
Subject: Bug 38748
Author: rguenth
Date: Tue Jan 20 17:10:40 2009
New Revision: 143523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143523
Log:
2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-20 17:10 ---
Subject: Bug 38747
Author: rguenth
Date: Tue Jan 20 17:10:40 2009
New Revision: 143523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143523
Log:
2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-20 17:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-01-20 17:17
---
then
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch02.html#manual.intro.setup.prereq
should be updated to say a POSIX sed is required.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-01-20 17:18
---
oh sorry, Paolo, did you only mean the head part? I'm not too concerned
about that bit, it works everywhere I care about, even if POSIX says otherwise
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-20 17:29
---
Yes, I only meant the head -1 vs head -n 1 part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-01-20 18:50 ---
This code block appears to be capable of generating no end of issues, sadly.
For the record, POSIX head docs say -n is a requirement for conformance, at
least p.2791 of EEE Std 1003.1-2008. Of course, who knows if
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-20 18:52 ---
Mine
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-01-20 19:07
---
I've just noticed that the libgomp configure says:
configure: versioning on shared library symbols is gnu
even though it seems to have the same sed script as libstdc++, which says:
configure: WARNING: ===
--- Comment #2 from sje at gcc dot gnu dot org 2009-01-20 19:14 ---
Subject: Bug 30687
Author: sje
Date: Tue Jan 20 19:14:06 2009
New Revision: 143525
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143525
Log:
PR target/30687
* doc/extend.texi (syscall_linkage):
--- Comment #7 from kargl at gcc dot gnu dot org 2009-01-20 19:22 ---
I have a patch that not only fixes the ICE, but it will issue an
error for a program of the form
troutmask:sgk[203] cat a.f90
program a
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
z = 1.
print '(5ES12.5)', z
--- Comment #19 from bkoz at gcc dot gnu dot org 2009-01-20 19:25 ---
Fixed for 4.4.0
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-01-20 19:31 ---
Subject: Bug 38919
Author: bkoz
Date: Tue Jan 20 19:30:51 2009
New Revision: 143526
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143526
Log:
2009-01-20 Benjamin Kosnik b...@redhat.com
Rainer
--- Comment #3 from sje at cup dot hp dot com 2009-01-20 19:37 ---
Added documentation about syscall_linkage to 4.4.0 documentation.
Closing out defect.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #8 from kargl at gcc dot gnu dot org 2009-01-20 19:41 ---
(In reply to comment #7)
I have a patch that not only fixes the ICE, but it will issue an
error for a program of the form
troutmask:sgk[203] cat a.f90
program a
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
--- Comment #11 from bkoz at gcc dot gnu dot org 2009-01-20 19:44 ---
Should be fixed now.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-20 19:48 ---
(In reply to comment #5)
This removes the ICE: ...
Do you understand why?
In the following:
RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)
gfc_match_rvalue sets where for the rhs to the marked position below:
--- Comment #4 from ubizjak at gmail dot com 2009-01-20 19:49 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01018.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-20 20:00 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822#c7
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
1
Error: Fortran 2003: Noninteger exponent in an initialization expression at (1)
--- Comment #39 from bkoz at gcc dot gnu dot org 2009-01-20 20:02 ---
Hey all. It looks like the libstdc++ part of this is fixed. Therefore, I am
going to slightly edit the subject, un-assign myself, and change the component
to target. Although I suppose it could be binutils.
From
--- Comment #40 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-20
20:23 ---
Subject: Re: link/execute fails for cross gcc from linux to target
hppa64-hp-hpux11.00
From looking at the log of #3, I would suggest that one thing to try would be
to explicitly turn off symbol
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-20 20:56 ---
I don't think this is a libstdc++ bug per se, but configure/build and possibly
libtool-related. But I don't see a configure/build category (only a keyword),
so the current mis-categorization shall continue. I will
+++ This bug was initially created as a clone of Bug #6482 +++ Please
see there for more info. I eyeballed my Testsuite logs and found a
number of test were UNSUPPORTED and should be enabled, here is one:
The file: gcc_trunk/gcc/config/sol2.h is setting SUPPORTS_INIT_PRIORITY
incorrectly.
--- Comment #6 from kargl at gcc dot gnu dot org 2009-01-20 21:02 ---
(In reply to comment #5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822#c7
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
1
Error: Fortran 2003: Noninteger exponent in an
--- Comment #31 from hjl dot tools at gmail dot com 2009-01-20 21:17
---
Created an attachment (id=17154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17154action=view)
A testcase
Revision 143498 gave:
[...@gnu-34 ppc]$ /export/gnu/import/rrs/143498/usr/bin/gcc -S bar.c -O2;
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-20 21:19
---
THis is most likely the same issue as PR 38587. Does -fno-ira fix the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
--- Comment #32 from pinskia at gcc dot gnu dot org 2009-01-20 21:19
---
PR 38660 might the same issue too. It is an issue with longjmp and setjmp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
/*
* The below program demonstrates a defeciency with gcc's constraint
* syntax for 64-bit code: it's not possible to directly constrain an
* operand to a register in the range r8 through r15.
*
* Furthermore, it is not possible to use '%rbp' in a constraint.
*
* It has been shown that gcc
--- Comment #1 from thutt at vmware dot com 2009-01-20 21:27 ---
See bug 16331 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-20 21:34 ---
I think this code is undefined as you are using uninitialized variables for
input of the inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kurt at roeckx dot be 2009-01-20 21:36 ---
My version of gcc doesn't seem to support the -fno-ira option. Is that
something that needs to be enabled at compile time? Can you try my test case
with that option?
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-01-20 21:41
---
(In reply to comment #13)
My version of gcc doesn't seem to support the -fno-ira option.
Well then it is not a snapshot of GCC 4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-20 21:47 ---
Also I think the inline-asm could be improved so that the inline-asm just marks
the registers that are clobbered instead of doing the mess you are doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
--- Comment #8 from pault at gcc dot gnu dot org 2009-01-20 21:57 ---
Subject: Bug 38907
Author: pault
Date: Tue Jan 20 21:56:49 2009
New Revision: 143530
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143530
Log:
2009-01-20 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-01-20 21:58 ---
Subject: Bug 38758
Author: jsm28
Date: Tue Jan 20 21:58:30 2009
New Revision: 143531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143531
Log:
PR other/38758
* longlong.h: Update copyright
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-20 21:59 ---
Fixed on trunk
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-01-20 22:01 ---
Subject: Bug 38758
Author: jsm28
Date: Tue Jan 20 22:01:03 2009
New Revision: 143532
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143532
Log:
PR other/38758
* longlong.h: Update copyright
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-01-20 22:02 ---
Subject: Bug 38758
Author: jsm28
Date: Tue Jan 20 22:02:18 2009
New Revision: 143533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143533
Log:
PR other/38758
* longlong.h: Update copyright
--- Comment #15 from kurt at roeckx dot be 2009-01-20 22:03 ---
I was still using:
gcc (Debian 20081213-1) 4.4.0 20081212 (experimental) [trunk revision 142725]
Which doesn't seem to have that option.
Upgrading to the latest in Debian gives this version:
gcc (Debian 20090107-1) 4.4.0
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-20 22:29 ---
(In reply to comment #3)
DLA = DDA(2:3, 1:3:2, 5:4:-1, NF2, NF5:NF2:MF2)
The descriptor built for DLA has negative strides for dimension = 3.
This makes ubound fail.
Forget this
DLA = DDA(2:3, 1:3:2,
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-20 22:37 ---
(In reply to comment #6)
Note, this error is incorrect and will not be generated by gfortran when
my patch for pr38823 is accepted.
Your error may or may not eventually go to trunk.
But the marker is at the
--- Comment #13 from steven at gcc dot gnu dot org 2009-01-20 23:01 ---
Created an attachment (id=17155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17155action=view)
Throttle PRE, hookize SMALL_REGISTER_CLASSES
This is the patch I have in my local tree (bootstrappedtested on
1 - 100 of 122 matches
Mail list logo
