Re: make distclean can not remove intl/config.cache
Ian Lance Taylor wrote:
Sounds like a bug.
May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
Thanks for your comments. Here is a patch for it.
2005-09-22 Yao Qi [EMAIL PROTECTED]
* gcc/intl/Makefile.in (distclean): Add config.cache.
* gcc/fixincludes/Makefile.in (distclean): Likewise.
Index: gcc/fixincludes/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/fixincludes/Makefile.in,v
retrieving revision 1.11
diff -c -r1.11 Makefile.in
*** gcc/fixincludes/Makefile.in 15 Aug 2005 00:50:43 - 1.11
--- gcc/fixincludes/Makefile.in 22 Sep 2005 05:18:28 -
***
*** 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
--- 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h config.cache
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
Index: gcc/intl/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/intl/Makefile.in,v
retrieving revision 1.5
diff -c -r1.5 Makefile.in
*** gcc/intl/Makefile.in13 May 2005 08:03:46 - 1.5
--- gcc/intl/Makefile.in22 Sep 2005 05:51:01 -
***
*** 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS
maintainer-clean: distclean
--- 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS config.status config.cache config.log
maintainer-clean: distclean
--
Regards, Yao
Yao Qi
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
1. Introduce a new BB bit flag and set it for the header BB of a loop that has no data dependencies. This approach already works, but only if the old loop optimizer (pass_loop_optimize) is disabled (otherwise the bit doesn't survive). Which will happen in 4.2. One potential problem is that the loop header BB may change between the tree-level and SMS as result of some optimization pass (can that really happen?) I don't know, but I'd not answer with a definite no. I'm not an expert, but ISTR that SMSable loops are all do-while loops, and composed of a single basic block If this is true, why not mark the loop *body* instead of the header? 3. Use insn_notes - introduce a new note NOTE_INSN_NO_DEPS_IN_LOOP to be inserted after the NOTE_INSN_LOOP_BEG for relevant loops. This is a no-no. pass_loop_optimize will disappear in 4.2, and loop notes will disappear together with it (and with much joy). Paolo
Re: warning about classpath import
David Daney writes: Tom Tromey wrote: I'm finally ready to do another classpath import, Do you plan on another classpath import before the 4.1 release? This is an interesting question. Potentially, a classpath import can have a hugely destabilizing effect. However, IMO each Classpath import is more solid than the previous one as bugs get fixed, so I'm in favour. But a radom cut of Classpath HEAD is perhaps not so stable. Hmm. Discuss... Andrew.
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
Hello, As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html I would like to improve SMS by passing data dependencies information computed in tree-level to rtl-level SMS. Currently data-dependency graph built for use by SMS has an edge for every two data references (i.e. it's too conservative). I want to check for every loop, using functions defined in tree-data-ref.c, if there are data dependencies in the loop. The problem is how to pass this information to SMS (note - we're only trying to convey whether there are no dependencies at all in the loop - i.e. one bit of information). The alternatives being considered are: 1. Introduce a new BB bit flag and set it for the header BB of a loop that has no data dependencies. This approach already works, but only if the old loop optimizer (pass_loop_optimize) is disabled (otherwise the bit doesn't survive). One potential problem is that the loop header BB may change between the tree-level and SMS as result of some optimization pass (can that really happen?) yes -- jump threading may change loop structures, although this is fairly easy to prevent. Loop optimizations can of course alter the structure of loops, but they should be able to preserve this type of informations. 2. Use a bitmap (as suggested in http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01353.html) that is indexed using the BB index. In my case I need to define and use the property within different functions. I can define a static function set_and_check_nodeps(bb_loop_header) and define a bitmap there. Like the previous solution, The problem that can arise is that some intermediate optimizations can change the header of the loop. By the way, is it guaranteed that a BB keeps the same index throught the entire compilation? No -- basic blocks are compacted from time to time, to fill in holes created by removal of dead blocks. Also, basic block numbers might change due to basic block splitting/merging in some optimizations. 3. Use insn_notes - introduce a new note NOTE_INSN_NO_DEPS_IN_LOOP to be inserted after the NOTE_INSN_LOOP_BEG for relevant loops. NOTE_INSN_LOOP_BEG should most definitely disappear in 4.2, and introducing insn notes seems like a bad idea to me. 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far be the cleanest approach -- admitedly also the one that requires the greatest amount of work. Zdenek
RE: warning about classpath import
Original Message From: Tom Tromey Sent: 21 September 2005 20:31 I'm finally ready to do another classpath import, and near the last minute I realized that the import may temporarily break the build, due to an unfortunate interaction between the classpath Makefile and the way cvs import works. FWIW I'd prefer to continue using cvs import since it does seem to help the process a little. Is this anything that could be fixed with a cvs admin -b immediately after the import? cheers, DaveK -- Can't think of a witty .sigline today
arguements used in .c.26.flow2 are not used in assembly codes
Hi,
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include math.h
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
The begining of the .s file is
rad2deg:
addisp, sp, -16
stw fp, 8(sp)
mov r6, zero
mov fp, sp
movhi r7, %hiadj(1080459264)
addir7, r7, %lo(1080459264)
stw ra, 12(sp)
stw r16, 4(sp)
stw r17, 0(sp)
call__muldf3
mov r4, zero
movhi r5, %hiadj(1072693248)
addir5, r5, %lo(1072693248)
mov r16, r2
mov r17, r3
callatan
..
The corresponding rtl to call __muldf3 in .c.26.flow2 file is
(call_insn/u 17 16 21 0 0x0 (parallel [
(set (reg:DF 2 r2)
(call (mem:QI (symbol_ref:SI (__muldf3)) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 31 ra))
]) 44 {*call_value} (insn_list 15 (nil))
(expr_list:REG_DEAD (reg:DF 4 r4)
(expr_list:REG_DEAD (reg:DF 6 r6)
(expr_list:REG_UNUSED (reg:SI 31 ra)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)
(expr_list (use (reg:DF 6 r6))
(expr_list (use (reg:DF 4 r4))
(nil
According to the rtl, it uses r4, r5, r6 and r7 as arguements. But the
assemble codes show no r4 or r5 is ever used before call __muldf3.
Any idea why it is so?
Thanks
Haibin
Problems with collect2, linking libgcc twice causing duplicate symbols
Hi all, first of all, sorry for possible double post, I just didn't get any answers from gcc-help-mailing list. I'm trying to compile OpenSSH 0.9.8 with gcc 3.4.3 (64-bit) on a HP-UX.11i and collect2 utility is doing something odd (as far as I can tell). It is linking libgcc twice (I guess because of the millicode routines unusual calling convention) which is causing my compilation to fail miserably with the following: Loading /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/libgcc.a[_muldi3.o]: ld: Duplicate symbol __muldi3 in files /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/libgcc.a[_muldi3.o] and /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/libgcc.a[_muldi3.o] . . continues with tens of dozens similar erros . The collect2 utility is invoked as follows: Reading specs from /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/specs Configured with: /usr1/cpt2k4p/gcc-3.4.3/configure --prefix=/vobs/prod/tools/gnu/gcc/HP-UX.11 --enable-threads=posix --disable-shared --disable-nls --enable-languages=c --enable-libstdcxx-v3 --with-as=/vobs/prod/opensource/binutils/HP-UX.11/bin/as --with-ar=/vobs/prod/opensource/binutils/HP-UX.11/bin/ar --with-ranlib=/vobs/prod/opensource/binutils/HP-UX.11/bin/ranlib Thread model: posix gcc version 3.4.3 /vobs/prod/tools/gnu/gcc/HP-UX.11/libexec/gcc/hppa64-hp-hpux11.11/3.4.3/collect2 +Accept TypeMismatch -z -E -b -o libcrypto.sl.0.9.8 /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/crtbeginS.o -L. -L/vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib/pa20_64 -L/opt/langtools/lib/pa20_64 -L/vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/../../.. -t -B symbolic +vnocompatwarnings -z +s +h libcrypto.sl.0.9.8 +forceload libcrypto.a -ldl -lgcc /usr/lib/pa20_64/milli.a -lgcc /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/crtendS.o Loading /vobs/prod/tools/gnu/gcc/HP-UX.11/lib/gcc/hppa64-hp-hpux11.11/3.4.3/crtbeginS.o: How could I avoid these duplicate symbols? I can post the whole compilation output if needed. br, Jussi Mononen
Succesfull build on i386-unknown-freebsd5.3
Hello [EMAIL PROTECTED] sgserv# srcdir/config.guess i386-unknown-freebsd5.3 sgserv# /usr/local/bin/gcc -v Using built-in specs. Target: i386-unknown-freebsd5.3 Configured with: ../srcdir/configure --with-arch=athlon-4 --with-tune=athlon-4 Thread model: posix gcc version 4.0.1 The following languages will be built: c,c++,f95,objc FreeBSD 5.3-RELEASE (SGKERNL) #2: Sun Sep 4 17:06:39 MSD 2005 There were no problems at all. Bye [EMAIL PROTECTED] ---Stargrave :::Created and sended by $Id: sgmail.pl,v 0.31 2005/09/19 19:09:45 stargrave Exp $
Re: [gomp] implement a handfull of easy directives
The builtins table is initialized with a separate .def file, but it
boils down to initializers this:
{ code, __builtin_name, C2_INT,
{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
This way I only have to write the type in one place, I only create the
function types I need, and the types are cached so I don't create the
same type more than once.
Much simpler in the long run, I think.
How are you handling putting attributes on these builtin functions?
RE: No effect of -fshort-enums..is it a bug
Thanks for the reply, but I did not get the answer to my question.
My question is:
In the below mentioned program
#include stdio.h
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(enum aa),sizeof(b),sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
)
The output is
size = 1 1 1
value= 0 127 128
when gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
And
size = 1 4 4
value= 0 127 128
when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Thanks
Gaurav gautam
-Original Message-
From: Gaurav Gautam, Noida
Sent: Wednesday, September 21, 2005 7:04 PM
To: 'gcc@gcc.gnu.org'; '[EMAIL PROTECTED]'
Cc: 'Daniel Jacobowitz'
Subject: RE: No effect of -fshort-enums..is it a bug
Thanks for the reply,
But why is there a difference in the output of same tc, with an old
gcc
compiler and a new version of compiler.
Was there a bug in the earlier gcc.
I have a doubt.
Gcc manual says that
-fshort-enums
Allocate to an enum type only as many bytes as it needs for the
declared range of possible values. Specifically, the enum type will be
equivalent to the smallest integer type which has enough room.
Does -fshort-enum guides the size of enumeration type or the size of
enumerator constant ?
After modifying the tc as
#include stdio.h
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(enum aa),sizeof(b),
sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
)
The output is
size = 1 1 1
value= 0 127 128
when gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
And
size = 1 4 4
value= 0 127 128
when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
Which of the two output is standard confirming.?
-Original Message-
From: Daniel Jacobowitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 21, 2005 6:10 PM
To: Gaurav Gautam, Noida
Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
Subject: Re: No effect of -fshort-enums..is it a bug
On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida
wrote:
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(a),sizeof(b),
sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
}
The option -fshort-enums has no effect and the output is same as
it is
without this option.
It's not a bug. Add sizeof(enum aa) to your printf; _that_ will be
affected by -fshort-enums. The type of the enumerators remains int.
--
Daniel Jacobowitz
CodeSourcery, LLC
Re: warning about classpath import
Dave == Dave Korn [EMAIL PROTECTED] writes: I'm finally ready to do another classpath import, and near the last minute I realized that the import may temporarily break the build, due to an unfortunate interaction between the classpath Makefile and the way cvs import works. FWIW I'd prefer to continue using cvs import since it does seem to help the process a little. Dave Is this anything that could be fixed with a cvs admin -b Dave immediately after the import? I've never used that, but based on the manual, I don't think so. The problem is that files that are new on the vendor branch will show up on HEAD immediately, and classpath will try to build them. Tom
RE: warning about classpath import
Original Message From: [EMAIL PROTECTED] Sent: 22 September 2005 15:25 Dave == Dave Korn [EMAIL PROTECTED] writes: I'm finally ready to do another classpath import, and near the last minute I realized that the import may temporarily break the build, due to an unfortunate interaction between the classpath Makefile and the way cvs import works. FWIW I'd prefer to continue using cvs import since it does seem to help the process a little. Dave Is this anything that could be fixed with a cvs admin -b Dave immediately after the import? I've never used that, but based on the manual, I don't think so. The problem is that files that are new on the vendor branch will show up on HEAD immediately, and classpath will try to build them. Tom Ah, that was part 2) of the problem, the bit I had trouble with was the way it kind-of auto-merges across any unchanged files by setting their default branch to vendor branch instead of trunk. What version of CVS are you using, and does it speak the -X option (new in 1.12.x)? http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_16.html#SEC155 cheers, DaveK -- Can't think of a witty .sigline today
Re: warning about classpath import
David == David Daney [EMAIL PROTECTED] writes: I'm finally ready to do another classpath import, David Do you plan on another classpath import before the 4.1 release? I think it depends a lot on timing; the sooner 4.1 ships the less inclined I would be to do another import. I want to see 4.1 ship with a reasonably up-to-date class library, though; for one thing the more recent the library, the more apps we can run. Tom
Re: [gomp] implement a handfull of easy directives
Daniel Berlin [EMAIL PROTECTED] writes:
The builtins table is initialized with a separate .def file, but it
boils down to initializers this:
{ code, __builtin_name, C2_INT,
{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
This way I only have to write the type in one place, I only create the
function types I need, and the types are cached so I don't create the
same type more than once.
Much simpler in the long run, I think.
How are you handling putting attributes on these builtin functions?
I didn't bother to show it, but I also have a code for which type of
attribute they should take. I build a table indexed by the code, and
pass the appropriate entry in to builtin_function. That part of it is
basically the way that builtins.def works today.
Ian
Re: No effect of -fshort-enums..is it a bug
Gaurav Gautam, Noida wrote:-
#include stdio.h
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(enum aa),sizeof(b),sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
)
The output is
size = 1 1 1
value= 0 127 128
when gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
And
size = 1 4 4
value= 0 127 128
when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
4.1.0 is correct, therefore 3.3.1 was buggy.
Neil.
Re: No effect of -fshort-enums..is it a bug
Hi Gaurav, Please confirm which of the two outputs is correct and why is there a difference in the output of two versions of compiler? Both outputs are correct. (Neither output is compliant to the standard, of course, as -fshort-enums is a deviation from the standard.) Sincerely, --Eljay
GCC 4.0.2 RC3
The GCC 4.0.2 RC3 prerelease is spinning now. If all goes well, it will be available later today. FYI, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: No effect of -fshort-enums..is it a bug
On Thu, Sep 22, 2005 at 10:34:19AM -0500, John Love-Jensen wrote: Hi Gaurav, Please confirm which of the two outputs is correct and why is there a difference in the output of two versions of compiler? Both outputs are correct. (Neither output is compliant to the standard, of course, as -fshort-enums is a deviation from the standard.) That's incorrect, please read my response again. The current output is C99-conformant. (It is surprising, though, on many non-embedded targets. For instance there are considerable difficulties using this option on GNU/Linux.) -- Daniel Jacobowitz CodeSourcery, LLC
RE: No effect of -fshort-enums..is it a bug
Original Message From: John Love-Jensen Sent: 22 September 2005 16:34 Hi Gaurav, Please confirm which of the two outputs is correct and why is there a difference in the output of two versions of compiler? Both outputs are correct. No, the standard is entirely unambiguous: 6.4.4.3 Enumeration constants Syntax 1 enumeration-constant: identifier Semantics 2 An identifier declared as an enumeration constant has type int. The enumeration constants denoted by the identifiers a, b, and c are therefore of type int and must have size 4 (on a standard 32-bit system), regardless of the size of the enumerated type aa. (Neither output is compliant to the standard, of course, as -fshort-enums is a deviation from the standard.) Nope, the standard is entirely unambiguous: 6.7.2.2 Enumeration specifiers 4 Each enumerated type shall be compatible with an integer type. The choice of type is implementation-defined,97) but shall be capable of representing the values of all the members of the enumeration. The enumerated type is incomplete until after the } that terminates the list of enumerator declarations. The choice of what integer type to use to store a value of an enumerated type is implementation-defined, and if a char is big enough to represent all the values, the implementation is at liberty to use a char. cheers, DaveK -- Can't think of a witty .sigline today
Re: No effect of -fshort-enums..is it a bug
John Love-Jensen [EMAIL PROTECTED] writes: | Hi Gaurav, | | Please confirm which of the two outputs is correct and why is there a | difference in the output of two versions of compiler? | | Both outputs are correct. | | (Neither output is compliant to the standard, of course, as -fshort-enums is | a deviation from the standard.) This is incorrect and misleading. -- Gaby
Re: No effect of -fshort-enums..is it a bug
Hi Dave, Daniel, and Gaurav, For C99, I stand corrected. For C89 or C++98, I think my statement is applicable. (But until I double-check by reading those standards, take that with a grain of salt.) For all three, having enum be an int (signed or unsigned) is legit of course. For all three, having enum be a long is (at best) a compiler extension, at worst (-pedantic ?) not supported. If I'm reading the specs correctly. NOTE: not germane to Gaurav's question, just talking out loud. Sincerely, --Eljay
Re: No effect of -fshort-enums..is it a bug
Hi Gaby, Dave, Daniel, and Gaurav, This is incorrect and misleading. I concur. I retract my previous statement, and direct seekers-of-clarification to the previous posts that answered this issue. My apologies for my confusion. Sincerely, --Eljay
Re: No effect of -fshort-enums..is it a bug
John Love-Jensen [EMAIL PROTECTED] writes: | Hi Dave, Daniel, and Gaurav, | | For C99, I stand corrected. | | For C89 or C++98, I think my statement is applicable. No, for C++98 your statement is even more incorrect because enumerators (the constants) are NOT of type int -- and that has been so for looon time now that I'm surprise. In fact, I wish the enumeration underlying type were not int by default. But I suspect that for interoperability with C, it was decided -fshort-enum wasn't the default (I wish it was). -- Gaby
Re: No effect of -fshort-enums..is it a bug
Dave Korn wrote: Please confirm which of the two outputs is correct and why is there a difference in the output of two versions of compiler? Both outputs are correct. No, the standard is entirely unambiguous: of course, but the behavior of a compiler with a special implementation dependent switch is not specified by the standard! Switches can do any amount of violence to the standard you like, the only requirement is that there be a defined set of switches which gives standard defined semantics.
GCC 4.0.2 RC2 RTEMS Report
Mark Mitchell wrote: The GCC 4.0.2 RC3 prerelease is spinning now. If all goes well, it will be available later today. From an RTEMS perspective, 4.0.2RC2 with no patches appeared to be at least as good as 4.0.1 w/RTEMS patches. I spotted no new issues. I built a native C, C++, and Ada compiler and used that to build all the crosses. newlib 1.13.0 w/RTEMS patches was the C library. The targets built were: arm-rtems4.7: C C++ avr-rtems4.7: C h8300-rtems4.7: C C++ i386-rtems4.7: C C++ i686-pc-linux-gnu: C C++ m68k-rtems4.7: C C++ mips64-rtems4.7: C C++ mips-rtems4.7: C C++ powerpc-rtems4.7: C C++ sh-rtems4.7: C C++ sparc-rtems4.7: C C++ Ada did build for most of the targets. As I recall, arm and sh did not finish building. The sh had an ICE and the arm has some Ada specific issue. I did not investigate either enough to report. --joel
Re: warning about classpath import
Dave == Dave Korn [EMAIL PROTECTED] writes: Dave What version of CVS are you using, and does it speak the -X Dave option (new in 1.12.x)? Thanks! I didn't know that this was added; this addresses one of the biggest problems I've had with cvs import over the years. I'll try this out. Tom
Re: warning about classpath import
Gerald == Gerald Pfeifer [EMAIL PROTECTED] writes: Gerald On Thu, 22 Sep 2005, Tom Tromey wrote: I think it depends a lot on timing; the sooner 4.1 ships the less inclined I would be to do another import. I want to see 4.1 ship with a reasonably up-to-date class library, though; for one thing the more recent the library, the more apps we can run. Gerald It would also address some bugs (including regressions like Gerald #23499, which is not high priority, though), wouldn't it? Yes, definitely. Tom
Re: GCC 4.0.2 RC3
The GCC 4.0.2 RC3 prerelease is spinning now. Regressions on Solaris 2.6, 7, 8 and 9: FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test FAIL: ext/mt_allocator/check_delete.cc execution test FAIL: ext/mt_allocator/check_new.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test FAIL: ext/mt_allocator/tune-1.cc execution test FAIL: ext/mt_allocator/tune-2.cc execution test FAIL: ext/mt_allocator/tune-3.cc execution test FAIL: ext/mt_allocator/tune-4.cc execution test -- Eric Botcazou
Re: No effect of -fshort-enums..is it a bug
On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote: of course, but the behavior of a compiler with a special implementation dependent switch is not specified by the standard! Switches can do any amount of violence to the standard you like, the only requirement is that there be a defined set of switches which gives standard defined semantics. Except that the point I've been trying to make for the last day is that -fshort-enums does no damage to the standard. At least for C99. -- Daniel Jacobowitz CodeSourcery, LLC
Questionable code in fixup_reorder_chain
Hi Jan,
I think fixup_reorder_chain contains questionable code to cope with a
pathological case:
/* The degenerated case of conditional jump jumping to the next
instruction can happen on target having jumps with side
effects.
Create temporarily the duplicated edge representing branch.
It will get unidentified by force_nonfallthru_and_redirect
that would otherwise get confused by fallthru edge not pointing
to the next basic block. */
if (!e_taken)
{
rtx note;
edge e_fake;
bool redirected;
e_fake = unchecked_make_edge (bb, e_fall-dest, 0);
redirected = redirect_jump (BB_END (bb),
block_label (bb), 0);
gcc_assert (redirected);
Note the call to redirect_jump that creates a loop. It is responsible for the
ICE on the attached Ada testcase with the 3.4.5pre compiler at -O3 because the
edge and the jump disagree on the target.
The final patch: http://gcc.gnu.org/ml/gcc-cvs/2003-03/msg01294.html
The original version: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02097.html
Am I right in thinking that the call to redirect_jump must be removed?
Thanks in advance.
--
Eric Botcazou
WITH Text_IO;
PROCEDURE p IS
TYPE RealIS DIGITS 12;
TYPE Double IS DIGITS 13;
PROCEDURE q (Option : IN Character) IS
Z, Nn, Np,
Npp, Nz, Ne, Nc : Integer;
File_name : String (1..5);
I, C: Double;
U_0 : Text_IO.File_type;
BEGIN
FOR Sp IN 6..335 LOOP
IF (true) THEN
Nc := 0;
FOR N IN 1..85 LOOP
IF (true) THEN
Text_IO.New_line;
IF (Z 6)THEN
Nc := 1;
ELSE
Nc := 0;
END IF;
EXIT;
END IF;
END LOOP;
BEGIN
IF (File_name(1) = ' ') THEN
File_name(1) := '0';
END IF;
Text_IO.New_line;
IF ((Option = '1') OR (Option = '2')) THEN
BEGIN
Text_IO.Open (U_0, Text_IO.In_file, File_name .);
Text_IO.Skip_line (U_0, 3);
LOOP
BEGIN
declare
X,y : integer ;
begin
if x = y then
Np := 0;
Npp := 0;
end if;
end;
IF (Nn /= 0) THEN
IF (Np /= 0) THEN
Text_IO.New_line;
ELSE
Text_IO.New_line;
END IF;
ELSE
IF ((C - I) 0.0) THEN
NULL;
END IF;
END IF;
END;
END LOOP;
END;
Text_IO.New_Line;
END IF;
END;
END IF;
END LOOP;
END;
begin
null;
end;
Re: No effect of -fshort-enums..is it a bug
On Thursday 22 September 2005 19:31, Daniel Jacobowitz wrote: On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote: of course, but the behavior of a compiler with a special implementation dependent switch is not specified by the standard! Switches can do any amount of violence to the standard you like, the only requirement is that there be a defined set of switches which gives standard defined semantics. Except that the point I've been trying to make for the last day is that -fshort-enums does no damage to the standard. At least for C99. It's also worth noting that -fshort-enums is the default on some targets, as required by the platform ABI. Paul
Re: GCC 4.0.2 RC3
On 9/22/05, Mark Mitchell [EMAIL PROTECTED] wrote: The GCC 4.0.2 RC3 prerelease is spinning now. If all goes well, it will be available later today. whoa, I get a few regressions here, compare this with http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html ... LAST_UPDATED: Thu Sep 22 06:14:22 UTC 2005 === acats tests === FAIL: ce3810b === acats Summary === # of expected passes2319 # of unexpected failures1 Native configuration is sparc64-unknown-linux-gnu === gcc tests === Running target unix/-m64 FAIL: gcc.dg/20020201-1.c (test for excess errors) FAIL: gcc.misc-tests/linkage.c link === gcc Summary for unix/-m64 === # of expected passes34710 # of unexpected failures2 # of expected failures 95 # of untested testcases 28 # of unsupported tests 534 Running target unix FAIL: gcc.dg/20020201-1.c (test for excess errors) === gcc Summary for unix === # of expected passes34714 # of unexpected failures1 # of expected failures 95 # of untested testcases 28 # of unsupported tests 532 === gcc Summary === # of expected passes69424 # of unexpected failures3 # of expected failures 190 # of untested testcases 56 # of unsupported tests 1066 /usr/local/src/branch/objdir/gcc/xgcc version 4.0.2 === gfortran tests === Running target unix/-m64 === gfortran Summary for unix/-m64 === # of expected passes8188 # of expected failures 1 # of unsupported tests 17 Running target unix === g++ tests === Running target unix/-m64 FAIL: g++.dg/other/profile1.C (test for excess errors) FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) XPASS: g++.old-deja/g++.other/init5.C execution test FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) === g++ Summary for unix/-m64 === # of expected passes11030 # of unexpected failures3 # of unexpected successes 1 # of expected failures 68 # of unsupported tests 92 Running target unix FAIL: g++.dg/other/profile1.C (test for excess errors) FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) XPASS: g++.old-deja/g++.other/init5.C execution test FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) === g++ Summary for unix === # of expected passes11062 # of unexpected failures3 # of unexpected successes 1 # of expected failures 68 # of unsupported tests 90 === g++ Summary === # of expected passes22092 # of unexpected failures6 # of unexpected successes 2 # of expected failures 136 # of unsupported tests 182 /usr/local/src/branch/objdir/gcc/testsuite/../g++ version 4.0.2 Platform: sparc64-unknown-linux-gnu configure flags: --enable-__cxa_atexit --enable-shared --with-cpu=v7 --enable-languages=c,ada,c++,f95,java,objc,treelang -- Cheers, /ChJ
bad web link on mirrors page
FYI: On the web page: http://gcc.gnu.org/mirrors.html the link: http://strawberry.resnet.mtu.edu/pub/gcc/ fails: The requested URL /pub/gcc/ was not found on this server -- George Young -- Are the gods not just? Oh no, child. What would become of us if they were? (CSL)
Re: arguements used in .c.26.flow2 are not used in assembly codes
Liu Haibin [EMAIL PROTECTED] writes:
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include math.h
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
The begining of the .s file is
rad2deg:
addisp, sp, -16
stw fp, 8(sp)
mov r6, zero
mov fp, sp
movhi r7, %hiadj(1080459264)
addir7, r7, %lo(1080459264)
stw ra, 12(sp)
stw r16, 4(sp)
stw r17, 0(sp)
call__muldf3
mov r4, zero
movhi r5, %hiadj(1072693248)
addir5, r5, %lo(1072693248)
mov r16, r2
mov r17, r3
callatan
..
The corresponding rtl to call __muldf3 in .c.26.flow2 file is
(call_insn/u 17 16 21 0 0x0 (parallel [
(set (reg:DF 2 r2)
(call (mem:QI (symbol_ref:SI (__muldf3)) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 31 ra))
]) 44 {*call_value} (insn_list 15 (nil))
(expr_list:REG_DEAD (reg:DF 4 r4)
(expr_list:REG_DEAD (reg:DF 6 r6)
(expr_list:REG_UNUSED (reg:SI 31 ra)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)
(expr_list (use (reg:DF 6 r6))
(expr_list (use (reg:DF 4 r4))
(nil
According to the rtl, it uses r4, r5, r6 and r7 as arguements. But the
assemble codes show no r4 or r5 is ever used before call __muldf3.
Any idea why it is so?
Presumably r4 and r5 hold the value of rad which was passed into the
function. The compiler loads 180.0 into r6 and r7, and calls muldf3
to multiply rad (in r4/r5) by 180.0 (in r6/r7).
Ian
[RFC] patch to fix an ICE involving sign-extract of mmx expression
In a given test case with 128 bit mmx intrinsics, routine
make_compound_operation (in combine.c) attempts to do a sign-extract
of the middle 64bit of the 128 bit (TImode) register. Pattern we have
is:
(lshiftrt:TI (ashift:TI (subreg:TI (reg/v:V2DI 75
[ vu16YPrediction3 ]) 0) (const_int 32 [0x20]))
(const_int 64 [0x40]))
And here is the code which attempts to do this:
case LSHIFTRT:
/* ... fall through ... */
case ASHIFTRT:
lhs = XEXP (x, 0);
rhs = XEXP (x, 1);
/* If we have (ashiftrt (ashift foo C1) C2) with C2 = C1,
this is a SIGN_EXTRACT. */
=if (GET_CODE (rhs) == CONST_INT
GET_CODE (lhs) == ASHIFT
GET_CODE (XEXP (lhs, 1)) == CONST_INT
INTVAL (rhs) = INTVAL (XEXP (lhs, 1)))
{
new = make_compound_operation (XEXP (lhs, 0), next_code);
new = make_extraction (mode, new,
INTVAL (rhs) - INTVAL (XEXP (lhs, 1)),
NULL_RTX, mode_width - INTVAL (rhs),
code == LSHIFTRT, 0, in_code ==
COMPARE);
This results in gen_rtx_SUBREG asserting. We can't really do this
extraction when the extraction mode (DImode in this case) is not
properly aligned within its original mode. In other words,
gen_rtx_SUBREG attempts to generate an illegal rtl; such as:
(subreg:DI (reg/v:V2DI 75 [ vu16YPrediction3 ]) 4)
and asserts. Following patch avoids this problem. If this is OK, I
will submit a patch when fsf mainline is unfrozen.
- fariborz ([EMAIL PROTECTED])
Index: combine.c
===
RCS file: /cvs/gcc/gcc/gcc/combine.c,v
retrieving revision 1.475.2.5
diff -c -p -r1.475.2.5 combine.c
*** combine.c 26 Aug 2005 22:36:52 - 1.475.2.5
--- combine.c 22 Sep 2005 19:52:02 -
*** make_extraction (enum machine_mode mode,
*** 6197,6203
/* Avoid creating invalid subregs, for example when
simplifying (x32)255. */
! if (final_word = GET_MODE_SIZE (inner_mode))
return NULL_RTX;
new = gen_rtx_SUBREG (tmode, inner, final_word);
--- 6197,6204
/* Avoid creating invalid subregs, for example when
simplifying (x32)255. */
! if (final_word = GET_MODE_SIZE (inner_mode)
! || (final_word % GET_MODE_SIZE (tmode)) != 0)
return NULL_RTX;
new = gen_rtx_SUBREG (tmode, inner, final_word);
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Sep 22, 2005, at 4:21 PM, Fariborz Jahanian wrote: Following patch avoids this problem. If this is OK, I will submit a patch when fsf mainline is unfrozen. The FSF mainline is not frozen, only the 4.0 release branch. Thanks, Andrew Pinski
Re: On which platforms is -fvisibility supported?
On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote: Telling users to supply that flag is useless. It is the default. It's advertised as the default, but the threads I cited in my last post suggest The only time that it would matter is when the command line has on it a flag, such a -fvisibility=hidden, that alters the default. Let me elaborate. Various build systems (which have nothing to do with gcc) can alter command lines, insert build flags, alter build flags so so on. For example, Xcode inserts -fvisibility=hidden. In that environment, when that flag is passed to gcc, adding -fvisibility=default does indeed alter the behavior. In this case, the option is just negating a previous option. I think it makes more sense to tell people to turn off -fvisibility=hidden in their build system/Xcode, if that is the real issue. Give me a break! What am I trying to hide? You aren't trying to hide anything. But, what we've found is that your original question didn't contain enough details for us to help you to our satisfaction. We do really want to help you understand the issues involved. What's really going on is that you seem to have assumed I wasn't really asking what I plainly was asking. That's correct. For example, you didn't ask, does Xcode inject -fvisbility=hidden into some compilations? That answer is yes. Is that a possibly relevant detail, yes. Might it aide you in understanding the issue, I'd hope so, which is why I provide the answer. In short, at times, we feel it is better to understand your question in detail, so that we may provide you an answer. M-x grep VISIBILITY tells you the answer. What are you grepping? Why, the source code to gcc of course. This mailing list is for the developers of gcc. Gosh, now we have a hint at the real question. Now that you have a hint, tell me what it is. I'm sorry, could you repeat the question. But the example discussed there used no visibility attributes and no -fvisibility options. Prove it. Paste the command line to the compiler from the log file. Show us the .ii file, the resulting .s file and the command line flags. When you try, you will discover that something passed it, that, or during the link, someone crafted an export list that didn't include `enough' symbols. The preceding answer doesn't take into account dlopen/bundles complexities. Since no one has yet mentioned those sorts of things, I'll ignore those issues. The two A's should be the same unless requested otherwise, no? Right (given default flags/no funny environment variables, no linker export lists, no bundles, no dlopens and so on...) Do they even have a concept of not exporting the class? Not exporting is the default, isn't it? Sorry, I would not want to claim to be a Windows expert. If boost works across dll boundaries, and it isn't otherwise marked to export, then, my only guess would be that in fact it did export.
gcc-4.0-20050922 is now available
Snapshot gcc-4.0-20050922 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050922/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050922 You'll find: gcc-4.0-20050922.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050922.tar.bz2 C front end and core compiler gcc-ada-4.0-20050922.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050922.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050922.tar.bz2 C++ front end and runtime gcc-java-4.0-20050922.tar.bz2 Java front end and runtime gcc-objc-4.0-20050922.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050922.tar.bz2The GCC testsuite Diffs from 4.0-20050908 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Paul Eggert [EMAIL PROTECTED] writes: Thanks, everybody, for writing about this. The standardization process is one of consensus, and if the GCC developers find some areas of disagreement here I think it unlikely that the other POSIX implementers will agree with the proposed action. Hence I am thinking of weakening it. Currently the action proposes to insert the following text: It is implementation-defined whether trailing white-space characters in each C-language source line are ignored. Otherwise, the multibyte characters of each source line are mapped on a one-to-one basis to the C source character set. How about if I propose to insert the following text instead? The multibyte characters of each source file are mapped to the C source character set on a one-to-one basis, with the following exceptions: * It is implementation-defined whether trailing white-space characters in each input line are ignored. * Each extended source character, and each sequence of characters that would otherwise be recognized as a universal character name, is mapped to an implementation-defined extended source character or universal character name. If a universal character name is continued by a backslash-newline across a line boundary, the mapped output sequence contains the same number of backslash-newlines as the the input, but their location in the output sequence is unspecified. Would this weaker action pose an undue burden on GCC? My sense from the discussion is no, but I'd like to double-check with the experts. I think this is no problem for GCC, at least as far as UCNs go. I am less sure about the things that this is missing. For instance, it doesn't really define 'extended source character' in POSIX terms. The POSIXy way to do that would be to refer to the LC_CHARSET environment variable, but then consider LC_CHARSET=UTF-16 c99 foo.c where 'foo.c' is in UTF-16 and contains '#include stdio.h', which is in /usr/include but is in some other character set. So, there's some complication here that I'm not sure is completely solved, or at least that I don't fully understand. But, I'm pretty sure GCC would be just as hurt by that as any other compiler, so at least there are no GCC-specific problems.
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote: Telling users to supply that flag is useless. It is the default. It's advertised as the default, but the threads I cited in my last post suggest The only time that it would matter is when the command line has on it a flag, such a -fvisibility=hidden, that alters the default. Yes, I understand that's what you're saying. The evidence I cited suggested otherwise (but see below). Let me elaborate. Various build systems (which have nothing to do with gcc) can alter command lines, insert build flags, alter build flags so so on. For example, Xcode inserts -fvisibility=hidden. In that environment, when that flag is passed to gcc, adding -fvisibility=default does indeed alter the behavior. In this case, the option is just negating a previous option. I think it makes more sense to tell people to turn off -fvisibility=hidden in their build system/Xcode, if that is the real issue. I'm not interested in how Xcode handles -fvisibility; I never said I was. I'm simply interested in how g++ handles it, when invoked from the command line. Give me a break! What am I trying to hide? You aren't trying to hide anything. But, what we've found is that your original question didn't contain enough details for us to help you to our satisfaction. I only want to be helped to my satisfaction ;-) We do really want to help you understand the issues involved. If you really were trying to be helpful, and you thought a correct answer depended on my providing more information, you would have described what additional information was required. The question I'm interested in is the one I originally asked. What's really going on is that you seem to have assumed I wasn't really asking what I plainly was asking. That's correct. For example, you didn't ask, does Xcode inject -fvisbility=hidden into some compilations? And I don't care. That answer is yes. Is that a possibly relevant detail, yes. Might it aide you in understanding the issue, I'd hope so, which is why I provide the answer. In short, at times, we feel it is better to understand your question in detail, so that we may provide you an answer. M-x grep VISIBILITY tells you the answer. What are you grepping? Why, the source code to gcc of course. Let's go back a bit: Mike Stump wrote: Jonathan Turkanis wrote: So it seems a fair question to ask where -fvisibility is supported. An answer that isn't completely useless would be appreciated. M-x grep VISIBILITY tells you the answer. If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. This mailing list is for the developers of gcc. You didn't answer my question on gcc-help, either. Gosh, now we have a hint at the real question. Now that you have a hint, tell me what it is. I'm sorry, could you repeat the question. Okay, I'll rephrase it: now that you have a hint, would you please tell me what the hint is? (but you've already answered it now) But the example discussed there used no visibility attributes and no -fvisibility options. Prove it. As I said: Jonathan Turkanis wrote: I don't have time to verify the assertions made in that thread [http://article.gmane.org/gmane.comp.lib.boost.build/10072] -- the book went into production in August -- but I trust the author [Mat Marcus] and he seems to have conducted some careful experiments. Looking into it further, I've found: From Bugzilla Bug 23628: --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44 [reply] Sorry, I was a bit sloppy--I didn't remove all intermediate layers from my test environment. I will explore this further. In any case, if I explicitly invoke g++ -fvisibility=hidden t.cc ./a.out the Oops case is encountered. So part of Mat Marcus's original post was wrong. Still, there seem to be some serious issues with -fvisibility=hidden, as discussed in Bugzilla. Part of it seems to be a libstdc++ problem. Do they even have a concept of not exporting the class? Not exporting is the default, isn't it? Sorry, I would not want to claim to be a Windows expert. If boost works across dll boundaries, and it isn't otherwise marked to export, then, my only guess would be that in fact it did export. I answered your question as if you had said not exporting a class instead of not exporting the class, because you didn't seem to be refering to a particular class. I guess I should have just asked what class your were talking about. -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Ian Lance Taylor wrote: Jonathan Turkanis writes: I'm getting tired of this. You assumed I'm must have meant something else than what I plainly asked; once I mentioned that I was writing a book, you realized I really meant what I said. That's pretty much it, yes. Many years of experience have shown us by tedious example that most people ask the wrong question. Sorry you got caught, and sorry you feel insulted. Your question was easy to write, but was one that only a couple of people would know how to answer off the top of their head. If you want to get a question answered by an expert, you have to make the effort to not seem like a random newbie. I'm sorry it has to be that way, but that's the reality of the net. Thanks. Lately I've been feeling like I'm being chased by a pack of wild dogs ;-) Ian -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote: Looking into it further, I've found: From Bugzilla Bug 23628: --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44 [reply] Sorry, I was a bit sloppy--I didn't remove all intermediate layers from my test environment. I will explore this further. In any case, if I explicitly invoke g++ -fvisibility=hidden t.cc ./a.out the Oops case is encountered. Yup, as expected. I'm glad we were able to get to the bottom of this and hopefully help you understand gcc better.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
The POSIXy way to do that would be to refer to the LC_CHARSET environment variable, but then consider LC_CHARSET=UTF-16 c99 foo.c where 'foo.c' is in UTF-16 and contains '#include stdio.h', Not really a problem for a number of reasons. First, it's LC_CTYPE you're thinking of. Second, the narrow character set can only be 16-bits wide if char is 16-bits. Thirdly, if the character set that LC_CTYPE selects isn't superset of the POSIX portable character set then result is undefined. So if stdio.h happens to writen using characters only from C basic character set (which is a subset of the portable character set), there isn't a problem. Ross Ridge
Re: On which platforms is -fvisibility supported?
On 9/22/05, Jonathan Turkanis [EMAIL PROTECTED] wrote: M-x grep VISIBILITY tells you the answer. What are you grepping? Why, the source code to gcc of course. Let's go back a bit: Mike Stump wrote: Jonathan Turkanis wrote: So it seems a fair question to ask where -fvisibility is supported. An answer that isn't completely useless would be appreciated. M-x grep VISIBILITY tells you the answer. If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. I think that expecting the author of an email to the mailing list for developers of a program to have at least taken a cursory glance at the source of said program is entirely reasonable. Especially if the question regards how something in done in the source. -Hank K.
Re: On which platforms is -fvisibility supported?
Hank Kester wrote: On 9/22/05, Jonathan Turkanis wrote: M-x grep VISIBILITY tells you the answer. What are you grepping? Why, the source code to gcc of course. Let's go back a bit: Mike Stump wrote: If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. I think that expecting the author of an email to the mailing list for developers of a program to have at least taken a cursory glance at the source of said program is entirely reasonable. As I implied, this would be reasonable if the developers in question were responsive to questions on the user's list. Especially if the question regards how something in done in the source. It doesn't. -Hank K. Jonathan
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote: Looking into it further, I've found: From Bugzilla Bug 23628: --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44 [reply] Sorry, I was a bit sloppy--I didn't remove all intermediate layers from my test environment. I will explore this further. In any case, if I explicitly invoke g++ -fvisibility=hidden t.cc ./a.out the Oops case is encountered. Yup, as expected. I'm glad we were able to get to the bottom of this and hopefully help you understand gcc better. You can call it getting to the bottom of this if you want -- it's only marginally related to my original question. -- Jonathan Turkanis www.kangaroologic.com
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: On Sep 22, 2005 11:25 AM, Zdenek Dvorak [EMAIL PROTECTED] wrote: 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far be the cleanest approach -- admitedly also the one that requires the greatest amount of work. Shouldn't the regions patch allow us to preserve loops quite easily? Any pointer to this regions patch ? Thanks, - Devang
Re: On which platforms is -fvisibility supported?
Mike Stump [EMAIL PROTECTED] writes: | On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote: | Looking into it further, I've found: | | From Bugzilla Bug 23628: | --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44 | [reply] | Sorry, I was a bit sloppy--I didn't remove all intermediate layers | from my test environment. I will explore this further. In any case, | if I explicitly invoke g++ -fvisibility=hidden t.cc ./a.out the | Oops case is encountered. | | Yup, as expected. I'm glad we were able to get to the bottom of this | and hopefully help you understand gcc better. Not to be rude, but that comment is marginally helpful. -- Gaby
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
I will pull a patch together tomorrow. There is currently nothing in the code for keeping the region stuff up to date as changes are made to the cfg. For most changes this would not be hard, but for some it is really hard. Daniel Berlin wrote: On Thu, 2005-09-22 at 18:49 -0700, Devang Patel wrote: On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: On Sep 22, 2005 11:25 AM, Zdenek Dvorak [EMAIL PROTECTED] wrote: 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far be the cleanest approach -- admitedly also the one that requires the greatest amount of work. Shouldn't the regions patch allow us to preserve loops quite easily? Any pointer to this regions patch ? Thanks, Ask kenny for a copy.
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22 07:00 --- I don't know the tree-cfg bits very well, but the patch seems wrong; you are not committing the edge insertion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug fortran/24008] New: gfortran too permissive about ENTRY syntax
The following testcase should issue an error in strict F95 mode: REAL FUNCTION funct() funct = 0.0 RETURN ! ENTRY enter RESULT (answer) answer = 1.0 RETURN END FUNCTION funct The f95 standard forbids ENTRY enter RESULT (answer) because Section 12.5.2.5 syntax rule R1225 says ENTRY entry-name [([dummy-argument-list]) [RESULT(result-name)]] which would require at least ENTRY enter() RESULT (answer) The Portland and Lahey compilers indeed reject that code. -- Summary: gfortran too permissive about ENTRY syntax Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24008
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22 07:09 --- I have a patch but it only works in the -fno-trapping-math case. Given that trapping math is much more complex, that the code quality improves for -ftrapping-math, and that we are late in the development of 4.1, I'll probably punt and disable the optimization for -ftrapping-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug libstdc++/22205] [4.1 Regression] errors debug mode on aix
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:16 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug libstdc++/22222] New Tru64 UNIX libstdc++ testsuite failures: #warning debug mode disabled due to lack of weak symbol support
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:16 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:27 --- Hey Paolo. I consider this fixed for mainline. I don't want to port this to gcc-4_0-branch. First of all, this isn't a regression since debug mode was introduced in 3.4 and refined in 4.0.x, but is essentially the same. In addition, this turned out to be a messy area. Fixing this took a lot, including the header work to remove cassert and moving all those patches over to the stable branch is more movement and change than I feel comfortable with. So, permission to change to WONTFIX for gcc-4_0-branch and leave as fixed for gcc-4.1.0? -benjamin -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug tree-optimization/24001] Simple redundancy not eliminated
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-22 08:31 --- load-pre should sink the load and fix the problem at the tree level. GCSE does it at rtl level for both -O2 and -Os on i686, so maybe costs on alpha are weird enough to prevent it from doing its work at -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001
[Bug ada/23788] s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization)
--- Additional Comments From charlet at adacore dot com 2005-09-22 08:34 --- Subject: Re: s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization) This bug is also present on the 4.0 branch. This is a regression from 4.0.0 Could you double check ? I cannot see how this is possible, since the 4.0 branch hasn't been modified in this area at all. The regression is very recent and HEAD only AFAIK. The patch is fine BTW, feel free to commit it (I'll do it when I get a chance otherwise). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23788
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From pcarlini at suse dot de 2005-09-22 08:49 --- Sure! And thanks a lot for your concise and very effective fix! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug libstdc++/23956] Class __mt_alloc overexerts __policy_type::_S_get_pool
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 08:49 --- Subject: Bug 23956 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-22 08:48:33 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/ext: mt_allocator.h Log message: 2005-09-21 Guillaume Melquiond [EMAIL PROTECTED] PR libstdc++/23956 * include/ext/mt_allocator.h: Remove excess policy_type::_S_get_pool calls in constructors. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3110r2=1.3111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/mt_allocator.h.diff?cvsroot=gccr1=1.48r2=1.49 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
[Bug libstdc++/23956] Class __mt_alloc overexerts __policy_type::_S_get_pool
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:50 --- in on mainline, queued for 4.0.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:58 --- This is WONTFIX for 4.0.x, but is fixed in 4.1.x and later. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug ada/23788] s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 10:29 --- Subject: Bug 23788 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-22 10:28:17 Modified files: gcc/ada: ChangeLog s-tpinop.ads Log message: 2005-09-16 Laurent GUERBY [EMAIL PROTECTED] PR ada/23788 * s-tpinop.ads: Make this unit Preelaborate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gccr1=1.684r2=1.685 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/s-tpinop.ads.diff?cvsroot=gccr1=1.9r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23788
[Bug c++/24009] New: [4.1 regression] C++ fails to print #include stack
For the following program #define _POSIX_C_SOURCE 1 #include iostream g++ issues the following error message: /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../include/c++/4.1.0/cwchar:166: error: '::vfwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../include/c++/4.1.0/cwchar:170: error: '::vswscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../include/c++/4.1.0/cwchar:174: error: '::vwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../include/c++/4.1.0/cwchar:191: error: '::wcstof' has not been declared This bug report is _not_ about the specific error messages as such, but about the fact that g++ fails to provide the full #include stack, that is, a) the name of the file compiled, and b) the name of all the #include files involved which led to this. Contrast this with the corresponding diagnosis from GCC 3.4: In file included from /usr/include/c++/3.4/bits/postypes.h:46, from /usr/include/c++/3.4/iosfwd:50, from /usr/include/c++/3.4/ios:44, from /usr/include/c++/3.4/ostream:45, from /usr/include/c++/3.4/iostream:45, from x.cc:3: /usr/include/c++/3.4/cwchar:166: error: `::vfwscanf' has not been declared /usr/include/c++/3.4/cwchar:170: error: `::vswscanf' has not been declared /usr/include/c++/3.4/cwchar:174: error: `::vwscanf' has not been declared /usr/include/c++/3.4/cwchar:191: error: `::wcstof' has not been declared which is much more useful. -- Summary: [4.1 regression] C++ fails to print #include stack Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug libstdc++/23978] tr1::tie doesn't work with std::pair
--- Additional Comments From chris at bubblescope dot net 2005-09-22 10:49 --- Ah ha, found the problem. tuple has a copy constructor for std::pair, but not an operator=(std::pair). It should. I'll prepare a patch. While I'm at fixing this, there are quite a lot of functions (make_tuple, ref, cref, tie) that should really be marked inline, and aren't. I'll fix that at the same time. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23978
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Additional Comments From a dot darovskikh at compassplus dot ru
2005-09-22 10:54 ---
The same problem stays unresolved in GCC-3.4.4
My test is:
$ cat header1.h
$ cat header2.h
#include header1.h
$ cat test.cpp
#include header1.h
#include header2.h
main()
{
}
$g++ -x c++ -c header1.h
g++ test.cpp
In file included from test.cpp:2:
header2.h:1:21: calling fdopen: Bad file descriptor
test.cpp:4: internal compiler error: Segmentation fault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug tree-optimization/22438] [4.1 Regression] ICE SEGV in is_gimple_variable at tree-gimple.c:239
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 11:24 --- Subject: Bug 22438 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-22 11:24:01 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c Log message: PR tree-optimization/22438 * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Handle all preserved iv rhs rewriting specially. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10001r2=2.10002 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gccr1=2.88r2=2.89 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
[Bug c/24010] New: Duplicate dot initializer warning
Compiling a program like this with -Wall doesn't generate a warning, even
though the result very likely is not intended:
struct s {
int a;
};
struct s s = {
.a = 5,
.a = 6,
};
Can a duplicate initializers warning please be added? Thank you!
--
Summary: Duplicate dot initializer warning
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agruen at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug c/24010] Duplicate C99 dot initializer warning missing
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-09-22 12:50:28 date|| Summary|Duplicate dot initializer |Duplicate C99 dot |warning |initializer warning missing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From pluto at agmk dot net 2005-09-22 13:10 ---
Uros,
The mode switching patch ICEs current mainline on ix86.
gcc fbmmx.i -msse -O0,-O1 fails with different insn-errors.
[ -msse -O0 ]
fbmmx.c: In function
#8216;_cairo_pixman_composite_src_add_8000x8000mmx#8217;:
fbmmx.c:2169: error: unable to find a register to spill in class
#8216;MMX_REGS#8217;
fbmmx.c:2169: error: this is the insn:
(insn 174 172 175 7 (set (reg:V8QI 59 [ D.8903 ])
(mem/c/i:V8QI (plus:SI (reg/f:SI 20 frame)
(const_int -16 [0xfff0])) [0 __m2+0 S8 A32])) 776
{*movv8qi_internal} (nil)
(nil))
fbmmx.c:2169: internal compiler error: in spill_failure, at reload1.c:1890
[ -msse -O1 ]
fbmmx.c: In function
#8216;_cairo_pixman_composite_src_add_8000x8000mmx#8217;:
fbmmx.c:2169: error: unable to find a register to spill in class
#8216;MMX_REGS#8217;
fbmmx.c:2169: error: this is the insn:
(insn 166 165 169 9 (set (reg:V8QI 167)
(us_plus:V8QI (mem:V8QI (reg/v/f:SI 4 si [orig:120 src ] [120]) [0 S8
A64])
(mem:V8QI (reg/v/f:SI 2 cx [orig:122 dst ] [122]) [0 S8 A64])))
812 {mmx_usaddv8qi3} (nil)
(nil))
fbmmx.c:2169: internal compiler error: in spill_failure, at reload1.c:1890
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug target/23988] ICE / spill_failure, at reload1.c:1890
--- Additional Comments From pluto at agmk dot net 2005-09-22 13:15 --- You're right, the mainline is ok. This bug is related to PR19161. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23988
[Bug target/15397] [3.4 only] [g77] c float function called from fortran gives wrong result
--- Additional Comments From kmccarty at princeton dot edu 2005-09-22 14:17 --- Could anyone find out whether this g77 bug applies to other 64-bit Linux architectures as well as AMD64? I'm thinking of Alpha, Itanium, S390x, and 64-bit PowerPC and SPARC. Thanks in advance for any such information, especially on the first two of these. -- What|Removed |Added CC||kmccarty at princeton dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15397
[Bug target/24007] very weird register allocation, putting a fp in the ctr register
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 15:04 --- Subject: Bug 24007 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-22 15:03:35 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: PR target/24007 * config/rs6000/rs6000.md (movsf_hardfloat): Ignore special registers when choosing register preferences. (movdf_hardfloat): Same. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10003r2=2.10004 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gccr1=1.409r2=1.410 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24007
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:04 --- Confirmed, 4.0.0 have the same issue. To reproduce this on i686-pc-linux-gnu use cc1 directly so _GNU_SOURCE is not defined or undefine it in the source or invoke gcc as g++ t.cc -U_GNU_SOURCE the C front-end works still too. I am thinking this comes from the tokenize before parsing start parsing. -- What|Removed |Added Keywords||diagnostic Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Summary|[4.1 regression] C++ fails |[4.0/4.1 regression] C++ |to print #include stack |fails to print #include ||stack Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/24011] New: ambiguous overload reported for no obvious reason
// Barebones code to reproduce the problem:
// Interface
namespace NS
{
templatetypename T class X {};
templatetypename T XT operator*(const XT a, const XT b);
}
// Implementation
templatetypename T
NS::XToperator*(const NS::XT a,const NS::XT b)
{
return NS::XT();
}
// Application
int main(int argc, char *argv[])
{
NS::Xint tmp = NS::Xint() * NS::Xint();
}
What I get:
-bash-3.00$ uname -a
Linux elisha.research.canon.com.au 2.6.12-1.1447_FC4smp #1 SMP Fri Aug 26
20:57:13 EDT 2005 i686 i686 i386 GNU/Linux
-bash-3.00$ gcc --version
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
Copyright (C) 2005 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.
-bash-3.00$ make strange
g++ -gstrange.cpp -o strange
strange.cpp: In function 'int main(int, char**)':
strange.cpp:19: error: ambiguous overload for 'operator*' in 'NS::Xint() *
NS::Xint()'
strange.cpp:11: note: candidates are: NS::XT operator*(const NS::XT,
constNS::XT) [with T = int]
strange.cpp:6: note: NS::XT NS::operator*(const NS::XT,
const NS::XT) [with T = int]
make: *** [strange] Error 1
If I place the implementation within the scope of the namespace geometry{...}
then it seems to compile fine. However the above does not appear to cause
problems using MSVC. Problem exists with gcc 3.3.2 and 3.3.4. Is this code
incorrect???
Thanks
--
Summary: ambiguous overload reported for no obvious reason
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre_orwell at yahoo dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: redhat.x86.linux
GCC host triplet: redhat.x86.linux
GCC target triplet: redhat.x86.linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24011
[Bug libstdc++/24012] New: [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream
The following simple program fails to compile on FreeBSD 5.4: #define _POSIX_C_SOURCE 1 #include iostream g++ issues the following error message: /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:166: error: '::vfwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:170: error: '::vswscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:174: error: '::vwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:191: error: '::wcstof' has not been declared The FreeBSD 5.4 system compiler, which basically is GCC 3.4.2, has the same issue. -- Summary: [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i386-unknown-freebsd5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
[Bug c++/24011] ambiguous overload reported for no obvious reason
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:17 ---
the error message about ambiguous overload is correct as there are two
functions there.
operator* in the global namespace and operator* in the NS namespace.
You most likely wanted to implement operator* in the NS namespace and not a new
one in the global
namespace.
The following code does what you wanted to do:
// Barebones code to reproduce the problem:
// Interface
namespace NS
{
templatetypename T class X {};
templatetypename T XT operator*(const XT a, const XT b);
}
// Implementation
templatetypename T
NS::XTNS::operator*(const NS::XT a,const NS::XT b)
{
return NS::XT();
}
// Application
int main(int argc, char *argv[])
{
NS::Xint tmp = NS::Xint() * NS::Xint();
}
Notice how I wrote the Implementation.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24011
[Bug libstdc++/24012] [3.4/4.0/4.1 regression] #define _POSIX_C_SOURCE breaks #include iostream
-- What|Removed |Added Summary|[3.4,4.0,4,1 regression]|[3.4/4.0/4.1 regression] |#define _POSIX_C_SOURCE |#define _POSIX_C_SOURCE |breaks #include iostream |breaks #include iostream http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
[Bug target/24012] [3.4/4.0/4.1 regression] #define _POSIX_C_SOURCE breaks #include iostream
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:20 --- This is a target issue. The way we work around this on GNU/Linux is that we define _GNU_SOURCE all the time. -- What|Removed |Added Component|libstdc++ |target GCC host triplet|i386-unknown-freebsd5.4 | GCC target triplet||i386-unknown-freebsd5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
[Bug tree-optimization/22438] [4.1 Regression] ICE SEGV in is_gimple_variable at tree-gimple.c:239
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:25 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
[Bug libstdc++/24013] New: [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream
The following simple program fails to compile on FreeBSD 5.4: #define _POSIX_C_SOURCE 1 #include iostream g++ issues the following error message: /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:166: error: '::vfwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:170: error: '::vswscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:174: error: '::vwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:191: error: '::wcstof' has not been declared The FreeBSD 5.4 system compiler, which basically is GCC 3.4.2, has the same issue. -- Summary: [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i386-unknown-freebsd5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24013
[Bug libstdc++/24013] [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream
-- What|Removed |Added CC||rittle at latour dot rsch ||dot comm dot mot dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24013
[Bug libstdc++/24013] [3.4,4.0,4,1 regression] #define _POSIX_C_SOURCE breaks #include iostream
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:37 --- *** This bug has been marked as a duplicate of 24012 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24013
[Bug target/24012] [3.4/4.0/4.1 regression] #define _POSIX_C_SOURCE breaks #include iostream
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:37 --- *** Bug 24013 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
[Bug c++/24014] New: casting int to double with got wrong result
I've written an macro for log2 calculation to calculate the exponent of
one value.
Than I cast this value to from double to int.
The 2 values double and int differs.
example:
log2(8) should be 3 but after casting to int its 2.
This bug could be reproduced on 2 different linux distributions (Debian
GNU/Linux and Fedora Core 2) with different compiler versions.
Environment:
System: Linux lux 2.6.9 #2 Tue Dec 28 22:27:56 CET 2004 i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
How-To-Repeat:
use this code to reproduce it
--- code ---
#include math.h
#include stdlib.h
#define log2(val) (log((val))/log(2.0))
int main()
{
int n1=log2(8);
double d1=log2(8);
printf(%d %f\n,n1,d1);
return 0;
}
--- end ---
--- Additional Comments From u dot strempel at gmx dot de 2005-09-22 15:44
---
Fix:
For workaround I implemented a function for log2.
--
Summary: casting int to double with got wrong result
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: u dot strempel at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24014
[Bug c++/24014] casting int to double with got wrong result
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:48 --- This is really not a bug. This is a dup of 323. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24014
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 15:48 --- *** Bug 24014 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||u dot strempel at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/24012] [3.4/4.0/4.1 regression] #define _POSIX_C_SOURCE breaks #include iostream
-- What|Removed |Added CC||rittle at latour dot waar ||dot labs dot mot dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
[Bug rtl-optimization/23043] [4.1 regression] [m68k-linux] bootstrap error on m68k-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 15:58 --- Subject: Bug 23043 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-22 15:57:49 Modified files: gcc: ChangeLog postreload-gcse.c Log message: PR rtl-optimization/23043 * postreload-gcse.c (eliminate_partially_redundant_load): Fix typo when allocating a struct unoccr. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.433r2=2.7592.2.434 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/postreload-gcse.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.9r2=2.9.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23043
[Bug rtl-optimization/23043] [4.1 regression] [m68k-linux] bootstrap error on m68k-linux
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-22 16:06 --- I applied this patch to the 4.0 branch. -- What|Removed |Added Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23043
[Bug c/24015] New: Wrong code generated when using optimizer
gcc produces wrong code when optimizer (O1 O2 or O3) is used. The c-source showing the problem is generated by the flex lexical scanner. Applies to gcc versions 3.0.4, 3.3.5 and 3.4.4 (and maybe others not tested). Tested on Debian/Intel platforms only. On gcc 2.95 and multiple former versions of gcc, the problem does not occur. -- Summary: Wrong code generated when using optimizer Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: buergel at limmat dot ch CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
-- What|Removed |Added Severity|critical|normal Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 16:26 --- Of course, we cannot guess what the issue is from your description. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From buergel at limmat dot ch 2005-09-22 16:28 --- Created an attachment (id=9792) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9792action=view) Testcase. Unpack and make reproduces the bug Testcase requires flex (= 2.5.4) lexical scanner to be installed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug c++/21983] [3.4/4.0/4.1 Regression] multiple diagnostics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22 16:35 --- Subject: Bug 21983 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-22 16:34:59 Modified files: gcc/cp : ChangeLog class.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: pr21983.C Log message: PR c++/21983 * class.c (find_final_overrider): Move diagnostic about no unique final overrider to... (update_vtable_entry_for_fn): ... here. * g++.dg/warn/pr21983.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4900r2=1.4901 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gccr1=1.732r2=1.733 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6095r2=1.6096 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/pr21983.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21983
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From buergel at limmat dot ch 2005-09-22 16:39 --- How-To-Repeat: Unpack the attached archive, cd showbug, make. It will first compile the program, then process and display some test data. Prerequisites: You must have the flex lexical parser installed for this to work Expected behavior: Some HTML code shows up like HTML lang=it BODY ... Actual behavior: The HTML appears crippled, the first character of many tags is missing, e.g. HTML ang=it BODY ... Fix: No fix is known to me, workaround is -O0 or using gcc 2.95 -- What|Removed |Added Known to fail||3.0.4 3.3.5 3.4.4 Known to work||2.95 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 16:40 --- html_purify.l:24: warning: operation on `data' may be undefined -- What|Removed |Added Known to fail|3.0.4 3.3.5 3.4.4 | Known to work|2.95| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
16:43 ---
(In reply to comment #4)
html_purify.l:24: warning: operation on `data' may be undefined
Does fixing that line help?
It should look like:
static void strtolower(char *data) { while (*data != '\0') { *data =
tolower(*data); data++;} }
--
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 17:04 --- From the private email: Hello and thanks for the quick answer! Yes it does! But: I am not getting the warning: operation on `data' may be undefined when using gcc 3.4.4 and -Wall. So how could I (and someone else) find this type of error? Regards Friede PS: Wow! Never received an answer that fast! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug middle-end/24015] Wrong code generated when using optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
17:06 ---
(In reply to comment #6)
Hello and thanks for the quick answer! Yes it does! But: I am not getting the
warning: operation on `data' may be undefined
when using gcc 3.4.4 and -Wall.
Try at -O0, glibc changes tolower to a macro which causes issues with the
warning, I will file another
bug about that soon.
The short testcase for your issue would be:
#include ctype.h
void strtolower(char *data) { while (*data != '\0') *data++ = tolower(*data); }
*** This bug has been marked as a duplicate of 11751 ***
--
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
[Bug c/11751] wrong evaluation order of an expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22 17:07 --- *** Bug 24015 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||buergel at limmat dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
