--- Comment #13 from uros at kss-loka dot si 2005-11-09 07:55 ---
Fixed everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from uros at gcc dot gnu dot org 2005-11-09 07:51 ---
Subject: Bug 24101
Author: uros
Date: Wed Nov 9 07:51:51 2005
New Revision: 106679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106679
Log:
gcc/
PR c/24101
* toplev.c (process_options): Ini
I've sucessfully done this on a different machines, it may possibly be a
hardware fault that is causing the segfault? I just need someone @ gcc to
confirm that this is true and email me
caffeen-2# cc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc ver
--- Comment #2 from b dot gunreben at web dot de 2005-11-09 07:07 ---
Another testcase, fails with gcc -O2 -c, same compiler as above:
typedef long
(*bla)(int *node);
static long F2(void *tree, long blk, bla after_node_func)
{
long call_result = 0;
int *node;
if (call_result = aft
--- Comment #11 from uros at gcc dot gnu dot org 2005-11-09 06:42 ---
Subject: Bug 24101
Author: uros
Date: Wed Nov 9 06:42:53 2005
New Revision: 106678
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106678
Log:
libcpp/
PR c/24101
* init.c (read_original_filena
--- Comment #10 from uros at gcc dot gnu dot org 2005-11-09 06:30 ---
Subject: Bug 24101
Author: uros
Date: Wed Nov 9 06:30:03 2005
New Revision: 106677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106677
Log:
libcpp/
PR c/24101
* init.c (read_original_filena
--- Comment #5 from armcc2000 at yahoo dot com 2005-11-09 06:21 ---
(In reply to comment #4)
> I think this is a dup of bug 23150 which was fixed in 4.1.0.
>
I don't think so.
I rebuilt 4.0.2 after applying the patch given for bug 23150.
The patched version of 4.0.2 gives the same res
--- Comment #4 from ian at airs dot com 2005-11-09 06:08 ---
Not a bug.
--
ian at airs dot com changed:
What|Removed |Added
Status|WAITING
--- Comment #3 from armcc2000 at yahoo dot com 2005-11-09 05:56 ---
Yes, I think you're absolutely correct.
You've also just explained a bug I've been staring at all day ;-) Reading
action->dev_id was causing a segfault and I couldn't understand why r0 and r7
in the resulting register
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 05:25 ---
Actually I don't think this is a bug:
ldr r1, [r4, #16] <--- action->dev_id
mov r0, r7 <- irq
mov r2, r8 <- regs
mov lr, pc
Call act
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 05:17 ---
Do you have a self contained example?
I think what you are seeing is a different artifact of a different issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24751
The following example comes from ARM linux kernel 2.6.14
#define local_irq_enable() \
({ \
unsigned long temp;
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 04:31 ---
I think this is a dup of bug 23150 which was fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from armcc2000 at yahoo dot com 2005-11-09 04:21 ---
A few more results...
1) gcc 4.0.2 _is_ also buggy
2) Bug seems to be associated with -foptimize-sibling-calls
ie previous code compiled with:
arm-linux-gcc-4.0.2 -O1 -foptimize-sibling-calls
gives:
.align
--- Comment #5 from hp at gcc dot gnu dot org 2005-11-09 03:47 ---
And PR 20656.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
--- Comment #3 from hp at gcc dot gnu dot org 2005-11-09 03:45 ---
Referring to comment #2, the test-case for PR 24750 has a few similar loops and
a few other PR references that seems relevant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20656
--- Comment #4 from hp at gcc dot gnu dot org 2005-11-09 03:24 ---
And to PR 18527.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
--- Comment #3 from hp at gcc dot gnu dot org 2005-11-09 03:17 ---
Pinskia brings to attention that the loop removal thingy is more related to PR
23361.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-09 03:09 ---
(In reply to comment #1)
> With -funsafe-loop-optimizations we remove them.
> Using -Wunsafe-loop-optimizations, we get:
> t.c:2: warning: cannot optimize loop, the loop counter may overflow
If the loop counter will
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-09 02:30 ---
Created an attachment (id=10182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10182&action=view)
Compile with -Os
Note the brittleness of the test-case. Apparently there's a bug, PR 20656,
causing the empty, seem
--- Comment #1 from hp at gcc dot gnu dot org 2005-11-09 02:23 ---
I should mention that
(plus:SI (sign_extend:SI (reg:HI 10 r10)) (reg:SI 1 r1))
is not a valid address, but
(plus:SI (sign_extend:SI (sign_extend:SI (mem:HI (post_inc:SI (reg/f:SI 12
r12)
(reg:SI 1 r1))
is; th
--- Comment #2 from armcc2000 at yahoo dot com 2005-11-09 02:11 ---
Here's a slightly smaller test case:
extern void foo (int f1, int f2, int f3, int f4, int f5, int f6);
void good (int g1, int g2, int g3, int g4, int g5)
{
The test-case to be attached "works" with 4.0.2.
For revision 106478 of "Fri Nov 4 03:11:30 UTC 2005", I get
/tmp/st18.c: In function âfâ:
/tmp/st18.c:73: error: insn does not satisfy its constraints:
(insn:QI 84 518 85 9 (set (cc0)
(mem:QI (plus:SI (sign_extend:SI (reg:HI 10 r10))
--- Comment #17 from wilson at specifix dot com 2005-11-09 02:06 ---
Subject: Re: New: gfortran - fails to build on Mac OSX
-10.4.3
dir at lanl dot gov wrote:
> strip -o libgcc_s.10.4.dylib_T${mlib} \
> -s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
> libgcc_s$
--- Comment #7 from wilson at gcc dot gnu dot org 2005-11-09 01:45 ---
I see the problem now. It is present in the FSF gcc-3.4.x sources.
The problem is that init_gcc_specs in gcc.c rewrites the LIBGCC_SPEC rule. It
looks for the first -lgcc, and replaces it with target independent ru
--- Comment #2 from pierhyth at gmail dot com 2005-11-09 01:33 ---
The current C++ standard says that Koenig applies "when an unqualified
name is used as the postfix-expression in a function call" which from
what I've read, must include the case of functoids/functors and references
to f
--- Comment #5 from hp at bitrange dot com 2005-11-09 01:08 ---
Subject: Re: [4.1 regression] testsuite
failure:gfortran.fortran-torture/execute/in-pack.f90 exe
On Tue, 8 Nov 2005, fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2005-11-09
00:47 ---
(In reply to comment #5)
> Subject: Re: Shared libgcc not used for linking by default
>
> sje at cup dot hp dot com wrote:
> > --- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
>
--- Comment #5 from wilson at specifix dot com 2005-11-09 00:34 ---
Subject: Re: Shared libgcc not used for linking by default
sje at cup dot hp dot com wrote:
> --- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
> I am not convinced that this is a bug.
There
--- Comment #8 from amodra at bigpond dot net dot au 2005-11-09 00:25
---
Uggh, that was too simplistic. We really do need to search back from i3 in
other cases, eg. when combine extends a reg lifetime. It seems that we need to
check for other sets of a dead reg between from_insn and
--- Comment #4 from law at redhat dot com 2005-11-09 00:02 ---
Created an attachment (id=10181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10181&action=view)
Proposed patch and new testcases
I'm not comfortable self-approving this patch; the option processing code is
totally ne
--- Comment #8 from pupeno at pupeno dot com 2005-11-09 00:02 ---
I am now running 4.0.2 20050808 (prerelease) and I can't reproduce it either.
Whatever it was seems to be solved.
Would you still be interested on the unit tests ? if so, could you point me to
where I should start with it
--- Comment #11 from tobi at gcc dot gnu dot org 2005-11-08 23:58 ---
Patch posted.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|toon at
[EMAIL PROTECTED]:~/src/pr/24643> cat implicit_7.f90
subroutine variant
ybtable=ylocal(1:2) ! { dg-error "Unclassifiable" }
end
[EMAIL PROTECTED]:~/src/pr/24643> ~/src/gcc/build/gcc/f951 implicit_7.f90
variant In file implicit_7.f90:3
end
1
Internal Error at (1):
gfc_validate_kind(): Got ba
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 23:40 ---
*** Bug 24746 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24745
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 23:40 ---
*** This bug has been marked as a duplicate of 24745 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
C++ programs with "if (NULL)" generate an unpleasant warning even with default
compiler options. Code with "if (NULL)" comes from of macro expansion or
auto-generated code.
Warnings are a matter of taste so I won't ask "make all the warnings match my
taste", but I do petition you to revisit which
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 23:24 ---
Oh and the first "argument to non-pointer type `bool' from NULL" was new in
3.0.x and above and did not show up in 2.95.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 23:24 ---
Hmm, all of these warnings were present before 4.0.0.
The only warning that is a regression is the second:
"argument to non-pointer type `bool' from NULL" warning which did not warn in
3.3.3 and before but does in 3.
--- Comment #7 from amodra at bigpond dot net dot au 2005-11-08 23:19
---
I snipped too much of the dumps. The problem is that after reg 137 dies in
insn 118, it is set, and dies again before insn 123. When combine tries to
find a place for the death note on insn 118, it can't put it
C++ programs with "if (NULL)" generate an unpleasant warning even with default
compiler options. Code with "if (NULL)" comes from of macro expansion or
auto-generated code.
Warnings are a matter of taste so I won't ask "make all the warnings match my
taste", but I do petition you to revisit which
--- Comment #8 from bkoz at gcc dot gnu dot org 2005-11-08 23:12 ---
We'd certainly not forget about this on the branch.
However, I decided to just go ahead and do this anyway, because it is a change
in behavior but mostly because it seems to be confusing people/distros WRT what
alloc
--- Comment #5 from neroden at gcc dot gnu dot org 2005-11-08 22:56 ---
So Debian is planning to revert allocator choice to fix this, I believe. :-)
Technically it's not 'critical' according to the analysis, incidentally.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
--- Comment #2 from rth at gcc dot gnu dot org 2005-11-08 22:43 ---
Band-aid applied. I'll work on a better solution later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24703
--- Comment #1 from rth at gcc dot gnu dot org 2005-11-08 22:41 ---
Subject: Bug 24703
Author: rth
Date: Tue Nov 8 22:40:55 2005
New Revision: 106662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106662
Log:
PR 24703
* omp-low.c (determine_parallel_type): Disab
--- Comment #5 from sje at cup dot hp dot com 2005-11-08 22:29 ---
I forgot to include the PR number in the ChangeLog, the fix has been checked in
on the 3.4 branch for 3.4.5. It was already fixed on the 4.0 branch and on the
main line. The patch was submitted with:
http://gcc.gnu.org
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 22:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-08 22:13
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-08 22:12
---
(In reply to comment #2)
> The problem seems to be return-by-reference (e.g. character) functions don't
> mix well with DECL_IS_PURE. Testing a patch.
Patch here: http://gcc.gnu.org/ml/fortran/2005-11/msg00253.ht
--- Comment #3 from tromey at gcc dot gnu dot org 2005-11-08 22:00 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from tromey at gcc dot gnu dot org 2005-11-08 21:58 ---
Subject: Bug 24587
Author: tromey
Date: Tue Nov 8 21:58:43 2005
New Revision: 106659
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106659
Log:
PR libgcj/24587:
* gnu/classpath/SystemProperti
--- Comment #2 from laurent at guerby dot net 2005-11-08 21:58 ---
Confirmed on 4.0.2 and 4.1.
+===GNAT BUG DETECTED==+
| 4.0.2 (i686-pc-linux-gnu) in build_unary_op, at ada/utils2.c:1056|
| Error detected at elements-sets.adb:
--- Comment #2 from sraa at kse dot nl 2005-11-08 21:57 ---
Subject: RE: NaN or correct result after divrp with 3 FPU registers
Hello,
That's the big problem. I'm trying for three weeks to get the problem expose
itself in a small program. But I can't get it wrong on purpose. Otherwi
--- Comment #16 from andreast at gcc dot gnu dot org 2005-11-08 21:55
---
Sorry to continue with questions...
Did you try a simple make bootstrap w/o -j x?
This is my config I use atm:
/Volumes/export/gcc/gcc-svn/head/gcc/configure
--prefix=/Volumes/export/gcc/gcc-svn/head/testbin --
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7906
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2005-11-08
21:49 ---
(In reply to comment #3)
> I am not convinced that this is a bug. Was there an intentional change
> between
> 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it
> seems like thi
--- Comment #4 from pcarlini at suse dot de 2005-11-08 21:48 ---
(In reply to comment #3)
> Does your comment mean that this configuration is strongly discouraged, or
> that the bug report lacked relevant information?
Neither ;) Not the former, because we are putting a lot of efforts o
--- Comment #15 from dir at lanl dot gov 2005-11-08 21:46 ---
The problem is still there -
34 13:14 svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
35 13:29 cd gcc
36 13:30 mkdir objdir
37 13:30 cd objdir
38 13:30 ../configure --prefix=/Users/di
--- Comment #5 from jakub at gcc dot gnu dot org 2005-11-08 21:45 ---
Subject: Bug 19450
Author: jakub
Date: Tue Nov 8 21:44:58 2005
New Revision: 106657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106657
Log:
PR c++/19450
* decl.c (redeclaration_error_messag
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 21:31 ---
Fixed in 4.1.0, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 21:25 ---
Only on the 4.0 branch:
maccumulate-outgoing-args
Target Report Mask(ACCUMULATE_OUTGOING_ARGS)
Reserve space for outgoing arguments in the function prologue
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 21:23 ---
Do you have a small source code which exposes the issue here?
(Note I saw "So I can not deliver a small program that
reproduces the problem " but we really cannot do anything about it if there
is not a testcase)
--- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
I am not convinced that this is a bug. Was there an intentional change between
3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it
seems like this might have happened, that in 3.4 (with C) -sha
--- Comment #2 from daney at gcc dot gnu dot org 2005-11-08 21:20 ---
Could someone elaborate?
If the child is killed, it is dead and it did not matter anyhow.
The child is not going to be getting random async signals.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23758
Hello,
(OS, machine and compiler info in bottom of this message).
In certain sources I get a problem that a calculation with floats gives a NaN.
It occurs when parens are used for the division (they are not neccessary, but
it is not wrong). But when two same instructions are placed after each oth
--- Comment #22 from dnovillo at gcc dot gnu dot org 2005-11-08 21:16
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00539.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from fw at deneb dot enyo dot de 2005-11-08 21:12 ---
(In reply to comment #2)
> I gather therefore that Debian
> is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely
> not obvious and not trivial in its consequences.
Seems to be the case:
Confi
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #21 from dnovillo at gcc dot gnu dot org 2005-11-08 21:09
---
Subject: Bug 23046
Author: dnovillo
Date: Tue Nov 8 21:09:51 2005
New Revision: 106656
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106656
Log:
2005-11-08 James A. Morrison <[EMAIL PROTECTED]>
--- Comment #12 from tromey at gcc dot gnu dot org 2005-11-08 21:01 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #11 from tromey at gcc dot gnu dot org 2005-11-08 21:00 ---
Subject: Bug 23763
Author: tromey
Date: Tue Nov 8 21:00:15 2005
New Revision: 106655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106655
Log:
PR libgcj/23763. From [EMAIL PROTECTED]
* jav
--- Comment #10 from tromey at gcc dot gnu dot org 2005-11-08 20:59 ---
Subject: Bug 23763
Author: tromey
Date: Tue Nov 8 20:59:20 2005
New Revision: 106654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106654
Log:
PR libgcj/23763. From [EMAIL PROTECTED]
* jav
--- Comment #10 from tobi at gcc dot gnu dot org 2005-11-08 20:55 ---
Correction: implicit types are only assigned during resolution. The issue is:
why does it reject the second statement if the RHS object already exists, but
not otherwise?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-08 20:43
---
The problem seems to be return-by-reference (e.g. character) functions don't
mix well with DECL_IS_PURE. Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-08 20:36 ---
I found an extra problem with loop-invariant.c, which is that it would move
expressions out of loops with calls, even if the expressions used call
clobbered hard registers. I'm testing a fix for this bug now, too...
--- Comment #9 from dpatel at gcc dot gnu dot org 2005-11-08 20:21 ---
Subject: Bug 23115
Author: dpatel
Date: Tue Nov 8 20:21:15 2005
New Revision: 106653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106653
Log:
PR tree-optimization/23115
* tree-if-conv.c (find
--- Comment #8 from tromey at gcc dot gnu dot org 2005-11-08 20:07 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-08 20:06 ---
Instead of the patch in comment #2, I think we want to
simply make this loadLibrary conditional on 'Configuration.INIT_LOAD_LIBRARY'.
See GtkToolkit.java for an example; FWIW this change is already in
Classpath CVS.
--- Comment #9 from tromey at gcc dot gnu dot org 2005-11-08 19:44 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-08 19:42
---
As I asked before, can you try to build not in the src directory.
Do instead:
cd gcc
mkdir objdir
../configure --prefix=/Users/dir/bin --enable-languages=c,f95
make -j 4
If that works then we have a regression in
--- Comment #7 from overholt at redhat dot com 2005-11-08 19:31 ---
(In reply to comment #6)
> I agree, this looks like PR 23182.
> Andrew (Overholt) -- does this bug still occur for you?
No. Sorry, I should have closed this when I first realized that it was no
longer occurring. Shall
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-08 19:27 ---
Fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-08 19:26 ---
Fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-08 19:24 ---
Subject: Bug 24735
Author: jakub
Date: Tue Nov 8 19:24:51 2005
New Revision: 106651
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106651
Log:
PR c++/24735
* semantics.c (finish_omp_barrier, f
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-08 19:23 ---
I agree, this looks like PR 23182.
Andrew (Overholt) -- does this bug still occur for you?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-08 19:22 ---
Subject: Bug 24734
Author: jakub
Date: Tue Nov 8 19:22:33 2005
New Revision: 106650
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106650
Log:
PR c++/24734
* pt.c (tsubst_expr): Handle OMP_MAS
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-08 19:11 ---
Fix is on 4.0 branch and trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-08 19:10 ---
Subject: Bug 23617
Author: tromey
Date: Tue Nov 8 19:10:39 2005
New Revision: 106648
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106648
Log:
2005-11-08 Wil Mahan <[EMAIL PROTECTED]>
PR java/236
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-11-08 18:56 ---
Subject: Re: ICE on module name vs dummy argument name
tobi,
>--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-07 13:07 ---
>(In reply to comment #3)
>
>
>>Thank you Salvatore and Andrew.
>>
>>The
--- Comment #13 from dir at lanl dot gov 2005-11-08 18:14 ---
Here is what I do -
12 9:21mkdir gfortran
13 9:21cd gfortran
14 9:25svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
15 9:56cd gcc
16 9:56configure --prefix=/Users/dir/bin
In i386.h, there are
{ "push-args",-MASK_NO_PUSH_ARGS, \
N_("Use push instructions to save outgoing arguments") }, \
{ "no-push-args", MASK_NO_PUSH_ARGS,\
N_("Do not use push instructions
--- Comment #4 from law at redhat dot com 2005-11-08 17:47 ---
Just an interesting tidbit.
This testcase exposes a much more difficult/interesting long term problem.
Namely, how should we handle uninitialized warnings for variables which are
exposed by optimization.
ie, in this case (
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-08 17:47 ---
For now, I am trying to get the size of umf_analyze down by removing the
unnecessary prototypes, beautifying the code, etc...
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #4 from simon dot marshall at misys dot com 2005-11-08 17:41
---
Is there a target milestone for this? IWBI it were fixed on 3.4 as well as
4.0.
(Appologies if I seem impertinent, I'm not too familiar with the way things
work.)
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 17:25 ---
(In reply to comment #5)
> Bogus warning no longer issued with GCC 4.1 based compilers.
Huh:
gcc version 4.1.0 20051106 (experimental)
../t6.c: In function foo:
../t6.c:13: warning: j is used uninitialized in t
--- Comment #5 from law at redhat dot com 2005-11-08 17:23 ---
Bogus warning no longer issued with GCC 4.1 based compilers.
--
law at redhat dot com changed:
What|Removed |Added
--
--- Comment #3 from law at redhat dot com 2005-11-08 17:18 ---
No plans exist to address these issues in the 3.x series. It works as expected
in GCC 4.1.
--
law at redhat dot com changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 17:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
law at redhat dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
1 - 100 of 161 matches
Mail list logo
