James E Wilson
Jonathan Bastien-Filiatrault wrote:
* We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On this
DSP, there are two 40-bits accumulators. How do we make GCC take
advantage of this and which machine mode do we use ?
GCC has little support for non-power-of-2 sized
Per Bothner wrote:
Mark Mitchell wrote:
Building libjava takes forever on any platform, relative to the rest of
the compiler build.
[...]
One way to speed up libcgj compilation by quite a bit would be to
compile more than one .java file at a time. For example:
gcj -c java/util/*.java
Hi.
Looks good to me.
Also I hope to post new pragma handling mechanism patch in near
future. Currently I'm trying to find sparc/solaris box to make some
tests. This will require some minor changes to the parser. In
particular I plan to remove threadprivate handler from FE to a
separate handler
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it in yet,
according to the Wiki:
# Autovectorization Enhancements
Items 1.4, 2.1, 2.3 (1.3)
Items 1.4 and 2.3 are in,
celeron_obj-gcc-3.4.3 /export/users/jordan/compile/gcc/gcc-3.4.3/config.guess
i386-pc-solaris2.8
celeron_obj-gcc-3.4.3 which gcc
/usr/local/bin/gcc
celeron_obj-gcc-3.4.3 gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.3/specs
Configured with:
On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
# CFG Transparent Inlining, Profile-Guided Inlining (1.3)
This one was submitted on April 29, but nobody has reviewed it.
# Compilation Level Analysis of Types and Static Variables (1.3)
# Pre-Inline Optimizations (1.3)
These two depend on
Steven Bosscher wrote:
On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
# CFG Transparent Inlining, Profile-Guided Inlining (1.3)
This one was submitted on April 29, but nobody has reviewed it.
When this goes in, I'll submit the conversion of rest_of_compilation to
use the pass manager (I
Ranjit Mathew wrote:
Ideally, there'd be a configure flag to control chunking.
Note that libgcj already supports an --enable-libgcj-multifile
configuration option that coarsely attempts to do the above.
See:
http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html
I tried this out
On Wed, May 04, 2005 at 01:02:18AM -0700, Richard Henderson wrote:
On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
For that instruction, instantiate_virtual_regs_in_insn
enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
is entered, where if (safe_insn_predicate
The __builtin_isless, __builtin_islessequal functions are provided as
implementations of standard C99 functions 'isless', 'isgreater'. Please,
explain why gcc for mips implements them via instructions
c.lt.FMT and
c.le.FMT
instead of
c.olt.FMT and
c.ole.FMT.
I am building GCC 3.2 for target=sparclet-aout.
Though there is no issue with C however the C++ global objects are not getting
initialized. I have posted a mail to libstdc++ mailing list and have tried all
that was suggested.
http://gcc.gnu.org/ml/libstdc++/2005-04/msg00238.html
I have
Satendra Pratap [EMAIL PROTECTED] writes:
Please don't send mail to so many mailing lists. In particular
[EMAIL PROTECTED] is not a mailing list, and I've dropped it from the CC.
** Legal Disclaimer
This email may contain confidential and
Hi
I can not control the disclaimer that is being appended by our office
mailserver . Hence resending the mail from my gmail account.
Please help.
--
I am building GCC 3.2 for target=sparclet-aout.
Though there is no issue with C
Ranjit == Ranjit Mathew [EMAIL PROTECTED] writes:
Ranjit Note that libgcj already supports an --enable-libgcj-multifile
Ranjit configuration option that coarsely attempts to do the above.
Ranjit See:
Ranjit http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html
--enable-libgcj-multifile
Original Message
From: Satendra Pratap
Sent: 05 May 2005 15:23
Hi
I can not control the disclaimer that is being appended by our office
mailserver . Hence resending the mail from my gmail account.
Very considerate of you, thanks!
I am building GCC 3.2 for target=sparclet-aout.
I am experimenting with the FORTH langauge, and I would like a front-end to
be added to GCC. I think I can get most of the parts down, but how can I
generate a tree that can be used in the code-generator?
Samuel Lauber
--
___
Surf the Web in a faster,
Satendra Pratap [EMAIL PROTECTED] writes:
I can not control the disclaimer that is being appended by our office
mailserver . Hence resending the mail from my gmail account.
Thanks.
After all this I got down to breaking the problem into a
compiler/linker (or my understanding) issue. After
On May 4, 2005, at 11:49 PM, Dorit Naishlos wrote:
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it in yet,
according to the Wiki:
# Autovectorization Enhancements
Items 1.4, 2.1,
Original Message
From: Ian Lance Taylor
Sent: 05 May 2005 16:38
Dave Korn [EMAIL PROTECTED] writes:
CONSTRUCTORS is only valid for formats such as ECOFF and XCOFF. Read
the bit in the ld manual more closely:
---
`CONSTRUCTORS'
Per Bothner writes:
We could also save time by making --disable-static the default.
Building static libraries is not very useful on other than
embedded-class systems.
I empahsisstrongly/emphasis agree.
Andrew.
The libtool folks seem to be making some progress in attacking our
problems. I had forwarded them Richard's data on the libtool
performance problems.
When they have something ready to try, I hope someone on our end
who knows about this stuff (Alexandre? Java folks?) can try it out.
I'd send a
On Wed, 2005-05-04 at 22:40 -0700, Mark Mitchell wrote:
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it in yet,
according to the Wiki:
# Structure Aliasing Part II
On Thu, May 05, 2005 at 12:19:07PM -0400, Daniel Berlin wrote:
On Wed, 2005-05-04 at 22:40 -0700, Mark Mitchell wrote:
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it
On Thursday, May 5, 2005, at 11:28 AM, ji tai wrote:
why i can't send mail?
Your email came though, so apparently you can with this account. If
there is another account you cannot send from, you will have to read
the email bounce message, it should describe why you would be unable to
send
On May 5, 2005, Andrew Haley [EMAIL PROTECTED] wrote:
Per Bothner writes:
We could also save time by making --disable-static the default.
Building static libraries is not very useful on other than
embedded-class systems.
I empahsisstrongly/emphasis agree.
The savings of creating static
Dorit Naishlos wrote:
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it in yet,
according to the Wiki:
# Autovectorization Enhancements
Items 1.4, 2.1, 2.3 (1.3)
Items 1.4 and
Steven Bosscher wrote:
On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
# CFG Transparent Inlining, Profile-Guided Inlining (1.3)
This one was submitted on April 29, but nobody has reviewed it.
# Compilation Level Analysis of Types and Static Variables (1.3)
# Pre-Inline Optimizations (1.3)
On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote:
The savings of creating static libraries would be small if we
refrained from building non-PIC object files.
But still largely useless. Who in their right mind is going to
use an 83MB static library when a shared library is
On Wed, 2005-05-04 at 20:41 -0400, Diego Novillo wrote:
On Wed, May 04, 2005 at 05:08:23PM -0700, James E Wilson wrote:
We can perhaps handle this well in the tree-aliasing code (if
it handled restrict at all), but it would be difficult to
handle this well in the RTL aliasing code.
It
Well, if you don't dynamically load classes, statically linking this 83Mb
behemoth enables you to get rid of most of it. On Windows, with MinGW, where
this is possible, I build a shared library (a python extension) that is
statically linked with libgcj.a and the resulting .dll is only 4.6MB in
Hi,
I finally got time (darn exams!) to file a bug on this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
This is the bug where two libs in the same ELF image compiled using
different C++ ABIs can interfere even when not linked to each other,
because the compiler emits symbols from the STL
[EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in [EMAIL PROTECTED]:
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that infinitely loops,
or should it be
Kai == Kai Henningsen [EMAIL PROTECTED] writes:
Kai As a QOI issue, it would be nice if such a situation caused a
Kai warning (ignoring volatile cast ... or something like that).
Kai It's rather dangerous to have the user believe that this worked
Kai as intended when it didn't.
Definitely.
[EMAIL PROTECTED] (Kai Henningsen) writes:
| [EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in [EMAIL PROTECTED]:
|
| Mike Stump wrote:
| int avail;
| int main() {
| while (*(volatile int *)avail == 0)
| continue;
| return 0;
| }
|
|
| Ok, so, the question is,
On 2005-05-06, at 04:04, Sam Lauber wrote:
There are a few diffciulties here, particularly with addressing the
open stack in an efficient way.
This problem is probably going to get a little off-topic for this
group, and it may be better to discuss this on comp.lang.forth.
I wasn't asking about the
Hi, all,
Is there anyone familiar with the check routine
check_ext_dependent_givs defined loop.c, and give me
an example explaining why it is needed.
Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.
On May 5, 2005, at 5:23 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in
[EMAIL PROTECTED]:
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that
On Thursday, May 5, 2005, at 02:53 PM, Andi Vajda wrote:
I wish the same were possible on Linux and Mac OS X but I have not
been able to create a shared library that is statically linked against
libgcj.a
Should just work, though, you don't want to link -static built objects
into a .dylib, you
From: Mark Mitchell
Sent: Friday, April 29, 2005 12:00 PM
Now that GCC 4.0 is out the door, I've spent some time looking at the
status of the 3.4 branch. As stated previously, I'll be doing a 3.4.4
release, and then turning the branch over to Gaby, to focus
exclusively on 4.0/4.1. [...]
Hi all,
I would like to know how many stages are there ?
What's the first stage ?
Thanks
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-05
06:27 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
07:11 ---
I'm confused by this report. You use:
*((int32_t *) a.unaligned_int) = 0x123456;
which reads the value of a.unaligned_int, casts it from an integer
to a pointer, and then dereferences the pointer.
The following program causes my gfortran to throw an internal compiler
error. The problem does not occur for N=10, so I gather that it happens
due to a maximum limit on parameter array size.
[niels:~]% cat test.f
MODULE TEST
integer ilocal
integer,parameter :: N=50
--
What|Removed |Added
Known to fail||3.4.3 3.3.5
Known to work||2.95.2 2.96
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
Thread model: posix
gcc version 4.0.0
chandra.anuradha% gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure
--- Additional Comments From asuraparaju at gmail dot com 2005-05-05 09:14
---
Created an attachment (id=8822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8822action=view)
A class that uses MMX intrinsics to compute block differences between two video
frames
--
following code doesnt compile with command gcc -c -O2 -o a.o a.c. It compiles
with any other -O flag. The error is:
a.c: In function `main':
a.c:7: error: inconsistent operand constraints in an `asm'
Here is the code:
typedef struct {
unsigned long sig[2];
} sigset_t;
static __inline__
When using -march, wrong tuning flags are selected.
E.g., -march=armv4t selects 'tune_flags' for arm600, instead of
arm7tdmi (or similar). The error is in arm_override_options().
When -march is given, (sel - all_architectures) is calculated.
In contrast, -mcpu calculates (sel - all_cores). This
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:49 ---
(In reply to comment #2)
You are completely right, the code above merely demonstrates what happens when
one writes to an illegal address. The correct version,
*((int32_t *) a.unaligned_int32) = 0x123456;
--- Additional Comments From laurent at guerby dot net 2005-05-05 11:56
---
Seems to be fixed on HEAD as of LAST_UPDATED: Thu May 5 08:05:40 UTC 2005
on x86 and x86_64-linux:
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00284.html
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:56 ---
(In reply to comment #2)
Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be
aligned.
It is not a bug then,
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
12:01 ---
Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be
aligned.
Right.
It is not a bug then, but merely a
--- Additional Comments From tsv at solvo dot ru 2005-05-05 13:13 ---
I put my code into try/catch block and the exception was successfully caught.
How general EH is supposed to be called? Could it be arch specific?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
the code like this:
unsigned short swap16(unsigned short x)
{
asm volatile (xchgb %b0, %h0 : =q (x) : 0 (x));
return x;
}
produces:
swap16: xchgb %dil, %di == %di isn't valid high 8-bit form.
movzwl %di, %eax
ret
IIRC the %rdi, %rsi, %rsp, %rbp
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
13:49 ---
`a', b, c, or d register for the i386. For x86-64 it is equivalent to `r'
class (for 8-bit instructions that
do not use upper halves).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398
--- Additional Comments From giovannibajo at libero dot it 2005-05-05
13:54 ---
The compiler is allowed to generate syntectic methods as lazy as possible,
which is upon the first actual use. Thus, this is not a bug.
--
What|Removed |Added
--- Additional Comments From schwab at suse dot de 2005-05-05 14:14 ---
I'm seeing the same error in some C++-only packages. The smallest example I
could find is jikes
http://prdownloads.sourceforge.net/jikes/jikes-1.22.tar.bz2:
g++ -O2 -fmessage-length=0 -Wall -o jikes ast.o
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:22
---
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
#define REG_CLASS_FROM_LETTER(C)\
((C) == 'r' ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:24 ---
(In reply to comment #2)
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
Yes see comment #1 which is a
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc ICEs when
compiled on AIX:
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
: In function 'void test01()':
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
:24: error: BB 3 can not throw but has EH edges
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:34
---
Created an attachment (id=8824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8824action=view)
pre-processed source for 12077.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:35 ---
Also happens on ppc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:37
---
The failure appeared April 25.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
bash-2.05b$ cat tst.c
extern double floor (double);
int
f (float minX)
{
return (int)floor(minX);
}
bash-2.05b$ ./cc1 tst.c -Os
f
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
f
tst.c: In function f:
tst.c:6: internal compiler error: in
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:41
---
(In reply to comment #3)
(In reply to comment #2)
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:43 ---
Time to update the sources.
This is a dup of bug 21282.
*** This bug has been marked as a duplicate of 21282 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:43 ---
*** Bug 21400 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:55 ---
Confirmed, reduced testcase:
typedef struct __FILE FILE;
extern C int fputs(const char *, FILE *);
struct a { ~a(); };
void f(FILE* file)
{
a b;
const char* str = a;
fputs(str, file);
}
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
15:01 ---
A slightly more reduced testcase:
typedef struct __FILE FILE;
extern C int fputs(const char *, FILE *);
void f(FILE* file) throw()
{
const char* str = a;
fputs(str, file);
}
The problem is somehow
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|SUSPENDED
The type of a function interface is not taken over from the
MODULE PROCEDURE's which constitute the INTERFACE.
---BUG.f90--- start
module interface_vs_functions_bug
implicit none
private
interface ex1 ! fails, but should be ok
module procedure func1, func2
end interface
The attached C source gives wrong output when compiled with inlined functions
(-O3 or -O2 -finline-functions) with gcc-4.1-20050501 or gcc-4.0.0. Compiling
gives the following warning twice:
dereferencing type-punned pointer will break strict-aliasing rules
The expected output is 0 0, the actual
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
15:36 ---
Subject: Bug 21284
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-05 15:36:34
Modified files:
gcc:
--- Additional Comments From gcc at arbruijn dot dds dot nl 2005-05-05
15:38 ---
Created an attachment (id=8825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8825action=view)
C source exposing problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
15:42 ---
Subject: Bug 21284
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-05 15:42:05
Modified files:
gcc: ChangeLog
gcc/config/avr :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:13 ---
unsigned char * and char * are in two different aliasing sets while char
and unsigned char are in the
same one, well char is every aliasing set.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:25 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:29 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00425.html.
--
What|Removed |Added
--- Additional Comments From aph at gcc dot gnu dot org 2005-05-05 16:33
---
This may be a dup of 20606
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:40 ---
*** This bug has been marked as a duplicate of 18108 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:40 ---
*** Bug 21401 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
GCC target triplet|i686-pc-linux-gnu configured|i686-pc-linux-gnu
|with: ../gcc-4.0.0/configure|
|--pref
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-05 16:49
---
This indeed can be fixed. Instead of
#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo. */
exit(0);
#else
do something like
#if
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:53 ---
Note C and C++ aliasing rules are being violated in the source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21395
A canadian cross of the compiler failed as it tried to link fix-header.
It's using a mix of build and host object files to build this. The Makefile
reads:
# This is nominally a 'build' program, but it's run only when host==build,
# so we can (indeed, must) use $(LIBDEPS) and $(LIBS).
I,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
17:00 ---
Note with the following code, I get back to what it is without -mmx:
union b
{
int i[2];
__m64 j;
}a;
__m64 sum = _mm_set_pi32(0, 0);
for (int j=0 ; j yl ; j++)
{
This test case fails for GCC 3.3.x and GCC 3.4.x at any level of optimization
other than -O0:
extern void abort (void);
char buffer[20];
void foo (char *p, const char *q)
{
int i = 0;
while (q[i])
p[i] =
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-05 17:11
---
This could be fixed by expanding __builtin_va_start, __builtin_va_copy
and __builtin_va_end in or soon after pass_stdarg.
Then SRA etc. can also optimize va_list handling.
On the other side, tree-stdarg.c
--- Additional Comments From schlie at comcast dot net 2005-05-05 17:19
---
(In reply to comment #2)
unsigned char * and char * are in two different aliasing sets while char
and unsigned char are in the same one, well char is every aliasing set.
Then I can't help but wonder if it may
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-05-05 17:23 ---
Bug 21306 is not the same bug. The attached patch FIX1 fixes the
test cases for this bug, but not for 21306 - you will need to look
at the test case for that bug.
--
--- Additional Comments From ericw at evcohs dot com 2005-05-05 17:25
---
(In reply to comment #2)
Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug
(also a target which probably doesn't provide REAL 8).
As a side note, it is known that Fortran does not
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-05 17:49
---
A workaround is to replace the body of the loop with:
{
p[i] = q[i];
i++;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21404
--- Additional Comments From law at redhat dot com 2005-05-05 18:01 ---
I know what's causing this and I'm testing a fix now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
--- Additional Comments From ericw at evcohs dot com 2005-05-05 18:09
---
Will someone with the requisite permissions please set this bug to NEW? This has
been confirmed.
Thanks
Eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
18:12 ---
This is invalid, there is no sequence point between the access of i and the
increment of i so either can
be first.
With -W -Wall we get a warning:
t.c:8: warning: operation on `i' may be undefined
***
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
18:12 ---
*** Bug 21404 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
1 - 100 of 150 matches
Mail list logo
