[Bug fortran/26681] internal compiler error
--- Comment #5 from pault at gcc dot gnu dot org 2006-03-15 08:14 --- Herve, > So what ? Is there a patch which I should use to correct this error ? Do > you need more info to reproduce this ICE ? Please ask and I will try to > provide all the available info. > Thanks. The could you post the modules sparsem and kinds, please? Your code does not do very well without them... if you get them to me, I will see if I can identify the problem >From the message, you bug appears to be one that I introduced, in a patch for references to function results from contained results, which has just been fixed by Jakub Jelenik. You can download the latest binary from the gfortran wiki. I believe that Francois-Xavier Coudert rebuilds every night. 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. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26681
[Bug fortran/24558] ENTRY doesn't work in module procedures
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-15 08:15 --- I am working on this one slowly but making progress nonetheless. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24558
[Bug java/26688] New: Classpath Makefiles assume CVS source control
The makefiles for classpath, as included in the libjava tree, run find to gather lists of specific files (for META-INF etc). The matched files are then copied to the build tree. However, the command lines used for the find invocations specifically mention 'CVS' as a directory to exclude; since gcc has switched to subversion, '.svn' should be excluded instead. I /think/ this only impacts the list of files in the build tree, and as such is fairly trivial, but I suppose the files may end up being included in some jar file too. -- Summary: Classpath Makefiles assume CVS source control Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim dot vanholder at anubex dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
[Bug c/26689] New: internal compiler error, avr-gcc
/var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/xgcc
-B/var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/ -B/usr/local/avr/avr/bin/
-B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include -O2 -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -isystem ./include -DDF=SF -Dinhibit_libc
-mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include
-DL_udivmoddi4 -c ../../gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o
libgcc/./_udivmoddi4.o
../../gcc/libgcc2.c: In function `__udivmoddi4':
../../gcc/libgcc2.c:731: error: insn does not satisfy its constraints:
(insn 1006 1005 1007 0xb7fdc604 (set (mem:QI (plus:HI (reg:HI 26 r26 [30])
(const_int 1 [0x1])) [2 S1 A8])
(reg:QI 24 r24 [268])) 9 {*movqi} (insn_list 1005 (insn_list 1435
(nil)))
(expr_list:REG_DEAD (reg:QI 24 r24 [268])
(nil)))
../../gcc/libgcc2.c:731: internal compiler error: in
extract_constrain_insn_cached, at recog.c:2090
Please submit a full bug report,
with preprocessed source if appropriate.
I tried to build avr-gcc on Arch linux current as described in this artickle:
http://www.tldp.org/linuxfocus/English/November2004/article352.shtml
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.3/configure --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu --prefix=/usr --enable-shared
--enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.3
$ abs
$ cd /var/abs/base/gcc/
$ makepkg
$ cd /var/abs/base/gcc/src/
$ make dist-clean
$ mkdir obj-avr
$ cd /var/abs/base/gcc/src/gcc-3.3.6/obj-avr
$ ../configure --target=avr --prefix=/usr/local/avr --disable-nls
--enable-language=c
$ make
--
Summary: internal compiler error, avr-gcc
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slansky at usa dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26689
[Bug c/26689] internal compiler error, avr-gcc
--- Comment #1 from slansky at usa dot net 2006-03-15 09:06 --- $ /var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/xgcc -v Using built-in specs. Configured with: ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-language=c Thread model: single gcc version 3.3.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26689
[Bug c++/26690] New: ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
The following invalid OpenMP-C++ code snippet crashes the compiler
when compiled with -fopenmp:
===
struct A
{
A(int);
};
void foo()
{
A a(0);
#pragma omp parallel private (a)
;
}
===
bug.cc: In function 'void foo()':
bug.cc:9: error: no matching function for call to 'A::A()'
bug.cc:3: note: candidates are: A::A(int)
bug.cc:2: note: A::A(const A&)
bug.cc:9: internal compiler error: in get_callee_fndecl, at tree.c:5806
Please submit a full bug report, [etc.]
--
Summary: ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26690
[Bug target/26687] gcc -O1 -fno-pic generates bad code that references uninitialized r31
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-15 09:57 --- with powerpc-unknown-linux and 4.1.0 I get (-O1 -fno-pic -mbss-plt) broken: cmpwi 7,4,0 beq 7,.L2 lis 9,[EMAIL PROTECTED] lfd 0,[EMAIL PROTECTED](9) b .L4 .L2: lis 9,[EMAIL PROTECTED] lfd 0,[EMAIL PROTECTED](9) .L4: stfd 0,0(3) blr -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC host triplet|gcc version 4.0.0 20041026 | |(Apple Computer, Inc. build | |4061), OS | GCC target triplet|gcc version 4.0.0 20041026 |powerpc-apple-darwin |(Apple Computer, Inc. build | |4061), OS | Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26687
[Bug c++/26691] New: Wrong code for constructor with default value
The compiler creates wrong code for the following valid OpenMP-C++
code snippet when compiled with "-fopenmp":
===
#include
struct A
{
int n;
A(int i=3) : n(i) {}
};
int main()
{
A a;
#pragma omp parallel private (a)
std::printf("%d\n", a.n);
return 0;
}
===
Instead of OMP_NUM_THREADS times the output "3"
I get one "1" and OMP_NUM_THREADS-1 times "0".
In addition I get a bogus warning with "-O -Wall -fopenmp"
which is probably just another symptom of the problem above:
bug.cc: In function 'void _Z3foov.omp_fn.0(void*)':
bug.cc:6: warning: 'i' is used uninitialized in this function
--
Summary: Wrong code for constructor with default value
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug c++/13717] duplicated parameter name not caught ?
--- Comment #4 from dcb314 at hotmail dot com 2006-03-15 10:42 --- (In reply to comment #0) > The one liner > > void f( int fred, char * fred); > > is IMHO illegal code because fred is the name of two parameters. I just checked gcc 4.2 and it is broken there as well. Even adding flags -Wall -ansi -pedantic doesn't help -- dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13717
[Bug other/26692] New: Build configure misses valid ld in hidden test
The latest binutils from (linux) kernel.org is: GNU ld version 2.16.91.0.6 The version test in gcc/configure fails (I think) because it doesn't check for five digit groups in the version number. I hand-edited configure to add an extra line that tests for the extra group and that seemed to work. This issue makes the build think that the linker doesn't support 'hidden'; then an attempt to compile glibc with the resulting compiler gives: checking whether __attribute__((visibility())) is supported... no and glibc can't be built. -- Summary: Build configure misses valid ld in hidden test Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at datatone dot co dot uk GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692
[Bug other/26692] Build configure misses valid ld in hidden test
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 12:27 --- (In reply to comment #0) > The latest binutils from (linux) kernel.org is: > GNU ld version 2.16.91.0.6 Don't use That binutils. That is not an official FSF binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692
[Bug target/26687] gcc -O1 -fno-pic generates bad code that references uninitialized r31
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 12:33 --- This comes from the following pattern: (define_insn "movdf_low_si" [(set (match_operand:DF 0 "gpc_reg_operand" "=f,!r") (mem:DF (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b,b") (match_operand 2 "" ""] "TARGET_MACHO && TARGET_HARD_FLOAT && TARGET_FPRS && !TARGET_64BIT" But this has been fixed in 4.1.0 by: 2005-10-08 Andrew Pinski <[EMAIL PROTECTED]> PR target/24136 * config/rs6000/darwin.md (movdf_low_si): Remove early clobber. Rewrite for no need for the early clobber. 2005-09-13 Andrew Pinski <[EMAIL PROTECTED]> * config/rs6000/darwin.md (movdf_low_si): Mark the outgoing r constraint as early clobber. Rewrite so the PIC register is not implicitly used. I rewrote this part so that there was no need for the PIC register. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26687
[Bug middle-end/26691] Wrong code for constructor with default value
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 12:58 ---
Hmm, the IR looks fine in .gimple:
struct A a;
__comp_ctor (&a, 3);
#pragma omp parallel private(a)
{
{
int D.2487;
D.2487 = a.n;
printf (&"%d\n"[0], D.2487);
}
}
D.2488 = 0;
return D.2488;
But broken in omplower:
__comp_ctor (&a, 3);
{
#pragma omp parallel private(a) [child fn: main.omp_fn.0 (???)]
{
__comp_ctor (&a);
D.2495 = a.n;
D.2487 = D.2495;
printf (&"%d\n"[0], D.2487);
OMP_RETURN
}
}
D.2488 = 0;
return D.2488;
Looks like we don't create the correct ctor for a, the one with the 3 as an
agrument.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-03-15 12:58:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug c++/26690] ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 13:00 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-15 13:00:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26690
[Bug c++/26691] Wrong code for constructor with default value
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 13:09 ---
Hmm, on second thought I think this is a front-end bug.
And here is a self contained testcase:
struct A
{
int n;
A(int i=3) : n(i) {}
};
int main()
{
A a;
#pragma omp parallel private (a)
if (a.n!=3) __builtin_abort();
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug middle-end/26679] [4.2 Regression] boostrap failure due to warning in gcc/varasm.c
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-15 13:13 --- Fixed by: 2006-03-14 Richard Guenther <[EMAIL PROTECTED]> * configure: Regenerate with autoconf 2.13. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26679
[Bug target/26689] internal compiler error, avr-gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 13:14 --- *** This bug has been marked as a duplicate of 14149 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26689
[Bug target/14149] [3.3 Regression] libgcc2.c:731: internal compiler error: in extract_constrain_insn_cached, at recog.c:2090
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-15 13:14 --- *** Bug 26689 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||slansky at usa dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14149
[Bug c++/26693] New: [4.0/4.1/4.2 regression] Access checks not performed for types in templates
The following invalid code is accepted since GCC 3.4.0:
class A
{
private:
typedef int X;
};
template int foo() { return A::X(); } // A::X is private!
int i=foo<0>();
If I make foo a non-template function, the code is correctly rejected.
--
Summary: [4.0/4.1/4.2 regression] Access checks not performed for
types in templates
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug middle-end/26643] [4.0/4.1/4.2 Regression] Linux matroxfb_probe miscompiled
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-03-15 13:21 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00925.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg00925.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug c++/26693] [4.0/4.1/4.2 regression] Access checks not performed for types in templates
--- 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||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-03-15 13:24:24 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug target/26695] New: -mabi=ieeelongdouble / undefined reference to _q_add.
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
(...)
/tmp/cccCMXjm.o: In function
`long double __add(long double, long double)':add.cpp
(.text._Z5__addIeET_S0_S0_[_Z5__addIeET_S0_S0_]+0x70):
undefined reference to `_q_add'
i have a gcc-4.1.1snap with patches from PR25864.
--
Summary: -mabi=ieeelongdouble / undefined reference to _q_add.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: ppc-linux
GCC host triplet: ppc-linux
GCC target triplet: ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26695
[Bug c++/26696] New: ICE with statement forming unused static member function reference
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 mingw cross compiler I'm using here) seems to be
affected too.
--
Summary: ICE with statement forming unused static member function
reference
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug target/26695] -mabi=ieeelongdouble / undefined reference to _q_add.
--- 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
[Bug c++/26696] [4.0/4.1/4.2 Regression] ICE with statement forming unused static member function reference
--- 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||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i586-suse-linux | GCC host triplet|i586-suse-linux | GCC target triplet|i586-suse-linux | Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-03-15 14:16:40 date|| Summary|ICE with statement forming |[4.0/4.1/4.2 Regression] ICE |unused static member|with statement forming |function reference |unused static member ||function reference Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug c++/26696] [4.0/4.1/4.2 Regression] ICE with statement forming unused static member function reference
--- 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?id=26696
[Bug target/26695] -mabi=ieeelongdouble / undefined reference to _q_add.
--- 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] ] `-mabi=ABI-TYPE' Extend the current ABI with a particular extension, or remove such extension. Valid values are ALTIVEC, NO-ALTIVEC, SPE, NO-SPE, IBMLONGDOUBLE, IEEELONGDOUBLE. ^^ `-mabi=ibmlongdouble' Change the current ABI to use IBM extended precision long double. This is a PowerPC 32-bit SYSV ABI option. `-mabi=ieeelongdouble' Change the current ABI to use IEEE extended precision long double. This is a PowerPC 32-bit Linux ABI option. [ /cite ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26695
[Bug libstdc++/26697] New: time_put::put('x') shows only 2 year digits, in en_GB locale.
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.
This is Ubuntu Linux's Dapper release (currently unstable):
[EMAIL PROTECTED]:~$ g++ --version
g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: time_put::put('x') shows only 2 year digits, in en_GB
locale.
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: murrayc at murrayc dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug c++/6634] wrong parsing of "long long double"
--- 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 accept long long double. Reorganize checks for invalid (combinations of) type modifiers. Quote modifiers in messages. g++.dg/parse/long1.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/long1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6634
[Bug c++/6634] wrong parsing of "long long double"
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6634
[Bug fortran/24520] Temporary constant array descriptors being declared at wrong binding level.
--- 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 function end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
[Bug other/26692] Build configure misses valid ld in hidden test
--- 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
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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 totally consistent with the C library strftime (you can check yourself in a pure C snippet). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug libgomp/26651] [gomp] #omp for ordered leaks memory
--- 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==by 0x11C2524F: gomp_new_work_share (work.c:48) ==25829==by 0x11C254E0: gomp_work_share_start (work.c:130) ==25829==by 0x11C24535: GOMP_loop_ordered_static_start (loop.c:154) ==25829==by 0x4006DF: main.omp_fn.0 (in /home/pinskia/a.out) ==25829==by 0x400699: main (in /home/pinskia/a.out) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-15 15:59:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26651
[Bug fortran/26681] internal compiler error
--- 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 just this one file, sorry I did not make that clear. Anyways this was fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26681
[Bug c++/26698] New: g++ accepts const-incorrect code due to conversion function
/*
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].
I think that diagnostics is required in this case.
Instead, g++ compiles this code, but the program
segfaults.
*/
struct X {
int x;
X ( int i = 0 )
: x ( i )
{}
operator X & ( void ) const {
return ( *this );
}
};
void add_one ( X & ref ) {
++ ref.x;
}
#include
int main ( void ) {
X const a ( 2 );
add_one( a );
std::cout << a.x << '\n';
}
--
Summary: g++ accepts const-incorrect code due to conversion
function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug other/26692] Build configure misses valid ld in hidden test
--- 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 from the gcc subdirectory? > > > Ah... I have taken your previous comment to heart and have replaced binutils with binutils-2.16.1. I am now recompiling the compiler and all is well with the hidden test. However, I will go back and recreate the kernel.org binutils situation ASAP. Regards, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692
[Bug c/26699] New: LD doesn't link in an object from an archive when the object has only public variables
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
Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/configure
--disable-checking --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^+.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/gcc/darwin/4.0/c++
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061)
Problem description:
I create a file "data.c" with herein a variable definition:
int winner = 666;
I compile data.c into data.o (gcc -c -o data.o data.c) and add it to libdata.a
using
ar rs libdata.a data.o
ranlib libdata.a
Now I compile a program that accesses the variable winner, e.g. the following
main.c:
#include
extern int winner;
int main () {
printf ("The winner is %d\n", winner);
return (0);
}
The compilation / linkage:
cc -o main.o main.c
cc -o main -L. -ldata main.o
BUG: ld won't select data.o out of libdata.a to link with main.o. There's an
unresolved reference to _winner.
--
Summary: LD doesn't link in an object from an archive when the
object has only public variables
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: karel at kubat dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26699
[Bug other/26699] LD doesn't link in an object from an archive when the object has only public variables
--- 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 has a reference to libdata, this fails as the linker are one pass linkers when looking for symbols. Change the order of the link line and it will work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |other Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26699
[Bug c++/26698] g++ accepts const-incorrect code due to conversion function
--- 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 to a reference to the same type will never use a type conversion operator t.cc:9: warning: conversion to a reference to the same type will never use a type conversion operator t.cc: In method `X::operator X &() const': t.cc:10: conversion from `const X' to `X &' discards qualifiers t.cc: In function `int main()': t.cc:23: conversion from `const X' to `X &' discards qualifiers t.cc:15: in passing argument 1 of `add_one(X &)' -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug target/26636] use of r1-r3 across __sdivsi3_4 call
--- 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.md, R1-R3 are clobbered in the define_expand for divsi3
(define_expand "divsi3"
[(set (match_dup 3) (symbol_ref:SI "__sdivsi3"))
(set (reg:SI R4_REG) (match_operand:SI 1 "general_operand" ""))
(set (reg:SI R5_REG) (match_operand:SI 2 "general_operand" ""))
(parallel [(set (match_operand:SI 0 "register_operand" "")
(div:SI (reg:SI R4_REG)
(reg:SI R5_REG)))
(clobber (reg:SI T_REG))
(clobber (reg:SI PR_REG))
(clobber (reg:SI R1_REG))
(clobber (reg:SI R2_REG))
(clobber (reg:SI R3_REG))
(use (match_dup 3))])]
{
rtx first, last;
operands[3] = gen_reg_rtx (Pmode);
...
last = gen_divsi3_i4 (operands[0], operands[3]);
The define_insn for divsi3_i4 does not have the R1-R3 clobbers as they did in
2.95.3
(define_insn "divsi3_i4"
[(set (match_operand:SI 0 "register_operand" "=y")
(div:SI (reg:SI R4_REG) (reg:SI R5_REG)))
(clobber (reg:SI PR_REG))
(clobber (reg:DF DR0_REG))
(clobber (reg:DF DR2_REG))
(use (reg:PSI FPSCR_REG))
(use (match_operand:SI 1 "arith_reg_operand" "r"))]
"TARGET_SH4 && ! TARGET_FPU_SINGLE"
"jsr @%1%#"
[(set_attr "type" "sfunc")
(set_attr "fp_mode" "double")
(set_attr "needs_delay_slot" "yes")])
in 2.95.3:
(define_insn "divsi3_i4"
[(set (match_operand:SI 0 "register_operand" "=y")
(div:SI (reg:SI 4) (reg:SI 5)))
(clobber (reg:SI 18))
(clobber (reg:SI 17))
(clobber (reg:DF 24))
(clobber (reg:DF 26))
(clobber (reg:SI 0))
(clobber (reg:SI 1))
(clobber (reg:SI 2))
How is the clobber list for define_expand insn expected to work? Should it
clobber for all emitted rtl insns?
Adding:
(clobber (reg:SI R1_REG))
(clobber (reg:SI R2_REG))
(clobber (reg:SI R3_REG))
to the "divsi3_i4" insn gets around the problem, but is that the proper
solution?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
[Bug testsuite/25891] gomp tests run on non-libgomp (non-thread) ports, failing all
--- 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 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- 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
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- 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 the sprintf
statement and the number 32 (buffer size) in the snprintf statement. This
fixed the LDBL_MAX problem but the test still failed on the LDBL_MIN part of
the test.
The attached C program fails on IA64 because the printf rounds the last digit
of MIN_LDBL down when it prints it and so it can't be read back in. The basic
problem is that LDBL_MAX and LDBL_MIN (or for that matter DBL_MIN and DBL_MAX)
cannot be represented exactly in decimal form so printf has to do some rounding
that may make the process non-reversable when trying to go back via strtod or
strtold. I looked to see if there was a float or double version of this test
and I didn't find one, if there was one I think it would fail on some platforms
because the write/read sequence is not gauranteed to return the original value
due to possible rounding during the writing and/or reading process.
#include
#include
#include
main()
{
char buffer[64];
long double x = LDBL_MIN;
sprintf(buffer, "%63.40Le", x);
printf("==%s==\n", buffer);
errno = 0;
x = strtold(buffer, 0);
printf("errno = %d\n", errno);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- 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 -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug java/26617] A class from an unnamed package is visible to classes in named packages
--- 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||13607 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-03-15 16:51:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26617
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- 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) = 1 10 continue return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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
[Bug libgcj/8995] race cases in interpreter
--- 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 these instructions with 0x1 when the datum is unresolved. This can be tested reasonably quickly. And, since these lookups are all idempotent, it does not matter if two threads happen to do a small amount of redudant lookup work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8995
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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 believe the behavior is a *bug*. I mean, what evidence do you have that the en_GB locale data should be different? About time_get, we don't use a glibc function directly, but certainly we query the very same locale data, same issue, more or less. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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 confusion because it is a loss of data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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 with 4. 2 digits lead to confusion because it is a loss > of data. In *principle*, I can well agree with you, but I'm afraid that reasoning is not sufficient. What about the "C" locale? It also uses 2 digits, and if it can, then, well, any other locale can. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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 it tomorrow morning. This won't help compiling tonto-chem. AFAICT, this code is riddled with nonstandard code. I can't compile it with either gfortran or NAG's F95 compiler. Additionally, it's rather odd build infrastructure makes it hard to follow what's going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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, even if that human is using the C locale.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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 who are in chanrge of the minute locale data details, not at all an easy task, if you ask me ;) > (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, > even if that human is using the C locale.) Maybe, again, but note that if we are talking about the "C" locale, the C Standard itself mandates %m/%d/%y. If you ask me, after so many years of code relying on that specific behavior, trying to change it now is an almost *impossible* task, really. By the way, can't you just prepare a small function consistently using 'Y', just a few lines, after all... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
[Bug libstdc++/26697] time_put::put('x') shows only 2 year digits, in en_GB locale.
--- 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.cgi?id=26697
[Bug libstdc++/26701] New: std::time_get parses only 2 digits of year, in en_GB locale.
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=2, year=1920 Maybe time_get tries to use the strftime date format only, which uses 2 digits only for display in en_GB. [EMAIL PROTECTED]:~$ g++ --version g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: std::time_get parses only 2 digits of year, in en_GB locale. Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: murrayc at murrayc dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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 it's obviously an implementation error to use _only_ that information for parsing. -- murrayc at murrayc dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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 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 it's obviously > an implementation error to use _only_ that information for parsing. ""Error"" is a wrong term, really. Maybe the QoI could be improved, but not so much, after all, please read also DR 461: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461 Ok, let's consider this one as an enhancement request. -- pcarlini at suse dot de changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-15 17:57:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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 just looked at the C++ standard, and you are right: "Each get member parses a format as produced by a corresponding format specifier to time_put<>::put. " " "In other words, user confirmation is required for reliable parsing of user-entered dates and times, but machine-generated formats can be parsed reliably. This allows parsers to be aggressive about interpreting user variations on standard formats. " I guess those other Standard C++ Library implementation are expanding on the standard, and it's not clear whether they should do that. Thanks. My disappointment is now with the C++ Standard instead. If only it had a bugzilla. -- murrayc at murrayc dot com changed: What|Removed |Added Severity|enhancement |normal Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug libstdc++/26701] std::time_get parses only 2 digits of year, in en_GB locale.
--- 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, many members of the committee read that list. In fact, many people are not happy with the time_get and time_put facets and it's very likely that in the next standard, C++0x, will be very different, could even disappear completely, because not many people are using those facilities and most are open coding functions dealing with dates anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
[Bug tree-optimization/25985] [4.2 Regression] with optimization integer math fails
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- 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_interface_method_index): Don't put into interface table. libjava PR java/26390: * link.cc (get_interfaces): Skip . (append_partial_itable): Likewise. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/libjava/ChangeLog trunk/libjava/link.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug c/26702] New: Size of static variables always zero on arm-elf
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 6: 0 NOTYPE LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ gcc -c foo.c $ readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 5: 4 OBJECT LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ arm-elf-gcc --version | head -1 arm-elf-gcc (GCC) 4.1.0 $ arm-elf-readelf --version | head -1 GNU readelf 2.16.91 20060309 $ gcc --version | head -1 gcc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) $ readelf --version | head -1 GNU readelf 2.16.91-multiarch 20060118 Debian GNU/Linux -- Summary: Size of static variables always zero on arm-elf Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sjackman at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- 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
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug tree-optimization/25985] [4.2 Regression] with optimization integer math fails
--- 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 -= 8;
} else {
break;
}
}
return 0;
}
And then compare 4.1 vs 4.2, I get the following observation:
in 4.1, it changed bits > 7 to use the iv, while in 4.2, it changed the bits !=
0 to use the iv
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
[Bug java/26638] Mauve crypto test failures
--- 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: trunk/gcc/java/ChangeLog trunk/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26638
[Bug java/26638] Mauve crypto test failures
--- 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|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26638
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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_foo in a BSS > using lcomm but I could be wrong. This might not be a gcc bug. $ arm-elf-readelf -S foo.o There are 8 section headers, starting at offset 0x7c: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 00 00 AX 0 0 1 [ 2] .data PROGBITS 34 00 00 WA 0 0 1 [ 3] .bss NOBITS 34 04 00 WA 0 0 4 [ 4] .comment PROGBITS 34 12 00 0 0 1 [ 5] .shstrtab STRTAB 46 35 00 0 0 1 [ 6] .symtab SYMTAB 0001bc 90 10 7 8 4 [ 7] .strtab STRTAB 00024c 19 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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 invoking gcc > with -S. It does not appear to use lcomm for static_foo. If it's not a gcc bug, is it a gas bug or a binutils bug? -- sdj $ arm-elf-gcc -S foo.c $ cat foo.s .file "foo.c" .bss .align 2 static_foo: .space 4 .comm foo,4,4 .ident "GCC: (GNU) 4.1.0" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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
[Bug libgcj/26688] Classpath Makefiles assume CVS source control
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-15 19:45:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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 object file? $ cat foo.c int foo; static int static_foo = 1; $ arm-elf-gcc -c foo.c $ arm-elf-readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 5: 4 OBJECT LOCAL DEFAULT2 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ arm-elf-gcc -S foo.c $ cat foo.s .file "foo.c" .data .align 2 .type static_foo, %object .size static_foo, 4 static_foo: .word 1 .comm foo,4,4 .ident "GCC: (GNU) 4.1.0" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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 with respect to Fortran 95 and earlier.
Making UNKNOWN-gfc4x-on-FREEBSD/modules/vec_int_module.mod ...
Target ./UNKNOWN-gfc4x-on-FREEBSD/modules/vec_int_module.mod does not exist,
compilation forced.
set noglob && /mnt1/sgk/bin/gfc4x -I. -I./UNKNOWN-gfc4x-on-FREEBSD/modules -O
-c -o ./UNKNOWN-gfc4x-on-FREEBSD/objects/vec\{int}.o
UNKNOWN-gfc4x-on-FREEBSD/f95files/vec\{int}.F90
In file UNKNOWN-gfc4x-on-FREEBSD/f95files/vec{int}.F90:804
integer(4), dimension(n_elements_uncommon_with_(self,v)) :: res
1
Error: Expression at (1) must be of INTEGER type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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
[Bug target/26702] Size of static variables always zero on arm-elf
--- 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 'static int foo;' >foo.c $ arm-elf-gcc -S foo.c -obss.s $ diff -u data.s bss.s --- data.s 2006-03-15 13:08:17.0 -0700 +++ bss.s 2006-03-15 13:08:17.0 -0700 @@ -1,8 +1,6 @@ .file "foo.c" - .data + .bss .align 2 - .type foo, %object - .size foo, 4 foo: - .word 1 + .space 4 .ident "GCC: (GNU) 4.1.0" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
[Bug tree-optimization/25985] [4.2 Regression] with optimization integer math fails
--- 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 CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
[Bug testsuite/25891] gomp tests run on non-libgomp (non-thread) ports, failing all
--- 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 gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org AssignedTo|hp at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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/intvec.F90 /usr/gcc-4.2/bin/gfortran -I. -I./GCC-gfortran-on-LINUX/modules -O -c -o ./GCC-gfortran-on-LINUX/objects/intvecvec.o f95files/intvecvec.F90 /usr/gcc-4.2/bin/gfortran -I. -I./GCC-gfortran-on-LINUX/modules -O -c -o ./GCC-gfortran-on-LINUX/objects/intvecintvechash.o f95files/intvecintvechash.F90 /usr/gcc-4.2/bin/gfortran -I. -I./GCC-gfortran-on-LINUX/modules -O -c -o ./GCC-gfortran-on-LINUX/objects/intvecmat3.o f95files/intvecmat3.F90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug java/26138] Lots of warnings with gcj .jar -> .so
--- 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, TYPE_ATABLE_SYMS_DECL, TYPE_ITABLE_SYMS_DECL here. I don't think it was put in 4.1.x -- do we want it there? -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26138
[Bug tree-optimization/25985] [4.2 Regression] with optimization integer math fails
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-26 23:28:04 |2006-03-15 20:22:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
[Bug libgcj/25934] fast instanceof checking
--- 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 question are concrete, we will use the 'ancestors' array to do a constant-time check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25934
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- 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
[Bug target/26695] -mabi=ieeelongdouble / undefined reference to _q_add.
--- 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 define, glibc has definitions of these functions (except it wrongly defines _q_uitoq instead of _q_utoq) but you'll need to get a glibc version with those definitions built in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26695
[Bug libmudflap/26704] New: ICE compiling with -fmudflap
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] Difference: -fmudflap [EMAIL PROTECTED] gcc --version gcc (GCC) 4.0.3 (Debian 4.0.3-1) [EMAIL PROTECTED] uname -ar Linux netfires-aptest 2.6.16-rc6-mm1_local_00 #1 PREEMPT Mon Mar 13 12:37:07 MST 2006 i686 GNU/Linux It's a Pentium 4 1.5GHz running Debian unstable. [EMAIL PROTECTED] gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 (Debian 4.0.3-1) Source: Coming soon. -- Summary: ICE compiling with -fmudflap Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwcrocombe at raytheon dot com GCC build triplet: i486-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26704
[Bug libmudflap/26704] ICE compiling with -fmudflap
--- 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/bugzilla/show_bug.cgi?id=26704
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- 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/show_bug.cgi?id=19303
[Bug java/26706] New: [4.1/4.2] Unexpanded macro in libjava/classpath/configure
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 Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug libgcj/26706] [4.1/4.2] Unexpanded macro in libjava/classpath/configure
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-15 22:37:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug classpath/26707] lib/Makefile.am should ignore .svn directories
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26707
[Bug libgcj/26688] Classpath Makefiles assume CVS source control
--- 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 CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
[Bug java/26138] Lots of warnings with gcj .jar -> .so
--- 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
