tory `/tmp/gfortran-20060118/ibin/libiberty'
gmake[2]: *** [all-stage1-libiberty] Error 2
gmake[2]: Leaving directory `/tmp/gfortran-20060118/ibin'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gfortran-20060118/ibin'
gmake: *** [all] Error 2
--
S
--- Comment #8 from uros at kss-loka dot si 2006-01-18 09:50 ---
(In reply to comment #7)
> Hmm, I get (but that looks like different branch predictions):
It looks that your default is -mtune=pentium.
> _testf:
> fldl4(%esp)
> ftst
> fnstsw %ax
> t
--- Comment #9 from uros at kss-loka dot si 2006-01-18 09:53 ---
Created an attachment (id=10666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10666&action=view)
patch to SVN GCC: (GNU) 4.2.0 20060117 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
--- Comment #3 from paolo at gcc dot gnu dot org 2006-01-18 11:22 ---
Subject: Bug 25824
Author: paolo
Date: Wed Jan 18 11:22:10 2006
New Revision: 109883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109883
Log:
2006-01-18 Perry Smith <[EMAIL PROTECTED]>
PR libstdc+
--- Comment #9 from paolo at gcc dot gnu dot org 2006-01-18 11:22 ---
Subject: Bug 25823
Author: paolo
Date: Wed Jan 18 11:22:10 2006
New Revision: 109883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109883
Log:
2006-01-18 Perry Smith <[EMAIL PROTECTED]>
PR libstdc+
--- Comment #4 from pcarlini at suse dot de 2006-01-18 12:38 ---
Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|00
--- Comment #10 from pcarlini at suse dot de 2006-01-18 12:39 ---
Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-01-18 13:31
---
> I rebuilt with -O2 AND -g, and got the following trace. Notice the while-loop
> in nscan, statements 1141 thru 1147 are four single statements. The "next"
> trace by gdb shows them occuring multiple times. T
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-01-18 13:38
---
> Notice that 'nscan' expects 'scancb' in %l0, but it is ZERO.
Better not trust GDB at -O2 on that one, it is easily fooled.
> It does NOT contain the value in R1 (aka: r1).
> (gdb) x/4bx &r1
> 0x2d6a0c : 0x00
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 14:07 ---
Hmm, ansidecl.h should have been included.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
--- Comment #9 from dir at lanl dot gov 2006-01-18 14:20 ---
Paul,
I am sorry that I upset you. It was completely unintentional.
Dale.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
Output of gcc -v:
-
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20060113/configure --disable-nls
--enable-languages=c,ada
--prefix=/disc/gbcc/home/chrisp/GNAT/koala/gcc4/native-20060113 --enable-libada
Threa
--- Comment #1 from hjl at lucon dot org 2006-01-18 14:40 ---
See
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00924.html
--
hjl at lucon dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Keywords||wrong-code
--- Comment #1 from holmana at adsmr dot co dot za 2006-01-18 14:34 ---
Created an attachment (id=10669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10669&action=view)
Files listed in bugbox, concatenated (suitable for gnatchop) (gzipped)
--
http://gcc.gnu.org/bugzilla/show_
Declaring variables and parameters as constants is a very useful feature that
should be used as much as possible. Therefore it would be very useful to have
an option to warn when something is not declared as constant eventhough it
could be, at least in C++ and probably in other languages as well.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 15:36 ---
Can you give an example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-18 15:45 ---
Subject: Bug 25731
Author: danglin
Date: Wed Jan 18 15:44:57 2006
New Revision: 109894
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109894
Log:
PR target/25731
* config.gcc (hppa*-*-linux*,
I have a problem with template construction compiled by g++ 4.0.2 (SuSE Linux).
The compiler populate following error message:
"test.cpp:17: error: a m_pData was not declared in this scope"
Previous release g++ 3.3.3 works fine.
template class c1T
{
public:
c1T () { }
~c1T (){ }
operator T*(
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-18 16:06
---
*** Bug 25846 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-01-18 16:06 ---
Please read http://gcc.gnu.org/gcc-3.4/changes.html.
This is a dup of bug 12970.
*** This bug has been marked as a duplicate of 12970 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from sigra at home dot se 2006-01-18 16:07 ---
Example 1:
{
int i = f();
do_something(i + 1, 7, 'h');
do_something_else(i % 3, 'e');
}
If i could be declared "const int", the compiler should warn.
Example 2:
float dra(float m, Panel & p) {
p.do_me(5);
return p.set_
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-18 16:13 ---
I still don't understand what this warning is useful for?
const does nothing when it comes to local variables except for not letting you
touch it in other expressions. It does nothing for optimizations or anythin
--- 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 optimizations or anything
> else.
This last point is not obvio
--- Comment #5 from sigra at home dot se 2006-01-18 16:25 ---
(In reply to comment #3)
> I still don't understand what this warning is useful for?
>
> const does nothing when it comes to local variables except for not letting
> you touch it in other expressions. It does nothing for o
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-18 16:30 ---
Subject: Bug 25731
Author: danglin
Date: Wed Jan 18 16:30:18 2006
New Revision: 109895
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109895
Log:
PR target/25731
* config.gcc (hppa*-*-linux*,
--- Comment #7 from pcarlini at suse dot de 2006-01-18 16:32 ---
(In reply to comment #6)
> 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.
Interesting example.
--- Comment #13 from danglin at gcc dot gnu dot org 2006-01-18 16:34
---
Fixed by patches on 4.0, 4.1 and trunk.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- 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
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 #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
--- 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 #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 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 #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 #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 #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 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 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 #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 #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 #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 #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 #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 #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/
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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
-
> > 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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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
"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 #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:
| --- 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 #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 ---
| >
--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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
/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 #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
--- 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 #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: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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 129 matches
Mail list logo
