The test still fails at -O2 -gnato... All the current FAIL
still fail with -gnato, and we even have two additional failures
(unexpected constraint_error):
c45532e
c45532g
So we have to look carefully at what the front-end does with modular
types here.
Note that cxa4025, cxa4028, cxa4033 are lik
Comments? I'm of course also volunteering to write the patch, provided that
an adept at the new bootstrap (black) magic gives me a clue as to where I
should start. :-)
You just have to write the test in the toplevel configure.in, and place
it just before the AC_SUBST(stage1_cflags).
The m
On 02 March 2006 00:02, Mike Stump wrote:
> On Mar 1, 2006, at 3:47 AM, HASSAN AL MOATASSIME wrote:
>> I have a problem with the compiler gcc 3.4.4.
>> With the gcc 3.2 compiler, i have no problem with the following
>>instruction : creal(U0[i])=PartieReelle;
>>cimag
Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}?
I only need original, generic and gimple. Is there a description about the
generic-file somewhere? I read
http://zenii.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf but it's
not enough yet.
Thank you very much in
> it's not a bug, -gnato is clearly documented as required in this
> case, what makes you think otherwise?
Laurent's message.
Sorry about that, -gnato indeed has always been specified for this test.
--
Eric Botcazou
> # BLOCK 6
> # PRED: 4 (false,exec)
> :;
> iftmp.78_63 = D.1309_32;
> iftmp.78_64 = D.1309_32;
> D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> if (D.1316_65 == 255) goto ; else goto ;
> # SUCC: 7 (true,exec) 8 (false,exec)
> [...]
> The problem (of course) is D.1316_65 can and
Hi,
On 2006-03-01 08:43:46 +0100, Maurizio Loreti wrote:
> /usr/soft/lib/libmpfr.a and /usr/soft/lib/libgmp.a are from gmp 4.1.4
The MPFR version distributed with GMP 4.1.4 is old, very buggy, and
no longer maintained. It is highly recommended to compile GMP without
MPFR support and compile the l
> Excerpt from utils2.c:
>
> /* Likewise, but only return types known to the Ada source. */
> tree
> get_ada_base_type (tree type)
> {
> while (TREE_TYPE (type)
>&& (TREE_CODE (type) == INTEGER_TYPE
>
>|| TREE_CODE (type) == REAL_TYPE)
>
>&& !TYPE_EXTRA_SUBTYPE_P (typ
Hi there,
Nobody seems to know about this in gcc-help, so, there I go:
Forwarded Message
From: David Fernandez <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: i686 architecture behaviour in gcc
Date: Tue, 21 Feb 2006 17:08:32 +
Hi there,
On 2006-03-01 14:51:45 -0800, H. J. Lu wrote:
> Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> "-O2 -mtune=generic -ffast-math" on Nocona:
[...]
Optimization is much less important than correct results. From
this point of view, I don't think that using an option known to
produce incorrect
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default. However glibc
still assumes gcc mixes SSE and x387 math. The x86-64 FP control
routines in glibc change both SSE and x387 units, which is no
longer necessary with the newer g
On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> With this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
>
> gcc no longer mixes SSE and x387 math by default. However glibc
> still assumes gcc mixes SSE and x387 math. The x86-64 FP control
> routines in glibc change both SSE an
On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > With this patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
> >
> > gcc no longer mixes SSE and x387 math by default. However glibc
> > still assumes gcc mixes
Hi all,
I am trying to build/install gcc-4.1.0 on my Linux box (RHEL-3), in a
non-standard prefix.
I use -with-libiconv-prefix the tell configure where to find libiconv,
and the configure step works.
The build step fails in libcpp:
/apa/gnu/Linux-RH-WS-3/gcc/gcc-3.4.4/bin/gcc -O2
-I/apa/gn
On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
> > On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > > With this patch:
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
> > >
> > > gcc no longer mixes SSE and x3
On Thu, Mar 02, 2006 at 04:34:09PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
> > > On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > > > With this patch:
> > > >
> > > > http://gcc.gnu.org/m
On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> Yes. That is for float and double functions in libm.
>
> > to touch x387
> > flags for XFmode long long operations.
>
> I assume you meant long double. If the library knows it doesn't long
> double, it doesn't need to touch x87 unit cont
On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > Yes. That is for float and double functions in libm.
> >
> > > to touch x387
> > > flags for XFmode long long operations.
> >
> > I assume you meant long double. If the l
On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > > Yes. That is for float and double functions in libm.
> > >
> > > > to touch x387
> > > > flags for XFmode long long ope
On Thu, Mar 02, 2006 at 05:19:20PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> > > On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > > > Yes. That is for float and double functions i
Hello,
There is a wikibook that describes the internals of GCC and GEM, an
extensibility framework.
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals
GEM allows programmers to write extensions to GNU C. We will submit the
framework as a GCC patch. Please give us feedback on the framework
This change:
2006-02-17 Roger Sayle <[EMAIL PROTECTED]>
PR middle-end/25600
* fold-const.c (fold_binary): Fold (X >> C) != 0 into X < 0 when
C is one less than the width of X (and related transformations).
* simplify-rtx.c (simplify_unary_operation_1): Transform
On Thu, 2006-03-02 at 14:05 +0100, Eric Botcazou wrote:
> > # BLOCK 6
> > # PRED: 4 (false,exec)
> > :;
> > iftmp.78_63 = D.1309_32;
> > iftmp.78_64 = D.1309_32;
> > D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> > if (D.1316_65 == 255) goto ; else goto ;
> > # SUCC: 7 (true,exec
Just to be 100% clear, I'm leaving this one in the hands of the
Ada maintainers. I'm not qualified to fix it.
Right.
We're also still need the uintp fix installed. I'm not qualified to
say if Kenner's fix is correct or not, thus I'm not comfortable
checking in that change.
> Just to be 100% clear, I'm leaving this one in the hands of the
> Ada maintainers. I'm not qualified to fix it. Once the Ada
> maintainers have this issue fixed, I'll re-run the Ada testsuite
> and attack the next regression introduced by the VRP changes
> (if any are left).
Sure. My message
On Thu, 2 Mar 2006, Jeffrey A Law wrote:
> Is causing 961206-1.c to regress at -O1 and -O2 on i686-pc-linux-gnu
> and possibly other platforms.
Doh! This doesn't fail on x86_64-unknown-linux-gnu, where I developed
that patch, but I am now seeing those failures on i686-pc-linux-gnu.
> OUCH. Ins
On Thu, 2006-03-02 at 12:35 -0700, Roger Sayle wrote:
> Sorry for the breakage. I'll have a fix before the sun goes down,
> that performs the shift in the correct mode, then appropriately
> sign extends, zero extends or truncates if necessary.
>
> Many thanks for analyzing this failure. Sorry a
On Thu, 2006-03-02 at 14:04 +0100, Eric Botcazou wrote:
> > it's not a bug, -gnato is clearly documented as required in this
> > case, what makes you think otherwise?
>
> Laurent's message.
I missed the fact that the test was already in overflow.lst :)
Laurent
On Thu, 2006-03-02 at 01:34 +0100, Robert Dewar wrote:
> Laurent GUERBY wrote:
>
> > VRP might now force us to update the overflow list but I'm not sure
> > about switching to a full -gnato everywhere.
>
> well you can expect some fiddling each version if you work this way
The list for -gnato te
> I missed the fact that the test was already in overflow.lst :)
No worries, so did I. :-)
--
Eric Botcazou
Roman Belenov wrote:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>
>> Upgrading GNU tar to 1.15.1 fixed the problem for me.
>
> So what is the actual requirement - 1.14 or "1.14 or above" ?
The latter.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Snapshot gcc-4.0-20060302 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060302/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
I am building a generic installation program for GNU
coding standards-compliant packages.
http://www.gnu.org/software/sourceinstall/
I am also helping all GNU projects with a
non-compliant build system make the move to the GNU
coding standards, with patches and support.
I have a problem w
Jan Wegner wrote:
Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}?
Try reading the docs for the -fdump-tree-* options. You can choose
which dump files are created by using the appropriate option.
I only need original, generic and gimple. Is there a description a
On Mar 2, 2006, at 7:23 PM, Claudio Fontana wrote:
The problem is that, while an user can read a message
like:
configure: error: you must configure in a separate
build directory
This is a bug only in the 4.0.x series of GCC and nowhere else.
-- Pinski
On Thu, Mar 02, 2006 at 04:23:42PM -0800, Claudio Fontana wrote:
> I am building a generic installation program for GNU
> coding standards-compliant packages.
> http://www.gnu.org/software/sourceinstall/
> I have a problem with current builddir != srcdir
> requirement in glibc and recent versions
Yoav Etsion wrote:
I'm designing a new hardware that needs to know which GPR contains a
simple integer, and which contained pointer. The hardware simply needs
different load operations for both (we're talking load/store machines,
with no indirect addressing to make life easier).
You can try u
David Fernandez wrote:
Can anyone explain why has been chosen that -march=i686 makes the
compiler change the normal behaviour, and zero-expand unsigned short
parameters into 32-bit registers by all means?
You failed to mention the gcc version, and your testcase doesn't
actually use any
Hello Andrew,
thanks for your answer.
--- Andrew Pinski <[EMAIL PROTECTED]> ha scritto:
>
> On Mar 2, 2006, at 7:23 PM, Claudio Fontana wrote:
> > The problem is that, while an user can read a
> message
> > like:
> >
> > configure: error: you must configure in a separate
> > build directory
>
Hi,
I've ported gcc to mytarget-linux version. The object file compiled
now are shared one. My current simulator is able to run static
executable program and just translate binary code one by one. I know
shared file needs dynamic linker to load. So I'd like to know can I
run shared file on my sim?
We are pleased to announce the availability of GCC for SPARC (R) Systems
(GCCfss) at http://cooltools.sunsource.net/gcc/
GCCfss extends GCC to be able to use
the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss).
We encourage you to download it and try it.
The compiler commands are the
41 matches
Mail list logo
