--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-19 00:58
---
(In reply to comment #8)
> Tried yesterday's snapshot of 4.1 and it still does not work.
OK, I'm on it. Looks like someone forgot about CRLF systems :)
I'll try to submit a first patch tomorrow...
--
fxcoude
--- Comment #19 from pcarlini at suse dot de 2005-11-19 01:05 ---
Created an attachment (id=10287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10287&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #20 from pcarlini at suse dot de 2005-11-19 01:06 ---
Created an attachment (id=10288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10288&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #21 from pcarlini at suse dot de 2005-11-19 01:08 ---
Just in case, those are ready to use outside the testsuite... For me,
especially
the second one, fails very quickly and consistently on 4-way and 16-way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-19 01:16 ---
Testing this on a cross to hppa2.0w-hp-hpux11.11 to see if this fails there so
it can be considered exposed on a primary target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #4 from schnetter at aei dot mpg dot de 2005-11-19 01:16
---
The same error message was already given (a few lines further down) when the
kind had an unsupported value. An old style kind is given in a declaration as
"real*8", a new style kind as "real(8)".
For integer and
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-19 01:27 ---
Confirmed on hppa2.0w-hp-hpux11.11 also which means this effects a primary
target also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 01:28
---
This also effects hppa2.0w-hp-hpux11.11 which means this effects a primary
target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 01:37
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-19 01:39
---
It would be a shame not to apply this patch, since it's been approved. Let's
get it applied, and get this closed.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-11-19 01:39
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-11-19 01:58
---
We should try to fix this, but zero-sized arrays are non-standard, so P2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-11-19 02:08
---
I think we need to understand this problem before we release. It might be that
we downgrade the priority if it turns out to be a problem outside our control.
--
mmitchel at gcc dot gnu dot org changed:
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-11-19 02:09
---
It would be nice to fix this, but not critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from rth at gcc dot gnu dot org 2005-11-19 02:09 ---
Created an attachment (id=10289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10289&action=view)
mf hack
For the record, here's the aforementioned hack.
And it does appear to change the behaviour of one of the
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 02:09
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-11-19 02:10
---
Should be fixed before 4.1, if possible.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-19 02:11 ---
HUH:
;; succ: 2 [100.0%] (fallthru)
(jump_insn 21 19 31 0 (parallel [
(set (pc)
(if_then_else (eq (reg:SI 28 %r28)
(const_int 0 [0x0]))
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-11-19 02:11
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-19 02:12
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 02:13
---
Objective-C is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-11-19 02:14
---
HP-UX 10 is not a primary platform, but this seems an easy fix; let's fix it if
we can.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #24 from pcarlini at suse dot de 2005-11-19 02:15 ---
(In reply to comment #23)
> Created an attachment (id=10289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10289&action=view) [edit]
> mf hack
>
> For the record, here's the aforementioned hack.
Ok, thanks. Over th
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-11-19 02:15
---
68k is not a primary/secondary platform, but bootstrap failures are obviously
bad. Let's fix this if we can.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-19 02:16
---
S390 is not release critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-19 02:18
---
Should this bug go into WORKSFORME state?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-11-19 02:18
---
Should be an easy fix.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-19 02:19
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-11-19 02:19
---
Should be fixed before release.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-11-19 02:20
---
Showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-11-19 02:21
---
This is annoying warning; let's fix.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-19 02:22
---
This is too obscure to be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-19 02:26
---
Subject: Bug 8355
Author: mmitchel
Date: Sat Nov 19 02:25:55 2005
New Revision: 107207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107207
Log:
PR c++/8355
* decl.c (grokfndecl): Set up D
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-19 02:31
---
Here is a shorter testcase:
long fff(int*);
long F2(int *node)
{
long call_result = 0;
if (call_result = fff(node))
goto error_free_node;
T(node);
return 0;
error_free_node:
T(node);
return call_result;
--- Comment #25 from pcarlini at suse dot de 2005-11-19 02:33 ---
(In reply to comment #23)
> And it does appear to change the behaviour of one of the testsuite tests,
> but it doesn't fix both of them. I'll claim, then, that it didn't fix either
> of them, but merely changed the timing
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:36 ---
Subject: Re: FAIL: gcc.dg/attr-weakref-1.c
> Does this target actually support weak declarations? It appears to me that it
> only does when the assembler supports .weak, but even then, the linker will
> o
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-19 02:37
---
Hmm:
Simplifying condjump 15 around jump 67
Merged 2 and 3 without moving.
But the edge is the same now :)
as:
Cross jumping from bb 1 to bb 2; 2 common insns
Deleted label in block 3.
But we don't delete the co
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 02:38
---
Fixed in 4.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-19 02:42
---
Hmm:
what changed is:
if (n_branch != 1 && any_condjump_p (BB_END (bb))
- && JUMP_LABEL (BB_END (bb)) != BB_HEAD (fallthru->dest))
+ && JUMP_LABEL (BB_END (bb)) == BB_HEAD (fallthru->dest))
--- Comment #27 from lucier at math dot purdue dot edu 2005-11-19 02:42
---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
I don't know what Apple's priorities are here, but it would be really
nice to get 64-bit dynamic libraries working on Darwin. (Or maybe
they
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:44 ---
Subject: Re: [4.1 Regression] internal compiler error: verify_flow_info failed
> But the edge is the same now :)
> as:
> Cross jumping from bb 1 to bb 2; 2 common insns
> Deleted label in block 3.
>
> Bu
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:51 ---
Subject: Re: [4.1 Regression] libobjc testsuite failures
> --- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 02:13
> ---
> Objective-C is not release-critical.
This is only one of s
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 02:52
---
(In reply to comment #13)
> This sounds familiar ;(
It should because it was:
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02416.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-19 02:55
---
This is related to the old PR 10024 which has the same instruction.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-19 03:06
---
(In reply to comment #12)
> Hmm:
> what changed is:
>if (n_branch != 1 && any_condjump_p (BB_END (bb))
> - && JUMP_LABEL (BB_END (bb)) != BB_HEAD (fallthru->dest))
> + && JUMP_LABEL (BB_END
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
03:41 ---
Subject: Re: [4.1 Regression] internal compiler error: verify_flow_info failed
> >if (n_branch != 1 && any_condjump_p (BB_END (bb))
> > - && JUMP_LABEL (BB_END (bb)) != BB_HEAD (fallthru->
--- Comment #28 from geoffk at geoffk dot org 2005-11-19 04:40 ---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
On 18/11/2005, at 6:42 PM, lucier at math dot purdue dot edu wrote:
> --- Comment #27 from lucier at math dot purdue dot edu
> 2005-11-19 02:42 ---
--- Comment #29 from geoffk at gcc dot gnu dot org 2005-11-19 04:42 ---
This is really '3rd party to resolve'. It shouldn't be fixed in GCC, but
rather in Apple's libtool.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #30 from geoffk at gcc dot gnu dot org 2005-11-19 04:56 ---
libtool -arch_only ppc64 doesn't work with -L paths
containing '..'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
--- Comment #11 from hp at gcc dot gnu dot org 2005-11-19 07:18 ---
Between "Sat Nov 12 22:59:48 UTC 2005 (revision 106840M)"
and "Sun Nov 13 07:41:36 UTC 2005 (revision 106853M)"
there was a changed that made the -Os case now pass,
still true with "Fri Nov 18 17:28:22 UTC 2005 (revision
--- Comment #31 from lucier at math dot purdue dot edu 2005-11-19 07:50
---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
Can you explain what Apple's libtool has to do with it? Is it used
by gcc to find these libraries at link time?
Brad
--
http://gcc.gnu.or
101 - 152 of 152 matches
Mail list logo
