Hi,
I have transferred all the statements of one BB( header of one loop)
to another BB. After that I have updated SSA information too.
But I get this error-
definition in block 6 does not dominate use in block 3
for SSA_NAME: i_25 in statement:
# VUSE a_18
D.1189_10 = a[i_25];
loop.c:8:
Hello
I'm having problem when making apache 2.0.63.
Im using the configure command like this:
CC=gcc CFLAGS= -O2 -mcpu=v9 -m64 CPPFLAGS= -m64 -I/usr/sfw/include
LDFLAGS=-m64 \
./configure --prefix=/usr/apache2 --enable-mods-shared=most --with-mpm=prefork
And the problem I got looks like
Hello all,
For a function call will i be able to implement long call/short call
for the same function at different locations?
Say fun1 calls bar and fun2 calls bar. I want short-call to be
generated for bar in fun1 and long-call to be generated in fun2.
Is to possible to implement this in the
On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram [EMAIL PROTECTED] wrote:
Hi,
I have transferred all the statements of one BB( header of one loop)
to another BB. After that I have updated SSA information too.
But I get this error-
definition in block 6 does not dominate use in block 3
Hi!
On Wed, Apr 09, 2008 at 11:29:24PM -0500, Vasilis Liaskovitis wrote:
I am a beginner interested in learning gcc internals and contributing
to the community.
Thanks for showing interest in this area!
I have started implementing PR35423 - omp workshare in the fortran
front-end. I have
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
corrected on
On Mon, Apr 14, 2008 at 1:55 PM, Paul Schlie [EMAIL PROTECTED] wrote:
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The
Paul Schlie wrote:
(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
Richard Guenther wrote:
In absence of any declared object (like with this testcase where we just
have an incoming pointer to some unknown object) the compiler can
still assume that any valid object ends at the end of the address space.
Thus, an object either declared or allocated via malloc
Robert Dewar [EMAIL PROTECTED] writes:
Alex Stepanov told me once that he preferred Ada to C, because Ada
has proper pointer arithmetic (via the type Integer_Address) which
is defined to work in Ada in the manner that Paul mistakenly expects
for C. Integer_Address would be a bit of a pain to
This is the final proposal for the introduction of arrays as first
class citizens of the middle-end. The goal is still to retain
the high-level information that the GFortran frontend has for array
assignments up to the high-level loop optimization passses and to
not lower Fortran array
Hi Bob,
On Sat, 12 Apr 2008, Bob Walters wrote:
Can you send me any reference to the current copyright assignment
form, so that I can get this taken care of. I found something online
at http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html, but have no idea
if that is current, so wanted to check
On Sun, 2008-04-13 at 17:05 +0530, Mohamed Shafi wrote:
Well i tracked down the cause to the md file. In the md file i had a
define_expand for the jump pattern. Inside the pattern i was checking
whether the value of the offset for the jump is out of range and if
its out of range then force
Robert C. Seacord wrote:
i agree that the optimization is allowed by C99. i think this is a
quality of implementation issue, and that it would be preferable for
gcc to emphasize security over performance, as might be expected.
On Sun, Apr 13, 2008 at 11:51:00PM +0200, Florian Weimer
* Robert Dewar:
Florian Weimer wrote:
* Robert C. Seacord:
i agree that the optimization is allowed by C99. i think this is a
quality of implementation issue, and that it would be preferable for
gcc to emphasize security over performance, as might be expected.
I don't think this is
Mohamed Shafi [EMAIL PROTECTED] writes:
I have read in the internals that indirect_jump and jump pattern are
necessary in any back-end for the compiler to be build and work
successfully. For any back-end there will be some limitation as to how
big the offset used in the jump instructions can
Persson Håkan [EMAIL PROTECTED] writes:
I'm having problem when making apache 2.0.63.
Wrong mailing list. gcc@gcc.gnu.org is about developing gcc.
[EMAIL PROTECTED] is about using gcc.
I don't know the answer to your question. It looks specific to your
distribution.
Ian
Mohamed Shafi wrote:
For a function call will i be able to implement long call/short call
for the same function at different locations?
Say fun1 calls bar and fun2 calls bar. I want short-call to be
generated for bar in fun1 and long-call to be generated in fun2.
Is to possible to implement this
On 4/10/08 8:16 AM, Fran Baena wrote:
Hi all,
i have a doubt about unSSA: is it allways possible to map back the
versioned variables to the original variable? If it could be possible,
is there an algorithm that describe this translation back?
It is not always possible. If there are
Florian Weimer [EMAIL PROTECTED] writes:
To me, dubious optimizations like this at the very least should
be optional and able to be turned off.
Why is this optimization dubious? We would need to look at real-world
code to tell, and so far, we haven't heard anything about the context in
Ian Lance Taylor wrote:
A theoretical argument for why somebody might write problematic code
is http://www.fefe.de/openldap-mail.txt .
I don't know where, or even if, such code is actually found in the
wild.
Ian
Fair enough question. The other question of course is how much this
On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote:
Ian Lance Taylor wrote:
A theoretical argument for why somebody might write problematic code
is http://www.fefe.de/openldap-mail.txt .
I don't know where, or even if, such code is actually found in the
wild.
Ian
Fair
Florian Weimer wrote:
Existing safe C implementations take a performance hit which is a factor
between 5 and 11 in terms of execution time. There is some new research
that seems to get away with a factor less than 2, but it's pretty recent
and I'm not sure if it's been reproduced
Joe Buck wrote:
On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote:
Ian Lance Taylor wrote:
A theoretical argument for why somebody might write problematic code
is http://www.fefe.de/openldap-mail.txt .
I don't know where, or even if, such code is actually found in the
wild.
Ian
Robert Dewar wrote:
An optimziation is dubious to me if
a) it produces surprising changes in behavior (note the importance of
the word surprising here)
b) it does not provide significant performance gains (note the
importance of the word significant here).
I find this optimization
Le vendredi 11 avril 2008 à 11:14 -0700, Jim Wilson a écrit :
Stelian Pop wrote:
#define PREFERRED_RELOAD_CLASS(X, CLASS)\
((CONSTANT_P(X)) ? EIGHT_REGS : \
(MEM_P(X)) ? EVEN_REGS : CLASS)
#define PREFERRED_OUTPUT_RELOAD_CLASS(X, CLASS) \
[EMAIL PROTECTED] wrote:
It's already been acknowledged that the source code is wrong
to assume that the compiler knows about wrapping of pointers.
The real issue at this stage is how to warn users who may be
using GCC and implicitly relying on its old behavior, without
unintentionally pushing
Snapshot gcc-4.1-20080414 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080414/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote:
[In fact,
after GCC does something to warn users about this, it'll be
much safer than those other compilers.]
For sure you want a warning, the compiler should never be
removing explicit tests in the users code without generating
Hi,
INSTALL/configure.html mentions ${gcc_tooldir}, just once. Here:
Cross-Compiler-Specific Options
The following options only apply to building cross compilers.
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains
a (subset of) the root
Hello Everyone,
I am currently working on OpenRISC port of GCC and I am trying to
add more constraints to the machine-dependent part and the default
number of constrant seem to be only 30 (and obviously I have more than
30 constraints, and thus it was failing). I tried making this a #define
Hi Mark
I'm not terribly familiar with this proposal.
Ben, to answer your original question, I don't think that lack of nested
address spaces is a fatal flaw, as long as the implementation otherwise
meets the spec, and as long as the implementation doesn't somehow make
it harder to add
Robert Dewar [EMAIL PROTECTED]
Richard Guenther wrote:
In absence of any declared object (like with this testcase where we just
have an incoming pointer to some unknown object) the compiler can
still assume that any valid object ends at the end of the address space.
Thus, an object
Hi there Balaji,
Here is the patch for it (if a value is not provided, then the
default value of 30 is assumed). I tried to build this for x86 and arm
and they seem to work fine with no problems.
Thanks for the patch. You should send your patch to gcc-patches,
though, not the main GCC
On Tue, 2008-04-15 at 00:06 +0200, Stelian Pop wrote:
- I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload
kept generating incorrect insn (putting constants into EVEN_REGS for
example). I'm not sure this is correct or if it hides something else...
It does sound odd, but
Joe Buck wrote:
On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote:
[In fact,
after GCC does something to warn users about this, it'll be
much safer than those other compilers.]
For sure you want a warning, the compiler should never be
removing explicit tests in the users code
This testcase extracted from libgcc2.c
int
sub (int i)
{
if (i == 0)
return 1 / i;
return i + 2;
}
compiled with -minline-int-divide-min-latency for IA-64 generates an
ICE.
tmp2.c:8: error: flow control insn inside a basic block
(insn 18 17 19 3 tmp2.c:5 (trap_if (const_int 1 [0x1])
Hello all,
I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no soft-float sqrt
libcall function. This is a big problem for MaverickCrunch as there are
no hard div or sqrt opcodes.
It seems that this is the only other
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote:
Hello all,
I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no soft-float sqrt
libcall function. This is a big problem for MaverickCrunch as there are
On Wed, Mar 26, 2008 at 02:38:53PM -0400, Daniel Berlin wrote:
On Wed, Mar 26, 2008 at 12:30 PM, Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Hi -
On Fri, Mar 14, 2008 at 10:41:42AM -0400, Frank Ch. Eigler wrote:
[...]
OK, /git/gcc.git appears ready for you to populate maintain.
On Mon, 14 Apr 2008 22:41:36 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote:
Hello all,
I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote:
Both FPA and VFP coprocessors implement sqrt opcodes:
So? Glibc does not rely on that. I've been building soft-float
versions of glibc for non-Crunch targets for scarily close to a decade
now, so this is clearly not the problem
On Mon, 14 Apr 2008 23:09:00 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote:
Both FPA and VFP coprocessors implement sqrt opcodes:
So? Glibc does not rely on that. I've been building soft-float
versions of glibc for
Ok, I give up.
I killed many hours trying to build a cross-compiling
x86_64-linux-uclibc-gcc, version 4.3.0.
After many WTF? moments I decided to go back and try
to build a cross-compiler which I already have,
just older version: I decided to build i486 one,
not x86_64.
Because I already have
Robert Dewar [EMAIL PROTECTED] writes:
An optimziation is dubious to me if
a) it produces surprising changes in behavior (note the importance of
the word surprising here)
b) it does not provide significant performance gains (note the
importance of the word significant here).
I find this
Jim Wilson [EMAIL PROTECTED] writes:
It seems odd that cfgrtl allows a conditional trap inside a basic block,
but not an unconditional trap. The way things are now, it means we need
to fix up the basic blocks after running combine or any other pass that
might be able to simplify a
To clarify what Richard means, your assertion that you have updated
SSA information is false.
If you had updated the SSA information, the error would not occur :).
How exactly are you updating the ssa information?
The general way to update SSA for this case would be:
For each statement you have
I put my version of the gcc conversion (which has all branches but no
tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update
it appropriately.
Note that i will not announce this anywhere until someone steps
forward to actually maintain it because i do not know GIT. Neither of
the
On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin [EMAIL PROTECTED] wrote:
To clarify what Richard means, your assertion that you have updated
SSA information is false.
If you had updated the SSA information, the error would not occur :).
How exactly are you updating the ssa information?
I
On Mon, Apr 14, 2008 at 11:44 PM, Jim Wilson [EMAIL PROTECTED] wrote:
Mohamed Shafi wrote:
For a function call will i be able to implement long call/short call
for the same function at different locations?
Say fun1 calls bar and fun2 calls bar. I want short-call to be
generated for bar
--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se
2008-04-14 06:34 ---
I think I was wrong.
--
gcc at magfr dot user dot lysator dot liu dot se changed:
What|Removed |Added
--- Comment #12 from amodra at bigpond dot net dot au 2008-04-14 07:19
---
Created an attachment (id=15476)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15476action=view)
proposed patch
I think we want something like the attached patch (as yet untested). Besides
the epilogue
--- Comment #13 from jakub at gcc dot gnu dot org 2008-04-14 07:30 ---
Couldn't it use hard_frame_pointer_rtx if frame_pointer_needed, to avoid the
load from 0(1) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
I understood -pedantic such that it gives warnings if a construct does not
match the Fortran standard. Currently, it seems to be partially used such but
also used to warn for non-Fortran-95 (!) constructs.
I think one should go through the pedantic sections in the source and check
whether they
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 09:18 ---
This is setting up the frame pointer which is needed for unwinding/debugging
on some targets. You can use -fomit-frame-pointer to avoid this.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 09:39 ---
Subject: Bug 35050
Author: sam
Date: Mon Apr 14 09:38:34 2008
New Revision: 134256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134256
Log:
gcc/ada/
PR ada/35050
* xref_lib.adb
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-14 09:48 ---
Thanks Rolf, patch applied in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 09:42 ---
Bug fixed in SVN version.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sam at gcc dot gnu dot org 2008-04-14 09:40 ---
Subject: Bug 20822
Author: sam
Date: Mon Apr 14 09:39:39 2008
New Revision: 134257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134257
Log:
2008-04-14 Rolf Ebert [EMAIL PROTECTED]
gcc/ada/
PR
--- Comment #7 from dmixm at marine dot febras dot ru 2008-04-14 10:55
---
Possible the
(isgreater(fabs(x), DBL_MAX) ? (signbit(x) ? -1 : 1) : 0)
will be fast with common finite numbers?
Question: in case of AVR target, is it possible to call extern
isinf() function regardless of
--- Comment #14 from amodra at bigpond dot net dot au 2008-04-14 10:25
---
Yes, I think you could use hard_frame_pointer_rtx in rs6000_emit_epilogue if
frame_pointer_needed, anywhere up to the point where gprs are restored.
Probably done best as a separate patch.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-14 11:06 ---
I propose that we do the following:
- add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is
only well-defined for !isinf (x) !isinf (y).
this doesn't result in a runtime penalty and informs
--- Comment #3 from ubizjak at gmail dot com 2008-04-14 11:12 ---
(In reply to comment #2)
This is setting up the frame pointer which is needed for unwinding/debugging
on some targets. You can use -fomit-frame-pointer to avoid this.
No, -fomit-frame-pointer uses %ebp.
%ebx is
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-04-14 11:27
---
Created an attachment (id=15477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15477action=view)
Possible fix
Sorry for the problems. Can you give this patch a try?
I'd wrongly assumed that one of the
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:11 ---
Subject: Bug 15915
Author: sam
Date: Mon Apr 14 12:10:16 2008
New Revision: 134261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134261
Log:
gcc/ada/
PR ada/15915
* sem_util.ads, sem_util.adb
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-14 12:11 ---
Subject: Bug 16098
Author: sam
Date: Mon Apr 14 12:11:06 2008
New Revision: 134262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134262
Log:
gcc/ada/
PR ada/16098
* sem_prag.adb
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 12:12 ---
This is fixed in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:12 ---
Fixed in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from david dot griffiths at gmail dot com 2008-04-14 12:25
---
Well there is no ecj1 - that's the problem I think. It didn't build it.
Presumably nobody has noticed this before because they are picking up an old
version of ecj1? Anyway, here's the -v output:
My target machine is an HP Jornada 720 (sa1100 based). Found this when trying
to boot from flashrom.
Using gcc 3.4.5 / glibc 2.3.5 memset.S is compiled without any errors. However
the kernel boots and freezes on memset.S (never returns from function). On
early_printk this is just seen as freezing
--- Comment #1 from kristoffer dot ericson at gmail dot com 2008-04-14
12:42 ---
Created an attachment (id=15478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15478action=view)
memset.o compiled with 3.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35931
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 12:43 ---
gcc 3.4 is no longer maintained. Please try 4.2.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 13:42 ---
Subject: Bug 18680
Author: sam
Date: Mon Apr 14 13:41:25 2008
New Revision: 134266
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134266
Log:
gcc/ada/
PR ada/18680
* sem_prag.adb
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-04-14 13:56 ---
The links on the C++0x status web pages have been fixed.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2008-04-14 14:17 ---
Yes. Note that it requires an argument of *class* type, not *pointer to
class* type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
--- Comment #2 from bangerth at dealii dot org 2008-04-14 14:28 ---
(In reply to comment #1)
I don't think this is a bug as you did not mark the operations on s
as atomic.
Yes, exactly.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:21 ---
I too believe that z1.cc is valid. icc accepts it.
Not a regression, the code fails back to 2.95.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:34 ---
You are asking for too much. The problem is that in your first example
the compiler knows that you want to call the grab() function and therefore
can give you an informative error message. But in the second example it
The following program generates an ICE.
program FA0005
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
CHARACTER(1) CDA1(10)
INTEGER IDA(10)
CDA1 = CHAR ( IDA, KIND(A )) !fails
CDA1 = CHAR ( IDA )
I finally got to the bottom of some unexpected behavior from the
amreb-linux target of the 4.1.2 compiler.
I'm hoping that someone can say if is this an optimization bug
(optimizes away too much) or a problem with this code.
extern int ReadChar( char *p);
/* grab a character from input
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-14 16:21 ---
Confirm. The following assert seemingly fails:
gcc_assert (lse.ss == gfc_ss_terminator
rse.ss == gfc_ss_terminator);
--
burnus at gcc dot gnu dot org changed:
What
I just tried to compile the GNU C compiler version
4.4 snapshot 20080411 with the Intel C compiler.
The Intel compiler said
gcc-4.4-20080411/gcc/fold-const.c(14101): warning #592: variable arg1 is used
before its value is set
The source code is
tree arg1 = arg1;
if
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 16:46 ---
This is fixed in the current SVN tree.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html
In gcc-4.0.0 search was instantiated in string-inst.cc:
// Used in str::find.
template
const C*
search(const C*, const C*, const C*, const C*, bool(*)(const C, const C));
and if a user compiled their code with -frepo, they can
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html
In gcc-4.0.0 search was instantiated in string-inst.cc:
// Used in str::find.
template
const C*
search(const C*, const C*, const C*, const C*, bool(*)(const C, const C));
and if a user compiled their code with -frepo, they can
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** This bug has been marked as a duplicate of 35934 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** Bug 35935 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
--- Comment #2 from jb at gcc dot gnu dot org 2008-04-14 18:09 ---
Well, your test case is invalid anyway (i0 is referenced before being defined).
Here's a standard conforming portable version that compiles with -Wall
-pedantic -std=f2003:
program short_test_inf
Mariusz Janiak wrote:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:
Assembler messages:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:123:
Error: SP not allowed in register list -- `stmea a1!,{v1-v7,fp,ip,sp,lr}'
John Breitenbach wrote:
char can't be less-than zero. However, can't make up my mind as to
whether or not it should be allowed to optimize away the
post-increment.
It is not OK to optimize away the post-increment. This is a gcc
optimization bug.
Jim
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-04-14 18:51
---
Subject: Bug 32972
Author: tkoenig
Date: Mon Apr 14 18:50:57 2008
New Revision: 134286
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134286
Log:
2008-04-14 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #1 from jb at gcc dot gnu dot org 2008-04-14 18:55 ---
Confirmed.
This could be a bit tricky to get right. OTOH Fortran is fortunate enough that
there are real strings and not char arrays like in C, so from a user
perspective it should be pretty transparent. But certainly
/home/sam/tmp/gcc-avr/./gcc/xgcc -B/home/sam/tmp/gcc-avr/./gcc/
-B/home/sam/local/i386-linux/avr/bin/ -B/home/sam/local/i386-linux/avr/lib/
-isystem /home/sam/local/i386-linux/avr/include -isystem
/home/sam/local/i386-linux/avr/sys-include -g -O2 -mmcu=avr31 -O2 -g -O2
-DIN_GCC
$ gfortran -g -fdefault-integer-8 char_result_5.f90
$ gdb ./a.out
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO
With a clean svn checkout (gcc version 4.4.0 20080414 (experimental) (GCC)),
--enable-languages=c,c++
I can successfully make bootstrap and make install, and the resulting
compiler seems to work.
However, trying to 'make check' results in the output below:
~/gccbin$ make check
autogen -T
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-14 19:36 ---
The last failures are white space differences and can be ignored, the BSD sed
causes them.
Anyways you should be using make -k check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35938
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-14 19:37 ---
Ah. Well, I see that this is the second time I broke stuff on stdint.h.
I must fix this correctly, apparently.
Mine...
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from andreast at gcc dot gnu dot org 2008-04-14 19:42
---
happens on sparc-solaris2.8 as well. sparc-solaris2.10 is not affected.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-14 19:45 ---
The right way around...
See the attached file in comment #7 of PR32770.
Yes, I'm trying to make indiviual PRs of all failures that
I see.
--
tkoenig at gcc dot gnu dot org changed:
What
1 - 100 of 129 matches
Mail list logo
