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: [RFC] propagating loop dependences from trees to RTL (for SMS)
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? Gr. Steven
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
#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] . . . 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
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
> 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: warning about classpath import
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. It would also address some bugs (including regressions like #23499, which is not high priority, though), wouldn't it? Gerald
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
> 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 and PR 23993
> I have. I am awaiting solaris test details. Not very good: 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: 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: GCC 4.0.2 and PR 23993
> > I have. I am awaiting solaris test details. > > Not very good: 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 Yes, I saw this with Joe Buck's results yesterday. Further details have not been available. These new fails are annoying, but not release-critical, and seem to be confined to Solaris. I'm not quite sure what is going on: can you send me your libstdc++ log file please? -benjamin
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
> #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 (x>>32)&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 (x>>32)&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 ', 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 ', 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 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: [RFC] propagating loop dependences from trees to RTL (for SMS)
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.
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.
