--- Comment #9 from gdr at gcc dot gnu dot org 2006-01-19 07:48 ---
Fixed in 4.0.3 and higher. Won't fix in 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-01-19 07:48
---
I've checked in the fix for 4.1 and 4.2. It doesn't apply directly
to earlier branches because they used TREE_LISTs for CONSTRUCTORs.
A straight-forward conversion would introduce a linear walk over
the list, whic
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-01-19 07:46
---
Subject: Bug 25805
Author: rsandifo
Revision: 109946
Modified property: svn:log
Modified: svn:log at Thu Jan 19 07:46:15 2006
--
--- svn
--- Comment #20 from dick_guertin at yahoo dot com 2006-01-19 07:45 ---
Created an attachment (id=10672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10672&action=view)
Contains a testcase in source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-01-19 07:45
---
Subject: Bug 25805
Author: rsandifo
Revision: 109947
Modified property: svn:log
Modified: svn:log at Thu Jan 19 07:45:28 2006
--
--- svn
--- Comment #2 from backes at rhrk dot uni-kl dot de 2006-01-19 07:36
---
Created an attachment (id=10671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10671&action=view)
faulty source
It seems to be an error in the source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=258
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-01-19 06:59
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-19 06:55
---
Subject: Bug 25836
Author: mmitchel
Date: Thu Jan 19 06:55:53 2006
New Revision: 109945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109945
Log:
PR c++/25836
* cp-tree.h (push_class_stack
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-01-19 06:55
---
> Good news, I think I found the problem. Bad news, I can't think of any
> solution. Please read my comments at the end of this information:
Thanks for your efforts.
> What I've discovered is that the -O2 opt
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-19 06:53
---
Subject: Bug 25836
Author: mmitchel
Date: Thu Jan 19 06:53:34 2006
New Revision: 109944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109944
Log:
PR c++/25836
* cp-tree.h (push_class_stack
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-19 06:53
---
Subject: Bug 25836
Author: mmitchel
Date: Thu Jan 19 06:52:56 2006
New Revision: 109943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109943
Log:
PR c++/25836
* cp-tree.h (push_class_stack
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-19 06:51
---
Oh, you are depending on the order of the static/global variables. That is
undefined C.
Try -O2 -fno-unit-at-a-time. If that works this is NOT, I will repeat NOT a
GCC bug as you are depending on undefined code.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 06:50 ---
This is an error but not always a bug in GCC. It is most likely a bug in the
WindowMaker source.
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I downloaded the WindowMaker-0.92.0.tar.gz and tried to compile it under
FedoraCore4, AMD XP 3200+.
The compilation breaks with the following error message:
gmake[1]: Entering directory `/tmp/WindowMaker-0.92.0/wrlib'
Making all in .
gmake[2]: Entering directory `/tmp/WindowMaker-0.92.0/wrlib'
`ec
--- Comment #17 from dick_guertin at yahoo dot com 2006-01-19 06:41 ---
I went back and recompiled all modules with -O -g to see what effect this has
on the order of static data. What I found was that all static data occurred in
memory in the order declared in the source code. This was
On x86_64, with -m32 I get:
FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors)
Excess errors:
/usr/bin/ld: skipping incompatible
/home/pinskia/src/checkin/trunk/objdir.c/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.so
when searching for -lgomp
/usr/bin/ld: skipping incompatible
/home/
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-19 04:58 ---
Confirmed fixed by:
2006-01-16 Daniel Berlin <[EMAIL PROTECTED]>
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from dick_guertin at yahoo dot com 2006-01-19 04:50 ---
I recompiled with -O2 -fno-gcse and got this:
Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0,
stack_ptr=0xffbef3d8, routine_result=0xffbef35c)
at scan.c:1452
1452kwp += 1;
--- Comment #13 from gccbugzilla at multiwebinc dot com 2006-01-19 04:38
---
Please help so I can get this fixed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-19 04:04
---
I wonder if this is at all related to PR 25654 and PR 25130.
Can you try "-O2 -fno-gcse"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
--- Comment #14 from dick_guertin at yahoo dot com 2006-01-19 04:00 ---
Good news, I think I found the problem. Bad news, I can't think of any
solution. Please read my comments at the end of this information:
typedef struct nkw
{
char tok[16];/* TOKEN, BLANK P
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-19 01:00
---
Closing as won't fix based on GDR's comments.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 00:59 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-19 00:55
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-19 00:53
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-01-19 00:38
---
Right, forgot about that... At the moment I can't think of testcase that would
break the transitivity without use of unions...
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 00:19
---
(In reply to comment #10)
> My understanding of C type based aliasing rules always was that char, as an
> exception, might alias with everything. Perhaps I lived in false belief for a
> while, but at least -Wstric
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-19 00:15 ---
(In reply to comment #7)
> I am trying to build a cross compiler for host i686-pc-cygwin and target
> h8300-hms. I built binutils, bootstrap GCC and newlib successfully. ( using
> binutils-2.16, newlib-1.14.0 and gcc
--- Comment #10 from hubicka at gcc dot gnu dot org 2006-01-19 00:14
---
My understanding of C type based aliasing rules always was that char, as an
exception, might alias with everything. Perhaps I lived in false belief for a
while, but at least -Wstrict-aliasing seems to think so:
ib
--- Comment #18 from gdr at cs dot tamu dot edu 2006-01-19 00:09 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| There is some good advice at
that precisely prooves my point: it is a cod
--- Comment #7 from dharinih at yahoo dot com 2006-01-18 23:53 ---
I am trying to build a cross compiler for host i686-pc-cygwin and target
h8300-hms. I built binutils, bootstrap GCC and newlib successfully. ( using
binutils-2.16, newlib-1.14.0 and gcc-3.4.4. When I build the final gcc u
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-18 23:31
---
Subject: Bug 23282
Author: rakdver
Date: Wed Jan 18 23:31:16 2006
New Revision: 109920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109920
Log:
PR tree-optimization/23282
* tree-chrec.c (
--- Comment #31 from mark at codesourcery dot com 2006-01-18 23:28 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> --- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08
> ---
> We should
--- Comment #17 from sigra at home dot se 2006-01-18 23:23 ---
There is some good advice at http://www.gotw.ca/publications/advice98.htm which
says that one should be const-correct and use const whenever possible. (But I
do not suggest using const for return values.) This feature request
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 ---
We should at least avoid introducing a third variant of how we lay out these
nasty zero-sized friends. People actually use them. For example Wine uses
them to enforce compatible alignment and data layout with MS Wi
--- Comment #29 from mark at codesourcery dot com 2006-01-18 23:00 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
I think that we should do as follows.
Preserve the original value of maximum_field_alignment when doing
#pragma pack. Then, for zero-
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-18 22:37 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| > Isn't this a task for lint-like tool? GCC isn't such thing.
|
| Are you
--- Comment #15 from gdr at cs dot tamu dot edu 2006-01-18 22:35 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| > It does not make any sense to require the compiler to give a warning
| >
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-01-18 22:25
---
In retrospect, I wonder if we should be complaining about a using-declaration
in a template in the first place.
For example, is:
struct X { void f(); };
template
struct S : public T {
using X::f;
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:55 ---
I am going to mark this as depending on PR 25477 for now. I am almost ready to
submit the patch for PR 25477 again.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-01-18 21:55
---
I'm still wrestling with this PR.
As I suggested earlier, I turned off the caching of nested-name-specifiers
unless we're in the check_dependency_p case. However, that causes
g++.dg/parse/operator2.C to fail, fo
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:52 ---
Part of this will be fixed by the patch for PR 25477. The other parts I
submitted but I need to reply to the comments. There is two Fortran front-end
parts so I am going to keep this as the fortran front-end bug.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:51 ---
Mine. All mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.2.0
20060118 (experimental)
make: [check-gfortran] Error 1 (ignored)
[dranta:~/gfortran/ibin/gcc] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.4.0
Configured with: ../gcc/configure --prefix=/Users/dir
--- Comment #2 from hjl at lucon dot org 2006-01-18 21:45 ---
4.2 is fixed by
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01029.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24547
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:30 ---
Also looking at the code:
void* v = std::malloc(sizeof(__cxa_eh_globals));
if (v == 0 || __gthread_setspecific(init._M_key, v) != 0)
std::terminate();
This is a false postive as we do
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:26 ---
Can you first read:
http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#mem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
--- Comment #4 from janis at gcc dot gnu dot org 2006-01-18 21:24 ---
A regression hunt on powerpc-linux using the submitter's testcase identified
the following very large patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=69130
r69130 | mmitchel | 2003-07-09 08:48:08 + (Wed, 09 Jul 20
If you link in libpthread with a program that uses cerr, you leak 8 bytes of
memory (determined through Purify). I discovered this using a RHEL 3 WS box
and also had the same occur on a RHEL 4 AS box. This will not occur when you
use cout or clog in place of cerr, or if libpthread is not linked i
--- Comment #19 from tobi at gcc dot gnu dot org 2006-01-18 21:08 ---
Fixed on the mainline. I will backport the cross-jumping part to 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
--- Comment #9 from tobi at gcc dot gnu dot org 2006-01-18 21:07 ---
The committed patch fixes only part of the problem, this is still a quadratic
bottleneck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-18 20:54 ---
Subject: Bug 18937
Author: tobi
Date: Wed Jan 18 20:54:49 2006
New Revision: 109914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914
Log:
PR fortran/18540
PR fortran/18937
* gfortran.h (BBT_HEADER): Move d
--- Comment #18 from tobi at gcc dot gnu dot org 2006-01-18 20:54 ---
Subject: Bug 18540
Author: tobi
Date: Wed Jan 18 20:54:49 2006
New Revision: 109914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914
Log:
PR fortran/18540
PR fortran/18937
* gfortran.h (BBT_HEADER): Move
--- Comment #14 from sigra at home dot se 2006-01-18 20:49 ---
> Isn't this a task for lint-like tool? GCC isn't such thing.
Are you sure? http://directory.fsf.org/GNU/gcc.html says: "GCC provides many
levels of source code error checking traditionally provided by other tools
(such as
--- Comment #13 from sigra at home dot se 2006-01-18 20:41 ---
> It does not make any sense to require the compiler to give a warning
> in that case.
Read the subject again: "optional"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
--- Comment #12 from gdr at cs dot tamu dot edu 2006-01-18 20:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| >
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| > On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
| >
| > > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| > > ---
| > > (In reply t
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-18 20:30 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| std::cout << static_cast(t) << std::endl;
| }
|
| If "static_cast" would
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| std::cout << static_cast(t) << std::endl;
| }
|
| If "static_cast" would work, the compiler should warn.
given call-by-value, you must be joking.
-- Gaby
--- Comment #10 from gdr at cs dot tamu dot edu 2006-01-18 20:29 ---
Subject: Re: New: want optional warning for non-constant declarations that
could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| Declaring variables and parameters as constants is a very useful feat
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-18 20:26
---
Hmm, we actually produce better code on the mainline for my example in comment
#2:
_xtermEnvEncoding1:
movl_result.1525, %edx
movl$2, %eax
pushl %ebp
movl%esp, %ebp
--- Comment #2 from dj at redhat dot com 2006-01-18 20:23 ---
Subject: Re: New: Error in building libiberty
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 20:08 ---
Hmm, I don't think so as slwi only acts on the lower 32bits so the upper 32bits
have the same sign as before which might be invalid if the b+a overflows.
Actually optimial is:
_f1:
slwi r0,r3,1
add r
--- Comment #12 from hjl at gcc dot gnu dot org 2006-01-18 20:04 ---
Subject: Bug 25840
Author: hjl
Date: Wed Jan 18 20:04:50 2006
New Revision: 109909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109909
Log:
2006-01-18 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/25840
This C example:
int f1(int a)
{
int b = a*2;
return b+a;
}
---
Currently we produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,3,0
extsw 3,0
blr
-
We should be able to produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,0,3
blr
,so the "extsw
--- Comment #11 from hjl at lucon dot org 2006-01-18 19:48 ---
I am testing this patch now:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-18 19:39
---
(In reply to comment #9)
> Looks at interpret.s
This is a bug in java-signal.h:
# 61 "./include/java-signal.h"
asm ( ".byte 0 # Yes, this really is necessary\n" ".align 16\n" "__"
"restore_rt" ":\n" " movq $
--- Comment #9 from hjl at lucon dot org 2006-01-18 19:34 ---
Looks at interpret.s
.Ldebug_line0:
.text
.Ltext0:
.section.ctors,"aw",@progbits
.align 8
.quad _GLOBAL__I__Jv_soleInterpreterEngine
#APP
.byte 0 # Yes, this really is necess
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-18 19:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way ar
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-18 19:31 ---
Both prims.o and interpret.o are created from C++ code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-18 19:30 ---
Hmm:
interpret.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
prims.o: file fo
--- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
> On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
>
> > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
> > ---
> > (In reply to comment #3)
> >> const does nothing when it comes to local v
--- Comment #3 from armcc2000 at yahoo dot com 2006-01-18 19:28 ---
(In reply to comment #2)
>
> Kazu, does your patch for PR 23150 apply to 4.0? If so, would you please
> test that change?
I think we've tried that already.
Patch applies to 4.0.2 without problems, but is doesn't seem t
--- Comment #6 from hjl at lucon dot org 2006-01-18 19:23 ---
It looks like gcc puts some junks in .ctors section:
[EMAIL PROTECTED] .libs]$ objdump -s -j .ctors libgcj.so.7
libgcj.so.7: file format elf64-x86-64
Contents of section .ctors:
190c000 0
--- Comment #2 from hjl at lucon dot org 2006-01-18 19:14 ---
It depends on what kind of failure. This "Segmentation fault" is due to a
broken libgcj.so. It makes no senses to continue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 19:00 ---
Lets look:
## We don't actually care if it fails -- if it does, just make an
## empty file. This is simpler than trying to discover when mmap is
## not available.
so what is the problem here? This is not really a
--- Comment #13 from pault at gcc dot gnu dot org 2006-01-18 18:59 ---
Fixed on trunk and 4.1
Thanks and sorry
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pault at gcc dot gnu dot org 2006-01-18 18:59 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:58 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-01-18 18:57 ---
Fixed on trunk and 4.1
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Stat
While investigating PR 25840, I notice that when there is a fatal error during
libjava build, build doesn't stop. I found this in my build log:
creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db
creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n
classmap.
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:56 ---
Subject: Bug 25024
Author: pault
Date: Wed Jan 18 18:56:43 2006
New Revision: 109900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from pault at gcc dot gnu dot org 2006-01-18 18:56 ---
Subject: Bug 25785
Author: pault
Date: Wed Jan 18 18:56:43 2006
New Revision: 109900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:56 ---
Subject: Bug 20875
Author: pault
Date: Wed Jan 18 18:56:43 2006
New Revision: 109900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2006-01-18 18:56 ---
Subject: Bug 20869
Author: pault
Date: Wed Jan 18 18:56:43 2006
New Revision: 109900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from pault at gcc dot gnu dot org 2006-01-18 18:55 ---
Subject: Bug 20875
Author: pault
Date: Wed Jan 18 18:55:01 2006
New Revision: 109899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #11 from pault at gcc dot gnu dot org 2006-01-18 18:55 ---
Subject: Bug 25785
Author: pault
Date: Wed Jan 18 18:55:01 2006
New Revision: 109899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:55 ---
Subject: Bug 25024
Author: pault
Date: Wed Jan 18 18:55:01 2006
New Revision: 109899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-01-18 18:55 ---
Subject: Bug 20869
Author: pault
Date: Wed Jan 18 18:55:01 2006
New Revision: 109899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899
Log:
2006-01-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from laurent at guerby dot net 2006-01-18 18:49 ---
With 4.0.2:
$ gcc -c x-toolkit.adb
x-toolkit.ads:590:04: this instantiation requires "Tgx.Lists (body)"
x-toolkit.ads:590:04: but file "tgx-lists.adb" was not found
With 4.1:
$ gcc -c x-toolkit.adb
+=
--- Comment #5 from hjl at lucon dot org 2006-01-18 18:48 ---
I found this in my build log
creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db
creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n
classmap.db
make[5]: Leaving directory
`/export/bui
--- Comment #4 from hjl at lucon dot org 2006-01-18 17:47 ---
I rebuilt crt*.o* with -fno-toplevel-reorder -fno-unit-at-a-time and
recreated lib*.so. I still have the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #3 from ian at airs dot com 2006-01-18 17:39 ---
Building a cross-compiler did not shed any light on the problem.
Can anybody provide more information about what is going wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #2 from ian at airs dot com 2006-01-18 17:04 ---
I just reconfirmed that I don't see any problems running the libjava testsuite
on i686-pc-linux-gnu. And I don't have access to any x86_64 systems. So I
can't recreate this problem myself.
The backtrace suggests that there i
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-18 17:02 ---
Fixed in 4.1.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #10 from paulthomas2 at wanadoo dot fr 2006-01-18 16:45 ---
Subject: Re: [4.1/4.2 Regression] gfortran - incorrectly
issues an error on tests for optional arguments with assumed length
Dale,
>
>I am sorry that I upset you. It was completely unintentional.
>
>
>
I up
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
--- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
---
(In reply to comment #3)
const does nothing when it comes to local variables except for not
letting you
touch it in other expressions. It does nothing for op
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-18 16:29 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
> --- Comment #4 from pcarlini at suse dot de 2006-01-18 1
1 - 100 of 129 matches
Mail list logo
