Re: New LTO branch ready

Daniel Berlin wrote: > Hi guys, I have merged all patches touching lto/ into the new lto branch Thank you! Did you also pull over Kenny's LTO-writer code? I'll try to get it compiling soon. > I will perform merges from mainline to branch every week or two, > unless you guys see a good reason n

Re: RFC: Make dllimport/dllexport imply default visibility

Chris Lattner wrote: >>> That is a limited view of things based on the current implementation of >>> GCC. When future developments (e.g. LTO) occur, this will change: types >>> certainly do live in object files. >> >> I don't see how LTO changes this. Yes, type definitions will appear in >> one o

Re: Activate -mrecip with -ffast-math?

On 6/19/07, tbp <[EMAIL PROTECTED]> wrote: Indeed there are holes in every direction when you pull in such transformation, and the cost of plugging every one of them would be prohibitive; the next batch of c2d supposedly will leave you with ~6 cycles to make it worth for a sqrt. My C2D has 6 c

Re: RFC: Make dllimport/dllexport imply default visibility

That is a limited view of things based on the current implementation of GCC. When future developments (e.g. LTO) occur, this will change: types certainly do live in object files. I don't see how LTO changes this. Yes, type definitions will appear in one or more object files. But, the i

Re: Activate -mrecip with -ffast-math?

Bradley Lucier wrote: > If -ffinite-math-only is specified, then producing NaN instead of inf > should be allowed. Agreed. After all, -finite-math says: Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. Since the compiler

Re: Object attribute tagging

On Tue, Jun 19, 2007 at 01:50:27AM +, Joseph S. Myers wrote: > The question was raised a while back on the gcc-patches and gdb-patches > lists of how GCC should tag objects with some ABI information for the use > of GDB, noting that various different methods have been in use >

Re: I'm sorry, but this is unacceptable (union members and ctors)

Daniel Jacobowitz-2 wrote: > > On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote: >> Yeah, I know (mailing lists are so particular -- I guess I fail to see >> the >> value beyond a noncentralized discussion) > > But since I believe three different people have asked you to move this > p

Object attribute tagging

The question was raised a while back on the gcc-patches and gdb-patches lists of how GCC should tag objects with some ABI information for the use of GDB, noting that various different methods have been in use . Mark suggested

Re: I'm sorry, but this is unacceptable (union members and ctors)

On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote: > Yeah, I know (mailing lists are so particular -- I guess I fail to see the > value beyond a noncentralized discussion) But since I believe three different people have asked you to move this problem to a different mailing list now, could

virtual stack regs.

I would like to get some more information about pr32374. I do not know what virtual_stack_vars are and there is no documentation in the doc directory. 1) What are these? 2) Why are they uninitialized? 3) If they really are uninitialized, why is it a problem to assign zero to them. 4) If they a

Re: Activate -mrecip with -ffast-math?

On 6/18/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: IMO, due to limited range of operands for -mrecip pass (inf, -inf); where 0.0 is excluded, it should be keept out of -ffast-math. There is no point to fix reciprocals only for 0.0, we need to fix both conversions for infinity and 0.0, even in -f

Re: I'm sorry, but this is unacceptable (union members and ctors)

Brian Dessent wrote: > > "michael.a" wrote: > >> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > This belongs on gcc-help not here. > > Debian-based distros use a 32/64 bit /usr/lib configuration that is > backwards from what the rest of the world uses and requires a patched > gcc to multilib

Re: I'm sorry, but this is unacceptable (union members and ctors)

"michael.a" wrote: > gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) This belongs on gcc-help not here. Debian-based distros use a 32/64 bit /usr/lib configuration that is backwards from what the rest of the world uses and requires a patched gcc to multilib correctly. You'll probably need to --disabl

Re: I'm sorry, but this is unacceptable (union members and ctors)

Eric Christopher-2 wrote: > > > 'gcc -v' will give you the information on how the system gcc was > configured. > > -eric > > Here is the gcc -v output for the binaries installed by the distro: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-l

RE: I'm sorry, but this is unacceptable (union members and ctors)

