--- Comment #14 from shanwill44 at yahoo dot com 2006-02-25 07:18 ---
> I changed the libgcj.spec file manually to the second. That seems to work.
> So, my conclusion is to change the libgcj.spec.in.
> The following line:
> *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@
--- Comment #13 from aoliva at gcc dot gnu dot org 2006-02-25 03:53 ---
It was GNU/Linux, for sure. Earlier gthr-posix.h used #pragma weak, which did
not require declarations for referenced symbols, whereas the new weakref
machinery requires earlier declarations to obtain the type for t
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-02-25 03:09 ---
Subject: Re: [4.2 regression] ICE in
add_virtual_operand, at tree-ssa-operands.c:1867
On Fri, 2006-02-24 at 13:06 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #2 from pinskia at gcc dot
On Fri, 2006-02-24 at 13:06 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 13:06
> ---
> Confirmed. Though VRP2 is just doing constant propagation at this point.
>
>
Last time i looked at a bug like this, it was actually
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-02-25 03:03
---
This does not fail with 4.0.2 , so it is a regression after all, but farther
back.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
--- Comment #6 from yichen dot xie at gmail dot com 2006-02-25 01:55
---
(In reply to comment #5)
> ISO C is not your normal low level language any more. It actually tries to be
> a high level language.
>
> So this is not a bug.
>
I still don't think it's a good idea to treat thread
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-02-25 01:24
---
I have reverted back several patches and the problem in Comment #15 is not a
recent regression. I have opened a new PR for this since it manifests
completely differently. See PR26464.
This PR26423 is fixed in
With the following test case: Either an invalid argument or abort triggered on
READ depending on datasize. Initial test case from Dale Ranta Comment #15 of
pr26423. Seems to trigger for datasize less then 1022.
program test
integer,parameter :: datasize = 1020
dimension idata(d
--- Comment #26 from rth at gcc dot gnu dot org 2006-02-25 01:00 ---
I agree we shouldn't mess with _Unwind_GetIP. While I kinda like the idea
behind _Unwind_SignalFrameContext, I'm not sure I like the idea of the
effectively mandatory back-to-back PLT calls. If you think that _U_SFC
--- Comment #4 from quanah at stanford dot edu 2006-02-25 00:59 ---
Setting the PIC flags did not fix this issue. It appears impossible at this
time to build gcj on AMD64 with 4.0.x.
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
Optimization on sample below creates a temporary
pointer &buf[i] where data is written. However
this pointer is not restored to &buf[0] when i
is set to 0.
Occurs on 3.3.3 but not 2.95. I realize that 3.3
is really old, but it would be useful to know if this
has already been fixed and if possibl
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-25 00:02 ---
ISO C is not your normal low level language any more. It actually tries to be
a high level language.
So this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from quanah at stanford dot edu 2006-02-24 23:24 ---
This may be in part because two variables are not being set correctly:
"PICFLAG=" "PICFLAG_FOR_TARGET="
when building in libjava/
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
--- Comment #2 from quanah at stanford dot edu 2006-02-24 23:09 ---
This seems to be because libsax_gcj_la-sax.o is not being built with -fPIC,
like it apparently needs to be:
[EMAIL
PROTECTED]:/afs/ir/src/pubsw/languages/gcc-build/amd64_linux26/x86_64-unknown-linux-gnu/libjava/extern
--- Comment #4 from yichen dot xie at gmail dot com 2006-02-24 23:06
---
> Why not let the OS do its job? I still don't understand that idea.
It's a thread library that builds on top of pthreads, so yes, OS is doing its
job, and we're doing more on top of that. C is a natural choice f
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 22:38 ---
(In reply to comment #2)
> (In reply to comment #1)
> > It seems like you are trying to
> > deal with your own threading system instead of allowing the OS do its work.
> >
>
> This is indeed what I am trying to do,
--- Comment #2 from yichen dot xie at gmail dot com 2006-02-24 22:12
---
(In reply to comment #1)
> It seems like you are trying to
> deal with your own threading system instead of allowing the OS do its work.
>
This is indeed what I am trying to do, and C seems to be the perfect lang
--- Comment #11 from bugzilla-gcc at thewrittenword dot com 2006-02-24
22:03 ---
(In reply to comment #9)
> Can you try 3.4.5?
Same problem as 3.4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-02-24 21:46
---
Edmar --
Great, yes, that looks like the right information. However, it's unlikely that
I'll be able to personally look at this before 4.1.0.
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-02-24 21:40
---
I will have to revert back a bit and see if this too is a regression or
something new. (yer killin me man! ;) )
Seriuously, though. We'll take all the testing we can get, even if it is
frustrating. Thanks.
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|c |middle-end
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:32 ---
Why do you think this can ever work in general?
Also why do you need this to work this way? It seems like you are trying to
deal with your own threading system instead of allowing the OS do its work.
--
pinskia
--- Comment #10 from pcarlini at suse dot de 2006-02-24 21:22 ---
(In reply to comment #9)
> ... If the standard says you can
> string together inserts, and that a failed insert will "disable" the
> stream until the error is cleared, but not allowing
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-24 21:17 ---
Subject: Re: [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in
matmul_i4.c in loop invariant motion
> I'm not sure how to fix this. The debug trace here says it all: We try to
> f
--- Comment #9 from edmar at freescale dot com 2006-02-24 21:15 ---
(In reply to comment #8)
> Subject: Re: [4.1/4.2 Regression] gcc fails to build on
> powerpc e500-double targets
>
>
>
> Bummer.
>
> Please attach preprocessed source and configuration options so that we
> have a s
--- Comment #9 from phil at mitre dot org 2006-02-24 21:14 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Yup. But by providing the ability to batch stream inserts, per the
standard I presume otherwise it's not much of a stream, then you create
t
--- Comment #8 from mark at codesourcery dot com 2006-02-24 21:07 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> --- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
> Created an attac
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 ---
*** Bug 26462 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 ---
This is a dup of bug 26374. The problem is that the middle-end does not fold
IBM 128bit long double format currently. See PR 19405 for history on why.
*** This bug has been marked as a duplicate of 26374 ***
--
--- Comment #8 from pcarlini at suse dot de 2006-02-24 21:03 ---
(In reply to comment #7)
> . In my recent example I was
> explaining how, even if I asserted ostream state and detected that an
> error had occurred, I would not be able to determine
$ cat const.c
#define B0 (+1.0l/5/1/6)
const double c0 = B0; // initializer element is not computable at load time
const double c0_tab[1] = { B0 }; // initializer element is not constant
#define B1 (+1.0l/5)
const double c1 = B1; // ok.
const double c1_tab[1] = { B1 }; // initializer element is
stop
end
[dir:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.5.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060224 (experimental)
[dir:~/tests/gfortran-D] dir
I ran into this problem with stock gcc-4.0.2 on Fedora Core 2. The problem
shows when the following code is compiled with -O2: the address of "array"
seems to be cached and reused across calls to function "h". This becomes a
problem when function h saves its execution context in one thread and resu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
--- Comment #4 from steven at gcc dot gnu dot org 2006-02-24 20:48 ---
I'm not sure how to fix this. The debug trace here says it all: We try to
force something into an operand using an optab with a mode for which we have no
handler:
Starting program: /home/steven/devel/build-trunk/gcc
--- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
Created an attachment (id=10911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10911&action=view)
Input program that causes ICE on gcc-4.1.0 RC2
No deal. I got an ICE now:
[root:/local/edmar/obj_gcc/powerpc-unkn
--- Comment #7 from phil at mitre dot org 2006-02-24 20:40 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Agreed, the stream object itself hopfully doesn't get corrupted (bad),
but what I was refering to was "the data" itself, not the stream
objec
--- Comment #6 from pcarlini at suse dot de 2006-02-24 19:56 ---
(In reply to comment #2)
> Otherwise, there's great potential that the output stream (the data)
> will become corrupted, even if you manage to check it state.
By the way, there is no such thing as a "corrupted stream". Eit
--- Comment #25 from jakub at gcc dot gnu dot org 2006-02-24 19:56 ---
Updated patches. Unfortunately, it seems even this is not enough as Java
(and C++ as well, but there we aren't expecting to throw through signal
frames), the personality routine does the same as uw_frame_state_for wa
--- Comment #24 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10910)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10910&action=view)
binutils-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #23 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10909)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10909&action=view)
gcc-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from roger at eyesopen dot com 2006-02-24 19:37 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-24 19:29 ---
Subject: Bug 24952
Author: sayle
Date: Fri Feb 24 19:29:34 2006
New Revision: 111425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111425
Log:
PR middle-end/24952
* combine.c (try_combine): E
--- Comment #6 from mark at codesourcery dot com 2006-02-24 19:14 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> I started a build. This is a very slow target, it will take several hours...
If you've got a
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 19:13 ---
This is ICEing when printing a warning:
1038warning (0, "mudflap cannot track %qs in stub function",
1039 IDENTIFIER_POINTER (DECL_NAME (decl)));
DECL_NAME (decl) is NULL as t
--- Comment #5 from edmar at freescale dot com 2006-02-24 19:10 ---
(In reply to comment #4)
> Edmar --
>
> Does changing:
>
> if (rs6000_float_gprs_string == NULL) \
> rs6000_float_gprs = 2;
>
> too:
>
> if (!rs6000_explicit_options.float_gprs) \
> rs6000_float_gprs = 2;
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-02-24 19:04
---
Edmar --
Does changing:
if (rs6000_float_gprs_string == NULL) \
rs6000_float_gprs = 2;
too:
if (!rs6000_explicit_options.float_gprs) \
rs6000_float_gprs = 2;
work? Not just compile, but also gener
--- Comment #5 from phil at mitre dot org 2006-02-24 19:00 ---
(In reply to comment #4)
> I think Paolo forgot to mention this is required by the C++ standard.
Well that's different then. I realize that many non-standard things were
allowed pre gcc-3.0 and that 3+ was starting to enfor
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:59 ---
Well this one class file is not enough to reproduce this failure as I get
errors:
java/util/Comparator.java: In class
'org.eclipse.jdt.internal.compiler.parser.AbstractCommentParser':
java/util/Comparator.java: In co
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:55 ---
I think Paolo forgot to mention this is required by the C++ standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from phil at mitre dot org 2006-02-24 18:54 ---
See comment #2.
--
phil at mitre dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #3 from edmar at freescale dot com 2006-02-24 18:49 ---
(In reply to comment #2)
> It also tells us that testing powerpc-linux-gnuspe is not important as it has
> been broken for over a half of a year.
>
We test all releases, the last one was 4.0.2 and it was OK.
--
ht
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:48 ---
Confirmed, had 3.4 was the last import.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from phil at mitre dot org 2006-02-24 18:45 ---
Subject: RE: Passing a NULL char* into output stream now breaks the output
stream
Thanks for the quick response. This came up when some old systems were
ported from Solaris using gcc-2.9.5 or so and out output files just
s
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:43 ---
It also tells us that testing powerpc-linux-gnuspe is not important as it has
been broken for over a half of a year.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:42 ---
It is obvious that it was caused by:
2005-05-05 Aldy Hernandez <[EMAIL PROTECTED]>
David Edelsohn <[EMAIL PROTECTED]>
* config.gcc: Add .opt magic for the rs6000 ports.
.
--
pinskia at
When configuring gcc with:
--target=powerpc-unknown-linux-gnuspe --host=powerpc-unknown-linux-gnuspe
--enable-e500_double
this file will be included:
gcc/config/rs6000/e500-double.h
which in turn uses the variable
rs6000_float_gprs_string
which is not defined anywhere. (So the build stops with unde
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 ---
*** Bug 26455 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 ---
*** This bug has been marked as a duplicate of 26417 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 ---
*** Bug 26452 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 ---
This is a dup of bug 25952.
*** This bug has been marked as a duplicate of 25952 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:23
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Feb 24 18:23:38 2006
New Revision: 111421
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111421
Log:
2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:23 ---
Actually this is still a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 18:22 ---
Actually never mind I see the issue now but I still say this is a latent bug
and not really my bug.
And the patch is wrong anyways in general as most of those places really should
have been testing
something like
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:16
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Feb 24 18:16:25 2006
New Revision: 111420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111420
Log:
2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-24 18:14
---
(In reply to comment #11)
> (In reply to comment #10)
> > Note -O3 enables complete unrolling at the tree level, I think there might
> > be
> > another related bug to this one. I bet it is failing in VRP2 also, j
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|ICE with -march=pentium4 - |[4.2 Regression
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-24 17:54
---
(In reply to comment #10)
> Note -O3 enables complete unrolling at the tree level, I think there might be
> another related bug to this one. I bet it is failing in VRP2 also, just like
> the other one.
That would
--- Comment #8 from ska at resqnet dot com 2006-02-24 17:53 ---
Any chances to get it resolved ?
This severe bug is a showstopper for using OpenCobol with GCC on AIX platform
because all C programs are generated and there are no way to reduce the size of
the programs automatically due t
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-24 17:53
---
Note -O3 enables complete unrolling at the tree level, I think there might be
another related bug to this one. I bet it is failing in VRP2 also, just like
the other one.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-24 17:48 ---
So what this means I could not have caused this as the only patch after my 18th
GCC and my 20th GCC is not a patch which I committed that would have caused
this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 17:47 ---
I can reproduce this on the 20th though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:46 ---
(In reply to comment #6)
> Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What
> were you doing to reproduce this?
Or even the 20th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:42 ---
I cannot reproduce this with "4.2.0 20060218".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 ---
*** Bug 26440 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 ---
Actually looking at the simplified testcase this is a dup of bug 25392.
*** This bug has been marked as a duplicate of 25392 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #37 from dcb314 at hotmail dot com 2006-02-24 17:38 ---
(In reply to comment #33)
> Created an attachment (id=10902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902&action=view) [edit]
> updated patch.
>
> better patch. I'm going to post that one when regtesting co
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:36 ---
Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What
were you doing to reproduce this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:34 ---
Actually this looks like it is x86 specific. Please next time add the target
if you think it is x86 specific and also pelase mention this was also using the
C++ front-end.
--
pinskia at gcc dot gnu dot org chang
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 17:32 ---
Actually I could not reproduce this with "4.2.0 20060221"?
Is it only with the patch to fix PR 26421?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:25 ---
I want to say this is exactly the same issue as PR 25392, looking at the fact
it is the return value which is causing the issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pcarlini at suse dot de 2006-02-24 16:53 ---
The change is certainly intended and the important point is that is not true
that there is no indication of the failure, quite to the contrary the badbit is
set. Try changing your test like this:
char *str = NULL;
cout
Prior behavior handled passing a char* with a NULL value into an output stream;
the result was that nothing printed. As of versions 3 and later this behavior
has changed. Perhaps a bug, perhaps a new enforcement.
The result is that the output stream no longer writes anything (to file or
stdout)
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-24 15:20
---
Ivopts fail to use the complex addressing mode, thus forcing one more biv into
inner loop. Since this makes it impossible to allocate registers for the loop,
we get another penalty for spilling.
Changing the ini
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-24 15:20
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:12 ---
This is an issue of agrument passing really as eax is used to pass 0 to memset
though I don't know if this is really an issue or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-24 15:11 ---
To my knowledge xorl %eax, %eax is just a shorter form of xorq %rax, %rax,
both clear all 64 bits of %rax.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 15:10 ---
More information about this issue is at the following thread:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00167.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25978
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 ---
*** Bug 26456 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 ---
This is Darwin specific.
This is a dup of bug 25978.
*** This bug has been marked as a duplicate of 25978 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-02-24 15:08
---
Patch submitted:
http://gcc.gnu.org/ml/fortran/2006-02/msg00498.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
The following code snippet, compiled with -Os -fstack-protector:
#include
int StringChecksum(char *s)
{
char buffer[2048];
int i;
int checksum = 0;
memset(buffer, 0, 2048);
strcpy(buffer, s);
for (i=0; i<2048; i++)
checksum += bu
--- Comment #13 from Ralf dot Wildenhues at gmx dot de 2006-02-24 14:57
---
(In reply to comment #12)
> It appears that the LT stands for libtool. So the first one (LIBICONV) is
> supposed to be used for linking if you aren't using libtool, and the second
> one
> (LTLIBICONV) is used
--- Comment #1 from eloranta at jyu dot fi 2006-02-24 14:23 ---
Most likely this is just OS X specific bug.
--
eloranta at jyu dot fi changed:
What|Removed |Added
OpenMP C programs deadlock immediately after starting when OMP_NUM_THREADS is >
1.
For example, the following simple code just hangs:
#include
main() {
int i;
#pragma omp parallel for private(i)
for (i = 0; i < 100; i++)
printf("Thread = %d.\n", omp_get_thread_num());
}
This occurs on
--- Comment #10 from pault at gcc dot gnu dot org 2006-02-24 14:15 ---
First, I am sorry to be a "doubting Thomas" - I finally succeeded in
reproducing the problem.
Second, I unpatched the above and find that this is indeed the problem. I will
try to understand why but:
(i) I have po
--- Comment #9 from pault at gcc dot gnu dot org 2006-02-24 13:54 ---
Subject: Bug 26409
Author: pault
Date: Fri Feb 24 13:54:06 2006
New Revision: 111417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111417
Log:
2006-02-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-02-24 13:15 ---
(In reply to comment #7)
> A few binary search steps later: Works with revision 111270, fails with
> 111271.
> It seems to be related to the patch
>
First, I am sorry to be a "doubting Thomas" - I finally succeeded
1 - 100 of 120 matches
Mail list logo
