--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 05:36 ---
And to PR 17519.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 05:35 ---
Hmm, related to PR 13983.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThis
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-16 05:08
---
PR23634 does not affect this PR. So only two bugs left. I checked by
commenting out the lines effecting compiling.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from mdorey at bluearc dot com 2006-03-16 04:31 ---
(In reply to comment #5)
> Nathan could you comment on this bug.
Two years with no comment. Is it because the Severity is set to Enhancement?
I'm convinced that the warning is incorrect, not missing, so I think the
Sev
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-03-16 03:15 ---
Actually, my previous comment is wrong, it is ivcanon (more precisely, # of
iterations analysis). Consider this testcase:
#include
void bla(int x)
{
if (x < -100)
exit (0);
}
int main(void)
{
int bits = 2
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-03-16 02:49 ---
"Added canonical iv..." seems correct to me (at least, -fno-tree-loop-ivcanon
does not fix the problem). However, -fno-tree-loop-ivcanon -fno-ivopts fixes
it, so it is mine anyway.
--
http://gcc.gnu.org/bugzil
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-16 02:48 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 02:16 ---
You need a newer cctools.
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-590.12.dmg
works for me on 10.3.9 just fine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-16 01:59 ---
I fixed this in GCC svn.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-16 01:58 ---
Subject: Bug 26688
Author: tromey
Date: Thu Mar 16 01:58:38 2006
New Revision: 112116
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112116
Log:
PR libgcj/26688:
* lib/Makefile.in: Rebuilt.
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-16 01:54 ---
Subject: Bug 26688
Author: tromey
Date: Thu Mar 16 01:54:51 2006
New Revision: 112115
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112115
Log:
PR libgcj/26688:
* lib/Makefile.in: Rebuilt.
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-03-16 01:42 ---
Subject: Bug 26142
Author: bkoz
Date: Thu Mar 16 01:42:24 2006
New Revision: 112114
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112114
Log:
2006-02-22 Paolo Carlini <[EMAIL PROTECTED]>
* include/
--- Comment #7 from sayle at gcc dot gnu dot org 2006-03-16 01:21 ---
Subject: Bug 26557
Author: sayle
Date: Thu Mar 16 01:20:57 2006
New Revision: 112111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112111
Log:
PR middle-end/26557
* stmt.c (emit_case_nodes):
Building SVN rev 112107 of gcc/trunk on my PowerPC G4 OS X 10.3.9
(powerpc-apple-darwin7.9.0)
/Users/perrin/gcc_MAINLINE/gcc/configure
--prefix=/Users/perrin/gcc_MAINLINE/INSTALL/112107/ --enable-languages=c
--enable-threads=posix --disable-multilib
and then
make -j 2 bootstrap && make install
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-16 00:19 ---
I'm not certain that this should be fixed in Classpath.
After all, Classpath doesn't use svn.
I have a fix for libgcj which I will check in soon.
--
tromey at gcc dot gnu dot org changed:
What|Rem
--- Comment #12 from hjl at lucon dot org 2006-03-16 00:14 ---
I(In reply to comment #11)
> Subject: Re: [meta-bug] Gfortran can't compile tonto
>
>
> On Mar 15, 2006, at 6:28 PM, hjl at lucon dot org wrote:
>
> >
> >
> > --- Comment #10 from hjl at lucon dot org 2006-03-15 23:2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 23:57 ---
Fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-15 23:33
---
Subject: Re: [meta-bug] Gfortran can't compile tonto
On Mar 15, 2006, at 6:28 PM, hjl at lucon dot org wrote:
>
>
> --- Comment #10 from hjl at lucon dot org 2006-03-15 23:28 ---
> (In reply to comment
On Mar 15, 2006, at 6:28 PM, hjl at lucon dot org wrote:
--- Comment #10 from hjl at lucon dot org 2006-03-15 23:28 ---
(In reply to comment #9)
(In reply to comment #8)
Is that the exact output?
Yes, of course!
I assum you tried to compile f95files/intvec.F90. I have no probl
--- Comment #10 from hjl at lucon dot org 2006-03-15 23:28 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Is that the exact output?
>
> Yes, of course!
>
I assum you tried to compile f95files/intvec.F90. I have no problem with it:
[EMAIL PROTECTED] tonto]$ perl Makefile.
--- Comment #5 from aph at gcc dot gnu dot org 2006-03-15 23:15 ---
Oh yes, definitely. It was just waiting for the branch to be unfrozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26138
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 23:00 ---
*** Bug 26707 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-03-15 23:00 ---
*** This bug has been marked as a duplicate of 26688 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
This is an issue for both 4.1 branch and trunk.
$ grep GCC_ libjava/classpath/configure
GCC_NO_EXECUTABLES
--
Summary: [4.1/4.2] Unexpanded macro in
libjava/classpath/configure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Comment #21 from patchapp at dberlin dot org 2006-03-15 22:30 ---
Subject: Bug number PR 19303
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00980.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #1 from rwcrocombe at raytheon dot com 2006-03-15 21:19 ---
Created an attachment (id=11056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11056&action=view)
Bzipped2 result of g++ -I. -fmudflap -E -save-temps CLU_message.cpp > blob.cpp
--
http://gcc.gnu.org/bugzil
Bad:
[EMAIL PROTECTED] g++ -I. -fmudflap -c CLU_message.cpp
CLU_message.cpp: In constructor 'CLU_message::CLU_message(const std::string&)':
CLU_message.cpp:23: internal compiler error: Segmentation fault
.
.
.
[EMAIL PROTECTED]
Good:
[EMAIL PROTECTED] g++ -I. -c CLU_message.cpp
[EMAIL PROTECTED]
--- Comment #3 from joseph at codesourcery dot com 2006-03-15 21:14 ---
Subject: Re: New: -mabi=ieeelongdouble / undefined
reference to _q_add.
On Wed, 15 Mar 2006, pluto at agmk dot net wrote:
> undefined reference to `_q_add'
This function is an ABI-defined function libc should d
--- Comment #9 from kargl at gcc dot gnu dot org 2006-03-15 20:42 ---
(In reply to comment #8)
> Is that the exact output?
Yes, of course!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-15 20:26 ---
Now I think we don't need to do anything here.
We already handle the common cases.
For instance, if the target is an interface we will use
the IDT to do this test. This is reasonably fast.
Also if both classes in q
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-15 20:19 ---
This was fixed on the trunk by:
2006-02-15 Andrew Haley <[EMAIL PROTECTED]>
* class.c (GEN_TABLE): Don't pushdecl *_SYMS_DECL here.
(make_class_data): pushdecl_top_level TYPE_OTABLE_SYMS_DECL,
--- Comment #8 from hjl at lucon dot org 2006-03-15 20:18 ---
Is that the exact output? I couldn't find similar thing in my log. The
closest things I have are
/usr/gcc-4.2/bin/gfortran -I. -I./GCC-gfortran-on-LINUX/modules -O -c -o
./GCC-gfortran-on-LINUX/objects/intvec.o f95files/intve
--- Comment #6 from hp at gcc dot gnu dot org 2006-03-15 20:17 ---
Well Joern, I fixed the bug in this PR, so whatever happens now is a new bug.
I'm unassigning myself; I'm not sure I should re-close the PR, maybe Joern
wants to pick it up and treat it as the same PR; CC:ed.
--
hp at
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-15 20:15 ---
I'm sure Zdenek has an idea...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from sjackman at gmail dot com 2006-03-15 20:10 ---
Subject: Re: Size of static variables always zero on arm-elf
GCC is not emitting the type or size information for static bss symbols.
-- sdj
$ echo 'static int foo = 1;' >foo.c
$ arm-elf-gcc -S foo.c -odata.s
$ echo '
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-15 20:02 ---
Ok, this is a GCC bug for not outputing .size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #7 from kargl at gcc dot gnu dot org 2006-03-15 20:01 ---
(In reply to comment #6)
> Please point out the non-standard code in tonto in detail. I will report it to
> our SPEC people.
>
I believe that the code associated with gfortran's error message
is nonstandard at least
--- Comment #6 from sjackman at gmail dot com 2006-03-15 20:01 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 19:07:12 -, pinskia at gcc dot gnu dot org > Can
you try one more thing:
> static int static_foo = 1;
>
> And then use readelf -s on the ob
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #6 from hjl at lucon dot org 2006-03-15 19:31 ---
Please point out the non-standard code in tonto in detail. I will report it to
our SPEC people.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-15 19:07 ---
Can you try one more thing:
static int static_foo = 1;
And then use readelf -s on the object file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #4 from sjackman at gmail dot com 2006-03-15 19:03 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 18:53:53 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> No I mean what is the assembly output from GCC which you get by inv
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-15 18:53 ---
No I mean what is the assembly output from GCC which you get by invoking gcc
with -S.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #2 from sjackman at gmail dot com 2006-03-15 18:51 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 18:38:46 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> What does the output of -S show? I bet it is just putting static_f
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Subject: Bug 26638
Author: tromey
Date: Wed Mar 15 18:45:02 2006
New Revision: 112094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112094
Log:
Correctly reference PR java/26638 in ChangeLogs
Modified:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-15 18:40 ---
Hmm, if I change the function to be:
#include
int main(void)
{
int bits = 25;
while (bits) {
printf("bits=%d\n",bits);
if (bits >= 8) {
bits -
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 18:38 ---
What does the output of -S show? I bet it is just putting static_foo in a BSS
using lcomm but I could be wrong. This might not be a gcc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-15 18:31 ---
Oops -- that was the wrong PR number in that patch.
That commit was for PR 26638.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
When an object file is compiled by arm-elf-gcc 4.1.0, nm -S 2.16.*
always shows zero as the size of a static variable.
Thanks,
Shaun
$ cat foo.c
int foo;
static int static_foo;
$ arm-elf-gcc -c foo.c
$ arm-elf-readelf -s foo.o | grep foo
1: 0 FILELOCAL DEFAULT ABS foo.c
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-15 18:29 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 15 18:29:44 2006
New Revision: 112093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112093
Log:
gcc/java
PR java/26390:
* class.c (get_interfac
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 18:27 ---
Loop 1 iterates 2 times.
Added canonical iv to loop 1, 2 iterations.
That is wrong, it iterates 3 times at this point (an interation has already
been peeled before the loop).
This is from .ivcanon.
--
http://g
--- Comment #7 from pcarlini at suse dot de 2006-03-15 18:08 ---
(In reply to comment #6)
> Thanks. My disappointment is now with the C++ Standard instead. If only it had
> a bugzilla.
Actually, it has one, sort of. You can send messages with your proposals to the
comp.std.c++ list, man
--- Comment #6 from murrayc at murrayc dot com 2006-03-15 18:02 ---
Admittedly the libstdc++ time_get::get_date() documentation does say that it
interprets it according to format "X", and now I understand what it meant. I
was looking at the dinkumware and roguewave documentation.
I have
--- Comment #5 from pcarlini at suse dot de 2006-03-15 17:57 ---
(In reply to comment #3)
> That's maybe excusable for display,
We are not talking about ""excuses"", we are talking about standard conforming
behavior.
but all the documentation that I
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 17:56 ---
The only true documentation there is about libstdc++ is the C++ standard.
What documentation have you been looking at?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
--- Comment #3 from murrayc at murrayc dot com 2006-03-15 17:51 ---
That's maybe excusable for display, but all the documentation that I can find
for time_get says that it should parse up to 4 year digits. You mention in the
other bug that the locale information is used for parsing, but
--- Comment #2 from pcarlini at suse dot de 2006-03-15 17:47 ---
I thought it was clear it's really the same issue?!? In the en_GB locale, 'x'
expands to %d/%m/%y, lower case y.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #1 from murrayc at murrayc dot com 2006-03-15 17:44 ---
Created an attachment (id=11054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11054&action=view)
testtimeget.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
The attached test case shows that std::time_get<> parses only the first 2
digits of years, and assumes that those are years in the 1900s. This is a loss
of data.
It gives this output, in an en_GB locale:
[EMAIL PROTECTED]:~$ ./a.out
The date as text: 01/02/2003
std::time_get result: day=1, month=
--- Comment #9 from murrayc at murrayc dot com 2006-03-15 17:43 ---
> By the way, can't you just prepare a small function consistently using 'Y',
just a few lines, after all...
I need to support all locales. I may have to special-case en_GB.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #8 from pcarlini at suse dot de 2006-03-15 17:41 ---
(In reply to comment #7)
> Maybe we can just call it an enhancement or improvement then?
Maybe, if the glibc people agree (and the UK people agree, of course: the issue
boils down to convincing the ISO/POSIX people in UK w
--- Comment #7 from murrayc at murrayc dot com 2006-03-15 17:33 ---
Maybe we can just call it an enhancement or improvement then?
(Thought I strongly feel that any date meant for humans to read must have 4
year digits and any use of 2 year digits for a human to read should be a bug,
eve
--- Comment #5 from kargl at gcc dot gnu dot org 2006-03-15 17:26 ---
(In reply to comment #4)
> You will be glad to hear that, at long last, I am putting the finishing
> touches
> to a patch for transfer. It needs comments and a fine-toothed combing of the
> code. I maybe will submit
--- Comment #6 from pcarlini at suse dot de 2006-03-15 17:22 ---
(In reply to comment #5)
> > I mean, what evidence do you have that the en_GB locale data should be
> > different?
>
> I see no reason why en_GB should want to show 2 year digits, while en_US and
> en_DE should be happy w
--- Comment #5 from murrayc at murrayc dot com 2006-03-15 17:20 ---
> I mean, what evidence do you have that the en_GB locale data should be
> different?
I see no reason why en_GB should want to show 2 year digits, while en_US and
en_DE should be happy with 4. 2 digits lead to confusio
--- Comment #4 from pcarlini at suse dot de 2006-03-15 17:17 ---
(In reply to comment #2)
> Thanks. So, can't we just reassign this to glibc then?
If you want, you can certainly file a glibc PR. However, I think you should
first try to understand whether there are real reasons to believ
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-15 17:17 ---
Despite what the original report says, we don't really want to
resolve all entries when compiling.
Also it would be best to avoid any kind of synchronization at all.
One idea would be to 'or' the argument to one of t
--- Comment #3 from murrayc at murrayc dot com 2006-03-15 17:11 ---
Oh, and before I submit a time_get function, do we use a glibc function for
time_get too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
--- Comment #2 from murrayc at murrayc dot com 2006-03-15 17:10 ---
Thanks. So, can't we just reassign this to glibc then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 17:10 ---
Reduced testcase:
subroutine adw_set
implicit none
real*8Adw_xabcd_8(*)
pointer( Adw_xabcd_8_ , Adw_xabcd_8 )
common/ Adw / Adw_xabcd_8_
integer n
Adw_xabcd_8(1:n) =
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-15 16:53 ---
You will be glad to hear that, at long last, I am putting the finishing touches
to a patch for transfer. It needs comments and a fine-toothed combing of the
code. I maybe will submit it tomorrow morning.
Paul Thomas
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:51 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #8 from pault at gcc dot gnu dot org 2006-03-15 16:49 ---
You will be glad to hear that, at long last, I am putting the finishing touches
to a patch for this. It needs comments and a fine-toothed combing of the code.
I maybe will submit it tomorrow morning.
Paul Thomas
-
--- Comment #12 from sje at cup dot hp dot com 2006-03-15 16:44 ---
At least on IA64, I don't think there is a way to make this test work. I tried
a change similar to yours. I also changed the setting of ndigits (uses the
magic number 27 in a couple of places), changed the number 31 in
--- Comment #11 from jb at gcc dot gnu dot org 2006-03-15 16:22 ---
Tentative patch here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00950.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-03-15 16:22 ---
The g++ tests still fail, see:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01000.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rmansfield at qnx dot com 2006-03-15 16:20 ---
I looked at the RTL generated to find what pass R1 was first introduced and it
was greg. It appears (I'm not certain since I'm still learning to read RTL) the
that no clobber happens for the divsi3_i4 insn.
Looking at sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:19 ---
Hmm, we used to get a warning in 3.2.3 and before:
t.cc:9: warning: conversion to a reference to the same type will never use a
type conversion operator
And it was rejected in 2.95.3:
t.cc:9: warning: conversion
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:16 ---
First this is not a bug.
Lets look at your link line:
cc -o main -L. -ldata main.o
What is saying to the linker is look at libdata first for symbols that are
required already and then look at main.o. Since main.o
Bug description: An object that has only public variables is placed in an
archive. Linking against that archive fails: probably ld doesn't link in the .o
from the archive because it contains only public variables.
gcc -v output: Reading specs from
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs
Con
--- Comment #3 from dave at datatone dot co dot uk 2006-03-15 16:12 ---
Subject: Re: Build configure misses valid ld in hidden test
pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 15:50
> ---
> Can you attach config.log fr
/*
The following piece of code should not compile:
According to [12.3.2/1], the conversion function
operator X&() cannot be called. However, its
presence tricks the compiler into thinking that
I has a license to initialize a non-const X& from a
const X&. This is illegal by [8.5.3/5].
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-15 16:10 ---
(In reply to comment #5)
> I do not believe that pr24558 is anything to do with this because there are no
> entry's in your code, unless they are in the modules.
Note I was taking about the library in general, not j
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 15:59 ---
Confirmed:
==25829== 68 bytes in 1 blocks are definitely lost in loss record 1 of 1
==25829==at 0x11B1E1FD: calloc (vg_replace_malloc.c:279)
==25829==by 0x11C232E0: gomp_malloc_cleared (alloc.c:48)
==25829==
--- Comment #1 from pcarlini at suse dot de 2006-03-15 15:53 ---
We can't do much about that: the underlying locale data is telling us that 'x'
expands in the en_GB locale to %d/%m/%y, note lower case y. In fact, we are
simply using a threadsafe version of strftime, for a behavior totall
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 15:50 ---
Can you attach config.log from the gcc subdirectory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 15:38 ---
You can expose the bug now with:
real, dimension(12) :: x, y
real:: z
do i = 1, 1000
z = g(x,y)
end do
print *, x
contains
function g(x, y)
real, dimension(:) :: x, y
real g
x = x + y
end functi
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-03-15 15:29
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-15 15:27
---
Subject: Bug 6634
Author: reichelt
Date: Wed Mar 15 15:27:11 2006
New Revision: 112084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112084
Log:
PR c++/6634
decl.c (grokdeclarator): Do not
As seen in the C++ test case here:
http://bugzilla.gnome.org/show_bug.cgi?id=334648
std::time_put<>::put(), with format 'x", shows only the last 2 digits of the
year, and there is no short-date format that shows all 4 digits. I notice that
the en_US and de_DE locales do not have this problem.
Th
--- Comment #2 from pluto at agmk dot net 2006-03-15 14:22 ---
(In reply to comment #1)
> Why are you using ieeelongdouble?
just for testing. is it enough reason?
> It is not really supported at all on PPC-linux.
so, for what gcc has such broken feature?
[ cite [EMAIL PROTECTED] ]
`
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 14:17 ---
Here is the ICE when checking is enabled:
t.cc:9: internal compiler error: tree check: expected field_decl, have baselink
in component_ref_field_offset, at expr.c:5757
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 14:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 14:12 ---
Why are you using ieeelongdouble? It is not really supported at all on
PPC-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26695
Testcase is short enough:
struct A
{
static void f() {}
};
int main()
{
A a;
a.f;
}
Produces a segfault on the line where "a.f" occurs. It should instead issue the
warning "statement is a reference, not call, to function A::f". gcc 4.1.0 (at
least the experimental
template < typename T >
T __add( T x, T y )
{
return x + y;
}
template float __add( float, float );
template double __add( double, double );
template long double __add( long double, long double );
$ g++ add.cpp -O -mabi=ieeelongdouble
cc1plus: warning: Using IEEE extended precision long double
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 13:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
1 - 100 of 120 matches
Mail list logo
