--- Additional Comments From hjl at lucon dot org 2005-06-20 06:23 ---
It is a linker bug. I posted a patch for ia32/x86_64:
http://sourceware.org/ml/binutils/2005-06/msg00500.html
--
What|Removed |Added
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 06:39
---
Ugh. Well, that's that way it used to work apparently now it's different.
Here, this gets to the same place, and removes some misleading bits in the
current configury.
-benjamin
--
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 06:39
---
Ugh. Well, that's that way it used to work apparently now it's different.
Here, this gets to the same place, and removes some misleading bits in the
current configury.
-benjamin
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-20
06:48 ---
Subject: Bug 22111
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-20 06:48:28
Modified files:
libstdc++-v3 : ChangeLog Makefile.in acinclude.m4
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 07:04
---
We need a way to test for this in autoconf instead of just using a version
number.
Doing this seems hard. Can somebody smart figure it out while I'm sleeping?
-benjamin
--
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-20
07:25 ---
Apparently it has been decided that co-arrays will be included in the next
revision of the Fortran standard. See http://www.nag.co.uk/sc22wg5/ and
ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1639.txt
When trying to compile gcc3.4.3 I get the following error
gmake[1]: Entering directory `/raid/tmp/gcc-3.4.3/gcc'
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
07:59 ---
So the regression is fixed on mainline. Changing subject and keyword.
Note that the ICE was apparently caused by a missing processing of the nested
procedure, probably middle-end rather than front-end
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
08:00 ---
Since ZCX is now the default on darwin and linux, and since I doubt
anyone will look at __builsetjmp/longjmp issues on GCC 4.x, I am
closing this PR.
--
What|Removed
--- Additional Comments From dcb314 at hotmail dot com 2005-06-20 08:10
---
I fiddled with the supplied patch, and got this
--- expr.c.sav 2005-06-18 14:45:34.0 +0100
+++ expr.c 2005-06-19 11:19:02.0 +0100
@@ -5537,6 +5537,20 @@
tree low_bound = (domain
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
08:12 ---
Closing, as discussed, it would be an undesirable performance hit to make
changes
in this area.
Arno
--
What|Removed |Added
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
08:48 ---
(In reply to comment #2)
This was fixed by reverting the patch which caused this.
Which patch was this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21848
--- Additional Comments From falk at debian dot org 2005-06-20 09:36
---
(In reply to comment #5)
I fiddled with the supplied patch, and got this
--- expr.c.sav2005-06-18 14:45:34.0 +0100
+++ expr.c2005-06-19 11:19:02.0 +0100
@@ -5537,6 +5537,20 @@
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-20
09:38 ---
Thanks a lot for fixing this so promptly. I can confirm that the code which
triggered this compiles now and seems to be working fine again with CVS HEAD.
(BTW, even with its share of bugs, CLN might be
--- Additional Comments From pcarlini at suse dot de 2005-06-20 10:39
---
Up-to-date baselines are now both in 4_0-branch and mainline.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-20
10:56 ---
The patch is ok, it removes the testsuite failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:04 ---
the linking is picking up the wrong libintl.
*** This bug has been marked as a duplicate of 12482 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:04 ---
*** Bug 22126 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:09 ---
(In reply to comment #3)
(In reply to comment #2)
This was fixed by reverting the patch which caused this.
Which patch was this?
2005-05-31 Pat Haugen [EMAIL PROTECTED]
* loop.c
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
13:05 ---
(In reply to comment #4)
2005-05-31 Pat Haugen [EMAIL PROTECTED]
* loop.c (loop_invariant_p, valid_initial_value_p): Revert last
change.
The last change was:
2005-05-30 Pat Haugen
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
13:21 ---
P.S.: I realize now that the code in gcc/java/jcf-io.c is no longer miscompiled
for i686-pc-linux-gnu because the memory addresses contain stack pointer
references, and the stack pointer is a fixed
--- Additional Comments From dir at lanl dot gov 2005-06-20 13:33 ---
My example no longer crashes on powerpc-apple-darwin7.9.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20970
--- Additional Comments From hjl at lucon dot org 2005-06-20 13:40 ---
I checked in the linker patch to fix it.
--
What|Removed |Added
Status|NEW
--- Additional Comments From dir at lanl dot gov 2005-06-20 13:46 ---
PR21083 ,also, works Ok on the powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20970
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
14:46 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01667.html.
--
What|Removed |Added
--- Additional Comments From abilalh at yahoo dot com 2005-06-20 14:52
---
(In reply to comment #7)
I think you're trying to configure and compile GCC in
the source folder. Unfortunately, this is not yet supported.
Try creating a new folder totally outside of the GCC source
tree
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-06-20 15:18 ---
Subject: Re: New IRIX 6.5 testsuite failures with gas: .space repeat count is
zero, ignored
echristo at redhat dot com writes:
Did you happen to catch where the .space 0 were being emitted
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is blocking me fixing the structure aliasing regressions.
This was caused by:
2005-06-15 Joseph S. Myers [EMAIL PROTECTED]
* c-tree.h (default_function_array_conversion): Declare.
* c-typeck.c
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is new, i assume.
This is blocking me fixing the structure aliasing regressions.
I've attached pex-unix.i. Compile with -pendantic to see the crash.
Here is a reduced testcase:
typedef union
{
union wait *__uptr;
int
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
call through a function pointer where fundecl would never have been
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-06-20 16:25 ---
I've tried to create a testcase but can't seem to get a crash or infinite loop
lockup.
Anyway, I think I understand conceptually what must be done, but in practice
I'm still unsure of how to go
I found that following program loops infinitely on SPARC if it is optimized.
% uname -a
SunOS mule 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-80
% cat tst.i
typedef unsigned int size_t;
extern int printf(const char *, ...);
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:04 ---
Hmm, why do you think getcontext should return twice?
It does not, GCC is emmitting correct asm for a normal function, why should
getcontext be different?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:05 ---
GCC is emmitting correct asm for a normal function, why should getcontext be
different?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote:
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
--- Additional Comments From akr at m17n dot org 2005-06-20 17:22 ---
It's because getcontext is similar to setjmp.
Since setjmp/getcontext doesn't save registers in register window, modifications
to the registers between first setjmp/getcontext return and longjmp/setcontext
call is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:27 ---
Does this work correctly with say Sun's compiler?
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:31 ---
Confirmed. This happens to work with 2.95.3 so we have a regression.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:32 ---
Does this work correctly with say Sun's compiler?
Yes it does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Additional Comments From akr at m17n dot org 2005-06-20 17:36 ---
Although I have no Sun's Compiler, I found some pragmas about header file in
SunOS:
#pragma unknown_control_flow(setjmp)
#pragma unknown_control_flow(_setjmp)
#pragma unknown_control_flow(sigsetjmp)
#pragma
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:36 ---
This is not a front-end bug. But I still think it accidentally worked in
2.95.3 or any compiler really
because why do we have to treat function special.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:43 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01685.html.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:46 ---
This is not a front-end bug.
I disagree, the front-end should automatically recognize the function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-20
17:48 ---
Subject: Re: [3.4/4.0/4.1 Regression] register window not preserved after
getcontext call
On Jun 20, 2005, at 1:46 PM, ebotcazou at gcc dot gnu dot org wrote:
--- Additional Comments From
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-20
17:59 ---
I can't reproduce this any more.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-20
18:00 ---
Subject: Bug 22077
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-20 17:59:36
Modified files:
gcc: ChangeLog combine.c
Added files:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
18:02 ---
Fixed on the mainline at least.
--
What|Removed |Added
AssignedTo|aldyh at gcc dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
18:42 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
19:05 ---
This works for me on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13849
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
19:08 ---
Actually this still fails at -O0 for me on powerpc-darwin.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
19:09 ---
(In reply to comment #4)
Actually this still fails at -O0 for me on powerpc-darwin.
I mean on the mainline:
gcc version 4.1.0 20050619 (experimental)
--
--- Additional Comments From kreckel at ginac dot de 2005-06-20 19:13
---
Subject: Re: [4.1 Regression] ICE: SSA_NAME verification
failure
On 20 Jun 2005, Ralf dot Wildenhues at gmx dot de wrote:
(BTW, even with its share of bugs, CLN might be a candidate for g++ regression
testing
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-20
19:17 ---
Subject: Bug 21257
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-20 19:17:33
Modified files:
gcc/fortran: ChangeLog match.c
Log message:
--- Additional Comments From abalkiss at redhat dot com 2005-06-20 19:18
---
Problem may be with layout managers instead of JScrollPane. Run the test case
from Additional Comment #1 and try changing the JFrame's layout manager to
BoxLayout or GridLayout. The problem no longer
--- Additional Comments From kargl at gcc dot gnu dot org 2005-06-20 19:22
---
Fixed on mainline. Will apply to 4.0.x when branch re-opens.
--
What|Removed |Added
The following test case causes gcj to hang:
public class Cyclic extends Cyclic
{
class C
{
class D extends C {}
}
}
The circularity error at the top level is correctly issued, however we later get
stuck in inherits_from_p when checking circularity for the inner classes.
--
I've found a case where it appears that the optimizer has reordered some code
surrounding the initialization of a local constant array, stomping on some of
the elements after they have been loaded with the correct values. Here's a
snippet of the source and resulting assembly that illustrates the
--- Additional Comments From cnewbold at mathworks dot com 2005-06-20
20:26 ---
Created an attachment (id=9119)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9119action=view)
pre-processed source which illustrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129
--- Additional Comments From cnewbold at mathworks dot com 2005-06-20
20:36 ---
I should add that this initialization problem also occurs for one other local
arrays in the example in addition to the one already noted: the array
plain on line 611.
The problem still manifests at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
20:39 ---
I don't see the problem on the mainline, maybe I not understanding what you
mean.
--
What|Removed |Added
--- Additional Comments From cnewbold at mathworks dot com 2005-06-20
20:46 ---
Subject: Re: Optimization stomps const,
initialized local array
On Mon, 2005-06-20 at 20:39 +, pinskia at gcc dot gnu dot org wrote:
I don't see the problem on the mainline, maybe I not
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
20:48 ---
on the mainline and the 4.0 branch and in 4.0.0, encrypted gets promoted to a
static const which works
around the bug.
Also note this is not a full testcase and cannot just run, so is there way to
get
--- Additional Comments From cnewbold at mathworks dot com 2005-06-20
20:51 ---
Subject: Re: [3.4 only] Optimization stomps
const, initialized local array
On Mon, 2005-06-20 at 20:48 +, pinskia at gcc dot gnu dot org wrote:
Also note this is not a full testcase and
--- Additional Comments From law at redhat dot com 2005-06-20 21:22 ---
Subject: Re: no compile time array index checking
On Mon, 2005-06-20 at 09:36 +, falk at debian dot org wrote:
--- Additional Comments From falk at debian dot org 2005-06-20 09:36
---
(In reply to
--- Additional Comments From marcus at jet dot franken dot de 2005-06-20
21:24 ---
this still happens for me even after:
2005-06-20 Jan Hubicka [EMAIL PROTECTED]
* cfgloop.h (DLTHE_RECORD_COPY_NUMBER): New flag.
* cfgloopmanip.c (duplicate_loop_to_header_edge):
--- Additional Comments From bangerth at dealii dot org 2005-06-20 21:30
---
Since this PR prevents me from running my nightly tests for more than 2 months
now, could someone try to run the regression finder on the small testcase to
find out who broke this and when? The duplicate of
--- Additional Comments From kreckel at ginac dot de 2005-06-20 22:16
---
Subject: Re: [4.1 Regression] ICE: SSA_NAME verification
failure
On Mon, 20 Jun 2005, Richard B. Kreckel wrote:
On 20 Jun 2005, Ralf dot Wildenhues at gmx dot de wrote:
(BTW, even with its share of bugs, CLN
fstream fails to create a file in ios::in| ios::out mode.
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
environment: 2.4.21-20.ELsmp i686 GNU/Linux
Sample Code:
#include errno.h
#include fstream
#include iostream
using namespace::std;
int
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22130
--- Additional Comments From schwab at suse dot de 2005-06-20 22:45 ---
You need to add ios::trunc if you want to create the file, see
[lib.filebuf.members] 27.8.1.3#2.
--
What|Removed |Added
--- Additional Comments From gary at intrepid dot com 2005-06-20 23:40
---
I guess that tagging the bug with a documentation keyword doesn't
necessarily say that the bug is being classified only as a defect in the
documentation. However, if that is the meaning of this keyword, then
The program below is expected to run successfully to completion but when
compiled with gcc 3.4.3 or 4.0.0 it aborts.
$ cat u.cpp g++ u.cpp ./a.out
#include locale
#include sstream
#include cassert
int main ()
{
struct Punct: std::numpunctchar {
std::string do_grouping () const {
--- Additional Comments From giovannibajo at libero dot it 2005-06-21
00:10 ---
Doesn't -fmudflap handle this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- Additional Comments From giovannibajo at libero dot it 2005-06-21
00:19 ---
Does my patch for 8271 fix this bug? If so, whatever caused this might just
have exposed the problem, and fixing 8271 would fix this as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
--- Additional Comments From law at redhat dot com 2005-06-21 01:20 ---
Subject: Re: no compile time array index checking
On Tue, 2005-06-21 at 00:10 +, giovannibajo at libero dot it wrote:
--- Additional Comments From giovannibajo at libero dot it 2005-06-21
00:10 ---
Upcasting a const class pointer for a class that was derived from a struct
causes the upcasted pointer to
incorrectly access members of the derived struct.
Conditions:
1) The derived class object must have a virtual destructor (or possibly any
v-table entries)
2) The upcast must be a straight
--- Additional Comments From scott dot tupaj at line6 dot com 2005-06-21
01:37 ---
Created an attachment (id=9120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9120action=view)
Sample code to illustrate bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
--- Additional Comments From scott dot tupaj at line6 dot com 2005-06-21
01:38 ---
Created an attachment (id=9121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9121action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
--- Additional Comments From scott dot tupaj at line6 dot com 2005-06-21
01:38 ---
Created an attachment (id=9122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9122action=view)
Compiler Info
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
--- Additional Comments From scott dot tupaj at line6 dot com 2005-06-21
01:38 ---
Created an attachment (id=9123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9123action=view)
Compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
For a detailed description of this bug see:
https://sourceforge.net/tracker/?func=detailatid=102435aid=1053052group_id=2435
In short the file c-incpath.c (near line 331) needs to be modified to remove the
trailing slash if HAVE_DOS_BASED_FILE_SYSTEM is true. It seems on newer windows
systems the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
03:05 ---
I think this is invalid, you want:
OBJ* p1 = const_castAnObject*(objPtr);
but I don't have prove at this point if this invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
03:16 ---
IIRC this was discussed on the gcc-patches or gcc list just this year.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22133
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
04:11 ---
See the thread: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01267.html.
I don't know what happened to it.
--
What|Removed |Added
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-21
05:37 ---
The actual reason for the wrong-code generation has not been fixed.
Moreover, AFAICS, on ACCUMULATE_OUTGOING_ARGS targets, the stack
pointer is loop invariant unless current_function_calls_alloca, and
86 matches
Mail list logo
