Ivan Novick wrote:
Hello,
How come the following code would not be considered a Warning?
Surely there is no possible way this would be intentional?
if (x4);
x++;
When you consider macro expansion, it could:
#if SIZEOF_LONG == 4
#define WARN_FOR_BIG_VALUES \
printf (hey, x is too
Ivan Novick [EMAIL PROTECTED] writes:
How come the following code would not be considered a Warning?
Try -Wextra.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5
* Gerald Pfeifer:
On Sun, 31 Jul 2005, Daniel Berlin wrote:
For code.
I have never seen such claims made for documentation, since it's much
easier to remove and deal with infringing docs than code.
I have seen such statements, by RMS himself.
The official position might have changed (e.g.
Not that it come as a big surprise, but I successfully compiled
gcc-3.4.4 on darwin 6.8 (as specified by uname -a)
config.guess reports
powerpc-apple-darwin.6.8
gcc -v reports
Configured with ../gcc-3.4.4/configure --program-suffix=-3.4.4
--enable-languages=c,c++,f77,java,objc
Thread model:
Hello,
Is it true that in a SET, a search for a _use_ of a register
in the LHS should be done only inside a memory address?
Like in this SET:
(set (mem:SI (plus:DI (reg:DI 159)
(reg/v/f:DI 150 )))
(subreg/s:SI (reg/v:DI 142 [ j ]) 4)) -1 (nil)
Registers 142, 159 and 150 are
Leehod Baruch wrote:
Hello,
Is it true that in a SET, a search for a _use_ of a register
in the LHS should be done only inside a memory address?
Also within the second and third arguments of a ZERO_EXTRACT. And its
first argument may be a MEM, in which case you should look into it.
Look
Hi to everyone,
I cannot figure out how variadic function are
practically implemented. In the called (variadic)
function after few 'push's %rsp is suddenly
decremented by N bytes: the red area starts 128 bytes
below the NEW rsp or %rsp-N above?
Is it possible to find the register save area and
Hello,
can anyone tell me how to use option -m64 in
g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)?
when I input the command line:
g++ -m64 -o test test.cc
error message was output:
/tmp/ccyjpGIh.o(.text+0x900): In function `main':
: relocation truncated to fit: R_X86_64_32
.
.
.
best regards
Andreas Schwab wrote:
Try -Wextra.
Ah thanks! I have already lost time several times due to this
almost invisible mistake and I didn't know -Wextra would catch it.
However, it seems to only work for the C compiler, not for C++.
(Using GCC 3.4.4)
(Oops, sorry Andreas, I actually meant to only
* Matteo Emanuele:
Is it possible to find the register save area and the
overflowing arguments within the called function
without using %ebp (that means with
-fomit-frame-pointer set) and knowing nothing of the
caller?
You mean, if the caller called the function as it were a non-variadic
David Edelsohn wrote:
Paolo Bonzini writes:
Paolo I'm testing a patch that does this replacement, and I can post it
Paolo tomorrow morning. It has triggered only a dozen times so far (half in
Paolo libgcc, half in the compiler), but it may be worth keeping it.
It
Hello,
sorry for the late answer.
Vlad promised to update it to use df.c once it wasn't 1% slower, which
would make it easily reusable elsewhere, but never did.
Of course, you could reuse it without that, but then someone will
invariably come along and mess with it.
Ok I understand that
On Tue, 2005-08-23 at 16:44 +0200, Bernd Schmidt wrote:
Andreas Krebbel wrote:
Ok I understand that implementing the special lifeness analyzers in global
alloc
using the df.c framework would ease reusing it somewhere else. But my
question
was more basic.
So do you agree that using
Daniel Berlin wrote:
If you make them all defined, then it's going to be live where it wasn't
before, even though it's not really *used* over those paths.
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
Bernd
On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
int foo (int n)
{
int a;
while (--n)
a = n;
return a;
}
Not knowing n, how can you be sure whether a is uninitialized for
On Tue, 2005-08-23 at 17:06 +0200, Bernd Schmidt wrote:
Daniel Berlin wrote:
If you make them all defined, then it's going to be live where it wasn't
before, even though it's not really *used* over those paths.
The idea is to put the initialization insns only on the paths where the
Leehod Baruch [EMAIL PROTECTED] writes:
Is it true that in a SET, a search for a _use_ of a register
in the LHS should be done only inside a memory address?
See refers_to_regno_p for an example of a function which looks for
all uses of a register.
Ian
On Mon, 22 Aug 2005, Dale Johannesen wrote:
There is some clever code in convert_to_real that converts
double d;
(float)floor(d)
to
floorf((float)d)
...
Comments? Should I preserve the buggy behavior with -ffast-math?
Good catch. This is indeed a -ffast-math (or more precisely a
--- Florian Weimer [EMAIL PROTECTED] wrote:
* Gerald Pfeifer:
On Sun, 31 Jul 2005, Daniel Berlin wrote:
For code.
I have never seen such claims made for documentation, since it's much
easier to remove and deal with infringing docs than code.
I have seen such statements, by RMS
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
Good catch. This is indeed a -ffast-math (or more precisely a
flag_unsafe_math_optimizations) transformation. I'd prefer to
keep these transformations with -ffast-math, as Jan described them
as significantly helping SPEC's mesa
Hi Guys,
There is a problem with unit-at-a-time compilation and DWARF debug
info generation. Consider this small test case which has been
derived from GDB's observer.c source file:
int observer_test_first_observer = 0;
int observer_test_second_observer = 0;
int
On Aug 23, 2005, at 9:53 AM, Richard Henderson wrote:
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
Good catch. This is indeed a -ffast-math (or more precisely a
flag_unsafe_math_optimizations) transformation. I'd prefer to
keep these transformations with -ffast-math, as Jan
On Tue, 2005-08-23 at 07:44, Bernd Schmidt wrote:
Jim Wilson once suggested we should just emit insns to make sure every
register is initialized and be done with it - problem solved. I had
started to work on that, if people think it's a good idea I can dig that
stuff out again.
I'd like
--- Tom Tromey [EMAIL PROTECTED] wrote:
KC == Kelley Cook [EMAIL PROTECTED] writes:
KC 2005-08-19 Kelley Cook [EMAIL PROTECTED]
KC * Makefile.am (ACLOCAL_AMFLAGS): Also include ...
KC * acinclude.m4: Delete. Extract CHECK_FOR_BROKEN_MINGW_LD to
...
KC * mingwld.m4: ... this new
Thanks Tom for pointing this out. We have to all keep these autotools
versions synced: it bugs everybody to have extraneous differences in
trees due to version mis-match.
Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
throughout the tree.
How did this happen?
I propose
This certainly wasn't my intention, please change it to 79L.
How's this? It passes both m32c and x86-64.
2005-08-23 DJ Delorie [EMAIL PROTECTED]
* gcc.c-torture/execute/stdarg-2.c (main): Make sure long
constants have the L suffix.
Index: gcc.c-torture/execute/stdarg-2.c
Thanks Tom for pointing this out. We have to all keep these
autotools versions synced: it bugs everybody to have extraneous
differences in trees due to version mis-match.
Could we modify the CVS commit filters to *require* the right
versions? If it detects a commit with the wrong version (at
For this code (from PR23525):
extern int waiting_for_initial_map;
extern int cp_pipe[2];
extern int pc_pipe[2];
extern int close (int __fd);
void
first_map_occurred(void)
{
close(cp_pipe[0]);
close(pc_pipe[1]);
waiting_for_initial_map = 0;
}
gcc -march=i686 -O2 generates:
Steven Bosscher wrote:
On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
int foo (int n)
{
int a;
while (--n)
a = n;
return a;
}
Not knowing n, how can you be sure
Paolo Bonzini [EMAIL PROTECTED] wrote:
While researching who is really using flow's computed LOG_LINKS, I
found
a define_split in the rs6000 back-end that uses them through
find_single_use. It turns out the only users are combine, this split,
and a function in regmove.
See also:
On Tue, Aug 23, 2005 at 11:40:16AM -0700, Dan Nicolaescu wrote:
Is there a performance difference between the movl + movl and pushl
code sequences?
In this case, no.
If not maybe then gcc should generate pushl for -O2
too because it is smaller code.
It's not quite as simple as you make out.
Dan,
Is there a performance difference between the movl + movl and
pushl code sequences?
Not in this example, but movl is faster in some circumstances than pushl. A
sequence of pushl has an implicit dependency chain on %esp, as it changes after
each pushl, whereas a sequence of movl
KC == Kelley Cook [EMAIL PROTECTED] writes:
KC Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
KC throughout the tree. I propose standardizing the entire tree on 1.9.6,
KC as it is the current release; moreover the 1.9 branch has only had a
KC few minor patches since 1.9.6 was
Two things I'm wondering about:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
2. Why are there no sse equivalents of those functions, ones that
operate on 128 bit values (i.e.,
DJ Delorie wrote:
This certainly wasn't my intention, please change it to 79L.
How's this? It passes both m32c and x86-64.
2005-08-23 DJ Delorie [EMAIL PROTECTED]
* gcc.c-torture/execute/stdarg-2.c (main): Make sure long
constants have the L suffix.
OK.
--
Mark
Steven Bosscher wrote:
On Monday 22 August 2005 14:46, Leehod Baruch wrote:
Hello,
I would like to know if someone knows a suitable branch for the sign
extension optimization pass.
Why not just maintain it in a local tree and post refined
versions every now and then, until stage 1 for GCC
Benjamin Kosnik [EMAIL PROTECTED] writes:
Could we modify the CVS commit filters to *require* the right
versions? If it detects a commit with the wrong version (at least,
assuming the old rev had the right version), it can just reject it.
Dunno if this is possible, but this would be
On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
Because the interface you're actually supposed to be using
is
Snapshot gcc-3.4-20050823 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050823/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050823
You'll find
On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
As Jim points out, we may have to do that for IA64 anyway, so we could
consider doing it on all targets. Dan is correct that this can
introduce new code that won't be eliminated. One question is how often
this is going to occur in
On Tue, 2005-08-23 at 22:10 -0500, Peter Bergner wrote:
On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
As Jim points out, we may have to do that for IA64 anyway, so we could
consider doing it on all targets. Dan is correct that this can
introduce new code that won't be
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-23
06:06 ---
I don't care about this anymore. Perhaps this should be an invalid bug, oh
well.
--
What|Removed |Added
Compiling this code:
extern int waiting_for_initial_map;
extern int close (int __fd);
void
first_map_occurred(void)
{
close(cp_pipe[0]);
close(pc_pipe[1]);
waiting_for_initial_map = 0;
}
using -O2 -march=i686 4.[01] generate sequences like:
movlcp_pipe, %eax
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
07:28 ---
Subject: Bug 22043
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 07:28:26
Modified files:
gcc: ChangeLog expr.c gimplify.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
08:15 ---
Subject: Bug 23511
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 08:15:19
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23
09:50 ---
Changed synopsis and component. Added keyword.
Interestingly, the following is (wrongly) accepted:
- 8 -
interface MyRunnable
{
public void run( );
}
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:56
---
When push_back notices that s1 is shared and clones it (via reserve), creates
a new string (not shared) of capacity = original size (according to an
exponential grow policy) but unrelated to the original capacity.
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:57
---
Thanks Chris. I will work on this issue.
--
What|Removed |Added
AssignedTo|unassigned at
--- Additional Comments From oakad at yahoo dot com 2005-08-23 10:27
---
I was dealing with packed structs in this case. Are you sure that
-mstrict-align will not break packing? And I'm talking of both inter- and
intra-struct packing, as in packed array of packed structs.
--
--- Additional Comments From pcarlini at suse dot de 2005-08-23 10:22
---
Of course, first copy-constructing s2, then calling s1.reserve also makes sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
10:40 ---
Subject: Bug 23358
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 10:40:14
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:10 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:11 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-23
11:25 ---
You need to use -gnato if you want an exception here.
This test case in any case is handled as expected in GCC 4.1 as far as I can
see, unless the mingw build is too old or using non standard sources, but
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:26 ---
This is an ra issue. There is only one load from pc_pipe[1] which x86 does not
like. There is an
actually a different on the tree level but the ra should have handled that but
it does not.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:27 ---
You really should know that we only care about code size at -Os. We care about
performance
regressions though at -O2.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:34 ---
(In reply to comment #20)
gcc shouldn't always error out in this situation. For suspend to disk, we
clobber all registers when restoring the original cpu context after copying
back
the original kernel
--- Additional Comments From nigel at suspend2 dot net 2005-08-23 11:31
---
gcc shouldn't always error out in this situation. For suspend to disk, we
clobber all registers when restoring the original cpu context after copying back
the original kernel context. We could lie to gcc and say
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
--- Additional Comments From ncunningham at cyclades dot com 2005-08-23
11:41 ---
Subject: Re: GCC should error out when clobbering
the stack pointer and frame pointer
The function needs to be inlined - the return value especially is
pivotal in the transition from the booted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:41 ---
This is a dup of bug 23454.
Also please don't copy and paste the preprocessed source into gccbug. Instead
wait to the
confirmation email and attach it to the bug in the web interface or attach it
(and
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:42 ---
*** Bug 23526 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
,f95 --prefix=/
home/gates/pinskia/linux --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.1.0 20050823 (experimental)
So the error message is also a regression but that makes this minor as the
first error message is
correct.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:46 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
The attached testcase compiles and runs correctly with gcc 3.3.4, but gives the
following compilation errors with gcc 3.4.4:
hashtest.cxx: In function `int main()':
hashtest.cxx:11: error: cannot convert `int*' to `std::pairconst int, int*' in
initialization
hashtest.cxx:12: error: no matching
--- Additional Comments From mattias dot ellert at tsl dot uu dot se
2005-08-23 12:01 ---
Created an attachment (id=9563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9563action=view)
The testcase that exemplifies the error
It fails with gcc 3.4.4 but works correctly with gcc
--- Additional Comments From mattias dot ellert at tsl dot uu dot se
2005-08-23 12:02 ---
Created an attachment (id=9564)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9564action=view)
Patch against the gcc 3.4.4 STL headers
With this patch applied to gcc 3.4.4 it compiles
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:27 ---
Subject: Bug 23467
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:26:38
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:28 ---
Subject: Bug 23467
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:27:55
Modified files:
gcc: ChangeLog stor-layout.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:36 ---
Subject: Bug 23044
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:35:42
Modified files:
gcc/cp : ChangeLog pt.c
--
Bug 18835 depends on bug 23044, which changed state.
Bug 23044 Summary: [4.0/4.1 Regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044
What|Old Value |New Value
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-23
12:38 ---
fixed mainline and 4.0
2005-08-23 Nathan Sidwell [EMAIL PROTECTED]
PR c++/23044
* pt.c (tsubst_qualified_id): A SCOPE_REF can still remain.
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:39 ---
Subject: Bug 23044
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-23 12:38:53
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:42 ---
This works in both on the mainlline and in 4.0.0. Also the fix is not really a
correct fix as this area was
not what changed between 3.4.0 and 4.0.0.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:45 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From matti dot rintala at iki dot fi 2005-08-23
12:47 ---
(In reply to comment #3)
You can set env variables per user.
Are you saying that specs files and specs options are not supported in current
gcc and that they should not be used for any purpose?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:49 ---
(In reply to comment #4)
(In reply to comment #3)
You can set env variables per user.
Are you saying that specs files and specs options are not supported in current
gcc and that they should not be
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:15
---
I agree that something much more subtle is going on, maybe even a C++ front-end
bug in 3_4-branch. Notice that hash_map::allocator_type is typedef-ed as
_Ht::allocator_type, which, in turn (see the hashtable class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:15 ---
Confirmed, this is a regression from 3.4.0 where we did not have this access.
It looks like it was caused by:
2005-02-09 Richard Henderson [EMAIL PROTECTED]
* builtins.c (DEF_BUILTIN):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:18 ---
I forgot to mention that the preprocessed source from 4.1.0 compiles just fine
with the 3.4.0 compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:26
---
(In reply to comment #5)
I find this very hard to believe: the ext/ headers are basically frozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:34
---
(In reply to comment #6)
Ok, Andrew is right, just double checked. A big mistery...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:42
---
(In reply to comment #7)
A big mistery...
Actually, in 3_4-branch memory allocation in class hashtable was rather
different,
forgot about that. The bug is there.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:42 ---
Oh and the preprocessed created with 3.4.0 gives the same error on the mainline
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:55
---
It looks like the problem has been fixed in revision 1.6 of hashtable.h.
Mattias, can you experiment a bit with just changing in class hashtable:
typedef _Alloc allocator_type;
to
typedef typename
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:15 ---
I see this too.
Compiling with -fno-bounds-check helps, but not enough.
One possibility is simply that our implementation of nextDouble is
inefficient. I doubt this function was coded for maximum
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-08-23
14:19 ---
Working on a patch.
--
What|Removed |Added
AssignedTo|pbrook at gcc dot gnu dot
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:19 ---
I tried this with the gcc 4.0 and java-gnome that ship on Fedora Core 4.
It worked for me.
Can you give some more information? Perhaps the stack trace that you see?
Did you compile this or run it
--- Additional Comments From mark at klomp dot org 2005-08-23 14:31 ---
Subject: Re: Sun's JIT faster than gcc for
Random.nextDouble
It looks like the problem is that we don't remove the synchronization
for nextDouble() even though the test case is single-threaded.
qprof:
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:36 ---
This still seems quite high:
# of unexpected failures91
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20908
--- Additional Comments From kuan_long at hotmail dot com 2005-08-23 14:43
---
-gnato still fail in Mingw 4.1 ,the OS is windows XP
gcc -v
Reading specs from C:/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --
host=
Fortran code containing preprocessor instructions needed for handling
system-specific behaviour is traditionally written to files with
the extension .F (rather than .f). The GCC driver would preprocess this
file in a first step, writing the intermediate code to a temporary .f file.
The regression
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:48 ---
Yes, I think that most invocations of next should be inlined, and wrapped in a
single synchronized block.
Apart from that, I am pretty sure that here
seed = (seed * 0x5DEECE66DL + 0xBL) ((1L 48) -
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:51 ---
It looks like the problem is that we don't remove the synchronization
for nextDouble() even though the test case is single-threaded.
If we can remove even only half of the synchronization overhead, by
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
14:54 ---
The gfortran bug is PR 18452.
The g77 bug was PR 13008 and was fixed in 3.4.0.
I am going to close this as a dup of the gfortran bug.
*** This bug has been marked as a duplicate of 18452 ***
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
14:54 ---
*** Bug 23532 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:06 ---
Fixed by:
+2005-08-23 Mark Mitchell [EMAIL PROTECTED]
+
+ * hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT.
+
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:12 ---
This is a target bug.
http://groups-beta.google.com/group/comp.lang.ada/browse_thread/thread/ee1a8b8db84c88f/
2195130b88e4dc9d?
lnk=stq=Ada+exception+block+does+NOT+work%3Frnum=1#2195130b88e4dc9d
Most
The compiler generates the following error (includes command building the file)
when building a cross compiler out of GCC HEAD. This also happens on the
20050813 snapshot but does NOT happen on the May 15, 2005 snapshot.
- Pasted console log below -
1 - 100 of 164 matches
Mail list logo