On 18 June 2007 23:46, michael.a wrote: > Eric Christopher-2 wrote: >> >> >> You might want to make sure you're passing the same configure options >> that the distro did when building. It might cause some incompatibility >> somewhere that ld is detecting. From a quick look it seems that ld >> be

Re: Some thoughts about steerring commitee work

Joel Sherrill wrote: > Note that on the steering committee we represent technical areas > NOT the companies we work for at any given time. I'd like to emphasize that this is not only true in theory but in practice. It is true that, perhaps, when someone from company X is proposed for a maintaine

Re: I'm sorry, but this is unacceptable (union members and ctors)

I'm sure plenty will look down their nose at me for asking in this forum(mailing list) ...but I recall a tool for checking libraries and build options (libtool libraries only maybe) ...I can't recall how or where, or think what to feed google (The architecture I'm building on is amd64 if th

Re: I'm sorry, but this is unacceptable (union members and ctors)

Eric Christopher-2 wrote: > > > You might want to make sure you're passing the same configure options > that the distro did when building. It might cause some incompatibility > somewhere that ld is detecting. From a quick look it seems that ld > believes that the libc that you have doesn

gcc-4.1-20070618 is now available

Snapshot gcc-4.1-20070618 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070618/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: I'm sorry, but this is unacceptable (union members and ctors)

Thank you, I guess I missed that page somehow. Only I ran into the same Libc wall again, so I'm temporarily stumped: /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for -lc /usr/bin/

Re: I'm sorry, but this is unacceptable (union members and ctors)

Eric Christopher-2 wrote: > > > Sounds like you're using ./configure. Are you following the directions > at: > > http://gcc.gnu.org/install/configure.html > > -eric > > Thank you, I guess I missed that page somehow. Only I ran into the same Libc wall again, so I'm temporarily stumped:

RE: Fixed-point branch?

Bernd Schmidt wrote: > >>> +ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */ > >>> +ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */ > >>> +ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */ > >>> +ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */ > >> Lots of predefined types and modes in this patch. What > about targets > >> with

Re: I'm sorry, but this is unacceptable (union members and ctors)

On Jun 18, 2007, at 2:36 PM, michael.a wrote: This suggestion made some ground. But I just can't get a build to complete. The newest checkout / release aren't compatible with my C libraries it seems, and I'm not sure its safe dependency wise to just replace the C libraries. So I rewound my su

Re: Suffix for __float128 FP constants

On Mon, Jun 18, 2007 at 02:33:07PM -0700, Steve Ellcey wrote: > > We need a standard for __float128. Otherwise, a program using > > __float128 may generate different results with different > > compilers on different platforms. > > > > BTW, I had a __float128 patch for glibc. Because there is no >

Re: I'm sorry, but this is unacceptable (union members and ctors)

If all you need is one memeber that has constructors / destructors, and all other members are PODs that provide an alternate view of the contents, then I think that would make a logical extension of the transparent union extension. A transparent union as passed to functions in the same manner a

Re: Suffix for __float128 FP constants

> We need a standard for __float128. Otherwise, a program using > __float128 may generate different results with different > compilers on different platforms. > > BTW, I had a __float128 patch for glibc. Because there is no > __float128 standard, it wasn't accepted. > > > H.J. The HP compiler h

Re: Fixed-point branch?

Fu, Chao-Ying wrote: +ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */ +ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */ +ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */ +ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */ Lots of predefined types and modes in this patch. What about targets with other requirements (the Blackfin h

Re: Suffix for __float128 FP constants

On Mon, Jun 18, 2007 at 11:10:43AM -0700, Steve Ellcey wrote: > > BTW: IA64 has the same issues with two FP types (long double XFmode and > > "longer double" TFmode). How is this solved for IA64? > > > > Uros. > > This is different on IA64 HP-UX and IA64 Linux. On HP-UX, 128 bits is > the stand

Re: Incorrect bitfield aliasing with Tree SSA

> > I continue to strongly feel that the field type shouldn't be used > > for ANYTHING! > > Then you will continue to get worse code generation than you could, in > addition to bugs like we have now. Explain to me why in the following case: struct s1 {int a;}; struct s2 {short a;

Re: Incorrect bitfield aliasing with Tree SSA

> > struct foo {int a: 32; int b: 32; }; > > struct bar {int c: 32; int d: 32; }; > > > > you have the fields A and C conflicting, which is wrong. > > With the current scheme you have fields a and b conflict > and c and d conflicting > > Both of which are wrong But nothing is cha

The Linux binutils 2.17.50.0.17 is released

This is the beta release of binutils 2.17.50.0.17 for Linux, which is based on binutils 2007 0615 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > > you have the fields A and C conflicting, which is wrong. > > Well, that is where structure-field aliasing comes in. The two cannot > even alias for addressable fields: At tree level I'll take your word for it, but what about RTL level? I

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > Type of the expression passed to get_alias_set. And without the > component_uses_parent_alias_set loop. So you mean the type of the *field*? That can't work. That type can't be used for *anything*! Otherwise, if you have struct

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > They are the alias set mechanism, which you don't seem to understand. > They always have been. I certainly understand the alias set mechanism. It sounded like you were talking about something else since if the only thing we're using is ali

Re: Incorrect bitfield aliasing with Tree SSA

> > you have the fields A and C conflicting, which is wrong. > > Well, that is where structure-field aliasing comes in. The two cannot > even alias for addressable fields: At tree level I'll take your word for it, but what about RTL level? Is that nonconflicting status passed to RTL? What *is*

Re: Incorrect bitfield aliasing with Tree SSA

Richard Kenner writes: > Otherwise, if you have > > struct foo {int a: 32; int b: 32; }; > struct bar {int c: 32; int d: 32; }; > > you have the fields A and C conflicting, which is wrong. Well, that is where structure-field aliasing comes in. The two cannot even alias for addressab

Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h

Forwarding to gcc@, as this might be interesting to other people, and I'd like to ask whoever working on ia64 to take this issue up. Seongbae -- Forwarded message -- From: Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]> Date: Jun 18, 2007 12:44 AM Subject: INCOMING_RETURN_ADDR_RTX i

RE: Some thoughts about steerring commitee work

Hi Dorit, >loop-context when it helps you do things more efficiently. In any case, >we'll have to have a much better cost model before we start packing random >sequences of stmts out of loops. This is off topic from the discussion at hand, but we would be happy to help with changing the cost mode

Re: Incorrect bitfield aliasing with Tree SSA

> They are the alias set mechanism, which you don't seem to understand. > They always have been. I certainly understand the alias set mechanism. It sounded like you were talking about something else since if the only thing we're using is alias sets, I'm mystified as to what the issue is. > I'd r

Re: GCC Status Report (2007-06-15)

H. J. Lu wrote: > Good. I have another question. Intel BID patch itself doesn't change > any sources in DFP nor libdecnummber. The only significant change is > to change Makefile in libgcc to use Intel BID library for DFP > intrinsics when BID encoding is selected. Currently, DFP is only > suppor

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > It gives you the alias set of the parent, which, for the reason that > OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer. Can you give a few sentence explanation of what "alias set splay trees" are and why they aren't using

Re: Incorrect bitfield aliasing with Tree SSA

> Type of the expression passed to get_alias_set. And without the > component_uses_parent_alias_set loop. So you mean the type of the *field*? That can't work. That type can't be used for *anything*! Otherwise, if you have struct foo {int a: 32; int b: 32; }; struct bar {int c

Re: Incorrect bitfield aliasing with Tree SSA

Richard Kenner writes: > > I am glad to see we are converging toward implementation issues now! > > > > I am storing it in a new field under the alias_set_entry: > > > > get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set. > > Where T is which type? Type of the expression passed to g

Re: Incorrect bitfield aliasing with Tree SSA

> It gives you the alias set of the parent, which, for the reason that > OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer. Can you give a few sentence explanation of what "alias set splay trees" are and why they aren't using the alias set mechanism? > > I'm not sure what a "TBAA

Re: Incorrect bitfield aliasing with Tree SSA

> I am glad to see we are converging toward implementation issues now! > > I am storing it in a new field under the alias_set_entry: > > get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set. Where T is which type?

Re: Activate -mrecip with -ffast-math?

On Jun 18, 2007, at 2:27 PM, Bradley Lucier wrote: But even if sqrt is corrected for 0.0 * inf, there would still be a lot of problems with the combinations of NR-enhanced rsqrt and rcp. Consider for example: 1.0/sqrt(a/b) alias rsqrt(a/b) Having a=0, b != 0, the result is inf. As alrea

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > How does this get a different result for trees than RTL? > > As i've explained, we rely on the proper of the TBAA forest that given > > struct foo (set 1) > / \ > int :31 (set 2) short :31 (set 3) > > se

Re: Incorrect bitfield aliasing with Tree SSA

Richard Kenner writes: > But there's also an implementation issue: where do you propose to *store* > this fake alias set? There is no such field as DECL_ALIAS_SET. I am glad to see we are converging toward implementation issues now! I am storing it in a new field under the alias_set_entry: ge

Re: Incorrect bitfield aliasing with Tree SSA

> How does this get a different result for trees than RTL? > > As i've explained, we rely on the proper of the TBAA forest that given > > struct foo (set 1) > / \ > int :31 (set 2) short :31 (set 3) > > sets for int :31 and short :31 are strict subsets of th

Re: Activate -mrecip with -ffast-math?

On Jun 18, 2007, at 2:14 PM, Uros Bizjak wrote: tbp wrote: For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first get an inf from said reciprocal which then turns to a NaN in the NR stage but if you correct it by, say, doing a comparison to 0 and a 'and'. That's what ICC us

Re: Activate -mrecip with -ffast-math?

Giovanni Bajo wrote: Both our goals are legitimate. But that's not the point. The point is what -ffast-math semantically means (the simplistic list of suboptions activated by it is of couse unsufficiente because it doesn't explain how to behave in face of new options, like -mrecip). My proposal

RE: Fixed-point branch?

Bernd Schmidt wrote: > > I attached a diff file for 14 files of the new structures > > and documents. You and other maintainers are welcome to > > check it. Thanks a lot! > > > > Note: 14 files are => > > genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h > > tree.c rtl.def r

Re: Activate -mrecip with -ffast-math?

tbp wrote: For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first get an inf from said reciprocal which then turns to a NaN in the NR stage but if you correct it by, say, doing a comparison to 0 and a 'and'. That's what ICC used to do in your back. That's what you'll find page 15

Re: Suffix for __float128 FP constants

> BTW: IA64 has the same issues with two FP types (long double XFmode and > "longer double" TFmode). How is this solved for IA64? > > Uros. This is different on IA64 HP-UX and IA64 Linux. On HP-UX, 128 bits is the standard long double and 80 bits is __float80. We use the 'W' suffix for a __flo

New LTO branch ready

Hi guys, I have merged all patches touching lto/ into the new lto branch I'm almost 100% positive the result will not compile. There are no interesting conflicts to report (most were just formatting changes). I have not merged ChangeLog.lto onto the new branch, since it looked like it only conta

Re: Suffix for __float128 FP constants

On Mon, Jun 18, 2007 at 07:25:06PM +0200, Uros Bizjak wrote: > H. J. Lu wrote: > > >>>I was trying to load a full 128 bit constant into __float128 variable, > >>>but > >>>with "L" suffix, I was able to load only XFmode constant. Is there a > >>>special > >>>suffix for __float128 available in gcc

Re: Some thoughts about steerring commitee work

On 6/18/07, Sebastian Pop <[EMAIL PROTECTED]> wrote: On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: > > I can hand you more than the testcases i've given so far. There is > > tons of code out there that would benefit from straight line > > Interesting. I wasn't aware of this potential. Ple

Re: Some thoughts about steerring commitee work

On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: > I can hand you more than the testcases i've given so far. There is > tons of code out there that would benefit from straight line Interesting. I wasn't aware of this potential. Please do send some of this code. thanks! I'm thinking about

Re: Suffix for __float128 FP constants

H. J. Lu wrote: I was trying to load a full 128 bit constant into __float128 variable, but with "L" suffix, I was able to load only XFmode constant. Is there a special suffix for __float128 available in gcc? No; since the x86-64 ABI is what defines the __float128 name, you could ask the

Re: Suffix for __float128 FP constants

On Sun, Jun 17, 2007 at 09:06:36PM +, Joseph S. Myers wrote: > On Sun, 17 Jun 2007, Uros Bizjak wrote: > > > I was trying to load a full 128 bit constant into __float128 variable, but > > with "L" suffix, I was able to load only XFmode constant. Is there a special > > suffix for __float128 ava

Re: RFC: Make dllimport/dllexport imply default visibility

Chris Lattner wrote: [Richard E., please see below for a question re. RealView's behavior.] >> You and Chris are taking the view that "the type" has a location. But, >> a lot of people don't look at it this way. The things that have >> locations are variables (including class data) and function

Re: Some thoughts about steerring commitee work

I can hand you more than the testcases i've given so far. There is tons of code out there that would benefit from straight line vectorization. I'm interested in these test cases. Thanks! In fact, we have some that gets written in loop form right now just so it gets vectorized! May be loop

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > > But throws away the entire DECL_NONADDRESSABLE_P mechanism! > > No, an int* will still not conflict with int:31 > a short * will still not conflict with short:31 Using what mechanism? That's what DECL_NONADDRESSABLE_P does! Please read

Re: I'm sorry, but this is unacceptable (union members and ctors)

Robert Dewar writes: > Ross Ridge wrote: > t formal definition. > > > Most of GCC's long list of extensions to C are also implemented as > > extensions to C++, so you've already lost this battle in GNU C++. > > And many of them are ill-defined (and some would agree ill-considered). > Mist

Requesting SVN write access (Was: [PATCH frv] Fix PR ...)

On Mon, Jun 18, 2007 at 01:18:48PM +0200, Paolo Bonzini wrote: > Rask Ingemann Lambertsen wrote: > > This patch makes the frv build again after the dataflow merge. Ok? > >(I don't have access to check in patches myself.) > > Yes, ok. Please request write after approval access. I'm likely go

Re: Incorrect bitfield aliasing with Tree SSA

> > But throws away the entire DECL_NONADDRESSABLE_P mechanism! > > No, an int* will still not conflict with int:31 > a short * will still not conflict with short:31 Using what mechanism? That's what DECL_NONADDRESSABLE_P does! > Tell me what TYPE_NONALIASED_COMPONENT does, and i'll tell you wh

Re: I'm sorry, but this is unacceptable (union members and ctors)

On 6/16/07, michael.a <[EMAIL PROTECTED]> wrote: You are of course free to demonstrate how placement new could circumnavigate the need of unions. Boost.Variant implements discriminated unions using placement new: http://www.boost.org/doc/html/variant.html Of course, you would have to mimic t

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > His first patch, which simply makes #1 true, would cause missed optimization. It doesn't "cause missed optimizations": it completely removes all the functionality of DECL_NONADDRESSABLE_P! Hence the reason for the second suggestion.

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > Again, the tree level relies on the documented (in the comments of > alias.c) fact that given a structure, the fields contained in a > structure will have alias sets that are strict subsets of the parent. That is ONLY true for fields that d

Re: Incorrect bitfield aliasing with Tree SSA

> His first patch, which simply makes #1 true, would cause missed optimization. It doesn't "cause missed optimizations": it completely removes all the functionality of DECL_NONADDRESSABLE_P!

Re: Incorrect bitfield aliasing with Tree SSA

> Again, the tree level relies on the documented (in the comments of > alias.c) fact that given a structure, the fields contained in a > structure will have alias sets that are strict subsets of the parent. That is ONLY true for fields that don't have DECL_NONADDRESSABLE_P and that's been the case

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > Uh, except as we've discovered, the RTL uses alias set 0, so whatever > alias set you choose for these doesn't matter anyway to the RTL level. Only in some cases. That was a kludge put in to fix some obscure bug and left there. I hope we c

Re: Incorrect bitfield aliasing with Tree SSA

> Uh, except as we've discovered, the RTL uses alias set 0, so whatever > alias set you choose for these doesn't matter anyway to the RTL level. Only in some cases. That was a kludge put in to fix some obscure bug and left there. I hope we can remove it at some point, and think we can. > No i me

Re: I'm sorry, but this is unacceptable (union members and ctors)

michael.a: > A proper C++ style fix would require the introduction of new syntax rather > than tagging unions or such. The dominant ctors would have to be specified, > or unions themselves could simply be allowed ctors that override the member > ctors. Call them constructor overloads or something,

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > If it was designed properly in the first place, there simply would *be > > no problem at the tree level*, because nothing would have broken. > > That's certainly a point of view. The oth

Re: missing symbols

On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: > In the following code, compiled with > g++ cls.cc -Wall -W -g3 -o cls > > why only only virtual functions f1, f2 and constructor is listed by nm. Because they are needed for the vtable. While f

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > If it was designed properly in the first place, there simply would *be > no problem at the tree level*, because nothing would have broken. That's certainly a point of view. The other is that the RTL implementation predates the Tree one, wor

Re: missing symbols

On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: In the following code, compiled with g++ cls.cc -Wall -W -g3 -o cls why only only virtual functions f1, f2 and constructor is listed by nm. Only debugging symbols for virtual functions are included in executable output file ? //cls.cc #include

missing symbols

In the following code, compiled with g++ cls.cc -Wall -W -g3 -o cls why only only virtual functions f1, f2 and constructor is listed by nm. Only debugging symbols for virtual functions are included in executable output file ? //cls.cc #include using namespace std; class test { public: i

Re: Incorrect bitfield aliasing with Tree SSA

> If it was designed properly in the first place, there simply would *be > no problem at the tree level*, because nothing would have broken. It's possible to have bugs anytime and that's all we have here: somebody is using the wrong alias set someplace. We fix that and all is OK. > So far you gu

Re: I'm sorry, but this is unacceptable (union members and ctors)

On 6/17/07, michael.a <[EMAIL PROTECTED]> wrote: I appreciate the thought, but there is sort of an imperitive with this effort to shy away from Boost/STL/virtual inheritance completely. You'd be hard-pressed to find any instance of dynamic polymorphism anywhere in Boost. Most of Boost is based

gcov / gcov-dump

I'm writing a tool which reads information (arcs) from the .gcno file produced by GCC with -ftest-coverage. It calculates the NPATH complexity (number of execution paths in a function) By doing this I found out the graph generated by GCC contains more paths then I expected. For every function

Re: More vectorizer testcases?

Giovanni Bajo <[EMAIL PROTECTED]> wrote on 18/06/2007 15:06:48: > On 6/18/2007 1:26 PM, Dorit Nuzman wrote: > > > these 3 are actually not so simple... the main thing that's blocking 2 of > > them right now is that they need support for stores with gaps, which can be > > added except the other pro

Re: Incorrect bitfield aliasing with Tree SSA

> That is not the example case we have given where this breaks. > The case where it breaks is exactly the case i have shown you. > > We have a pointer to a structure, and because you have not recorded > the type's alias relationships properly, we claim derferences that are > offsetted from the str

Re: Incorrect bitfield aliasing with Tree SSA

> If it was designed properly in the first place, there simply would *be > no problem at the tree level*, because nothing would have broken. That's certainly a point of view. The other is that the RTL implementation predates the Tree one, works fine in GCC 3.x, including for the C compiler. One

Re: Some thoughts about steerring commitee work

> > > However, as far as I know (also from talking with the > > SLP authors) pretty much all the opportunities they had found at the time > > were in loops. > > I can hand you more than the testcases i've given so far. There is > tons of code out there that would benefit from straight line Inter

Re: Activate -mrecip with -ffast-math?

On 6/18/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: I understand your problems, but let me state that your objections are totally subjective. *You* need a specific behaviour from -ffast-math (eg: keep NaN/Inf), but that's not what *I* need. So, we have different goals. No. My NaN are my problem

Re: More vectorizer testcases?

On 6/18/2007 1:26 PM, Dorit Nuzman wrote: these 3 are actually not so simple... the main thing that's blocking 2 of them right now is that they need support for stores with gaps, which can be added except the other problem is that the vectorizer thinks it's not profitable to vectorize them (or r

Re: Activate -mrecip with -ffast-math?

On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote: No, that's not the contract with -ffast-math. Note that -ffast-math enables -funsafe-math-optimizations which is allowed to change results (add/remove rounding operations, contract expressions, do transforms like a/b to a * 1/b, do transfor

Re: Activate -mrecip with -ffast-math?

On 6/18/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: On 6/18/07, tbp <[EMAIL PROTECTED]> wrote: > Until now, the contract was: you have to deal with (and contain) NaN > and infinities. Fair enough, even if tricky that remained manageable. > But if i can't expect a mere division by 0, or sqrt of 0

Re: Some thoughts about steerring commitee work

On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19: ... > > The whole purpose of SLP was to enable straight line code > vectorization outside of loops. I wouldn't say that's the whole purpose of SLP. Okay, that is probably a st

Re: Activate -mrecip with -ffast-math?

On 6/18/2007 12:16 PM, tbp wrote: Of course there are cases with every optimization enabled by -ffast-math that can break existing programs. Just that we know of one case beforehand shouldn't prevent us from enabling -mrecip at -ffast-math (provided -mno-recip still works, regardless if provi

Re: Activate -mrecip with -ffast-math?

On 6/18/07, tbp <[EMAIL PROTECTED]> wrote: Until now, the contract was: you have to deal with (and contain) NaN and infinities. Fair enough, even if tricky that remained manageable. But if i can't expect a mere division by 0, or sqrt of 0 (quite common with FTZ/DAZ on) to give me respectively an

Re: Incorrect bitfield aliasing with Tree SSA

On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > I'm completely unsurprised this is broken at the tree level given how > it is implemented Nice tautology. :-) You have resisted implementing anything at the tree level to fix the problem and now you're complaining there is a problem... Pa

Re: More vectorizer testcases?

Giovanni Bajo <[EMAIL PROTECTED]> wrote on 17/06/2007 20:43:15: > Hi Dorit, > > some years ago I posted these testcases to Bugzilla's GCC: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439 > >

Re: Fixed-point branch?

Fu, Chao-Ying wrote: > I attached a diff file for 14 files of the new structures > and documents. You and other maintainers are welcome to > check it. Thanks a lot! > > Note: 14 files are => > genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h > tree.c rtl.def rtl.h rtl.c fixe

[M16C] : 20 bit data access

Hi, We have come up with two possible solutions to solve the 20 bit data access problem in m16c targets. We are very grateful for all the suggestions until now on this issue. Solution 1 is based on the discussion at the following link -: http://gcc.gnu.org/ml/gcc/2007-04/msg00402.html - 2 new at

Re: Activate -mrecip with -ffast-math?

On 6/18/07, tbp <[EMAIL PROTECTED]> wrote: On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > Of course there are cases with every optimization enabled by -ffast-math that > can break existing programs. Just that we know of one case beforehand shouldn't > prevent us from enabling -mrecip

Re: missed vectorization (was Some thoughts about steerring commitee work)

Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 19:47:10: > [EMAIL PROTECTED] wrote: > > Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56: > > > >> [EMAIL PROTECTED] wrote: > >>> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote: > > There are quite a few known simple

Re: Some thoughts about steerring commitee work

"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19: ... > > The whole purpose of SLP was to enable straight line code > vectorization outside of loops. I wouldn't say that's the whole purpose of SLP. I think the purpose and beauty of SLP is that it's a simple algorithm that makes ve

  1   2   >