Re: strict aliasing question

[Howard Chu]

Dave Korn wrote:

On 12 November 2006 04:16, Howard Chu wrote:

  

Dave Korn wrote:


f = (struct foo *)(void *)buf;



That's good, but why is it safe?




  Passing through void* means gcc has to assume it could alias anything,
IIUIC, as a result of the standard allowing implicit void*<=>T* conversions.

  

Ah right, 6.5.16.1 Simple assignment, Constraints...

   one operand is a pointer to an object or incomplete type  and the 
other is a pointer to a qualified or unqualified version of void, and 
the type pointed to by the left has all the qualifiers of the type 
pointed to by the right;


So actually
   f = (void *)buf;
works without complaint.

Thanks for pointing that out.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sunhttp://highlandsun.com/hyc
 OpenLDAP Core Teamhttp://www.openldap.org/project/

Re: strict aliasing question

[Andreas Schwab]

Howard Chu <[EMAIL PROTECTED]> writes:

> As I recall, we chose int[] for alignment reasons, figuring we'd have no
> guarantees on the alignment of a char[].

Neither you have on int[].

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bootstrap failure on HEAD

[Dave Korn]

  I see this on linux but not on cygwin:

make[3]: Leaving directory `/home/dk/gnu/obj'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
./cfg.o differs
./cfgloopanal.o differs
./loop-iv.o differs
./predict.o differs
./profile.o differs
./value-prof.o differs
./ipa-inline.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/dk/gnu/obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/dk/gnu/obj'
make: *** [all] Error 2
[EMAIL PROTECTED] obj]$ ../gcc/config.guess 
i686-pc-linux-gnu
[EMAIL PROTECTED] obj]$ uname -a
Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686
i386 GNU/Linux
[EMAIL PROTECTED] obj]$ 


  Is it just me, or does anyone else get this?  I objdump'd and diff'd the
stage2 and stage3 versions of cfg.o and it seems to have developed a habit of
inserting 'shrd'/'shld' opcodes:

@@ -8895,8 +8896,10 @@  :
 :  11 4c 24 34 %ecx,0x34(%esp,1)
 :  8b 5c 24 34 mov0x34(%esp,1),%ebx
 :  8b 4c 24 30 mov0x30(%esp,1),%ecx
-:  c1 e0 10shl$0x10,%eax
 :  8b 54 24 44 mov0x44(%esp,1),%edx
+:  0f ac d9 01 shrd   $0x1,%ebx,%ecx
+:  0f a4 c2 10 shld   $0x10,%eax,%edx
+:  c1 e0 10shl$0x10,%eax
 :  d1 fb   sar%ebx
 :  01 c8   %ecx,%eax
 :  11 da   %ebx,%edx


  although disturbingly enough there's a missing 'lea' too:


@@ -8968,29 +8971,29 @@  :
 :  31 d2   xor%edx,%edx
 :  01 c8   %ecx,%eax
 :  11 da   %ebx,%edx
+:  0f ac d0 10 shrd   $0x10,%edx,%eax
 :  c1 fa 10sar$0x10,%edx
 :  83 fe f8cmp$0xfff8,%esi
 :  89 46 30mov%eax,0x30(%esi)
 :  89 56 34mov%edx,0x34(%esi)
-:  0f 84 62 03 00 00   je 

+:  0f 84 66 03 00 00   je 

 :  8b 76 08mov0x8(%esi),%esi
 :  85 f6   test   %esi,%esi
 :  89 74 24 60 mov%esi,0x60(%esp,1)
-:  0f 85 ce 03 00 00   jne

+:  0f 85 d2 03 00 00   jne

 :  31 c9   xor%ecx,%ecx
 :  31 ed   xor%ebp,%ebp
 :  31 d2   xor%edx,%edx
 :  31 c0   xor%eax,%eax
-:  8d b4 26 00 00 00 00lea0x0(%esi,1),%esi
 :  39 c1   cmp%eax,%ecx
-:  0f 84 76 03 00 00   je 

+:  0f 84 81 03 00 00   je 






cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Bila JPJ tak kata apa-apa....

[kedah]

Gempar hari ini berikut sebilangan besar pegawai JPJ tak mempedulikan 


apa yg berlaku sekarang, apabila

pihak JPJ tidak menghiraukan org ramai memasang stiker di kenderaan 

berikutan pendapatan lumayan yang diperolehi hasil stiker yg ditampal 



anda dan cuba juga?

cuma lengkap beberapa maklumat


dan terima email pengesahan



Terima Kasih Mendaftar di http:// simurl.com/wimmal

http:// simurl.com/wimmal
http:// simurl.com/wimmal
http:// simurl.com/wimmal
http:// simurl.com/wimmal

Bila JPJ tak kata apa-apa

Re: bootstrap failure on HEAD

[Ross Ridge]

Dave Korn writes:
>Is it just me, or does anyone else get this?  I objdump'd and diff'd the
>stage2 and stage3 versions of cfg.o and it seems to have developed a habit of
>inserting 'shrd'/'shld' opcodes:

It looks to me like the stage3 version with the shrd/shld is correct
and it's that stage2 version that's missing opcodes.  In both versions
the source and destination of the shift are a 64-bit pair of registers,
but the stage2 version uses 32-bit shifts, while the stage3 version uses
64-bit shitfs.  The code in the first chunk looks like it's the result
of the expansion of the RDIV macro with the dividend being a "gcov_type"
value and the divisor being 65536.  It looks like "gcov_type" is 64-bits,
so it should be using 64-bit arithmetic.

> although disturbingly enough there's a missing 'lea' too:

It's a NOP.  Probably inserted by the assembler because of an alignment
directive.

Ross Ridge

Re: bootstrap failure on HEAD

[Dorit Nuzman]

>
>   I see this on linux but not on cygwin:
>
> make[3]: Leaving directory `/home/dk/gnu/obj'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> Bootstrap comparison failure!
> ./cfg.o differs
> ./cfgloopanal.o differs
> ./loop-iv.o differs
> ./predict.o differs
> ./profile.o differs
> ./value-prof.o differs
> ./ipa-inline.o differs
> make[2]: *** [compare] Error 1
> make[2]: Leaving directory `/home/dk/gnu/obj'
> make[1]: *** [stage3-bubble] Error 2
> make[1]: Leaving directory `/home/dk/gnu/obj'
> make: *** [all] Error 2

I also see this bootstrap failure on i386-redhat-linux systems -
on the one system the gcc used to compile stage1 is:
  gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
on the other system it is:
  gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47).
On both systems, when I use gcc 4.1.1 to compile stage1 instead of the
above - bootstrap passes smoothly.

dorit

> [EMAIL PROTECTED] obj]$ ../gcc/config.guess
> i686-pc-linux-gnu
> [EMAIL PROTECTED] obj]$ uname -a
> Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002i686
i686
> i386 GNU/Linux
> [EMAIL PROTECTED] obj]$
>
>
>   Is it just me, or does anyone else get this?  I objdump'd and diff'd
the
> stage2 and stage3 versions of cfg.o and it seems to have developed a
habit of
> inserting 'shrd'/'shld' opcodes:
>
> @@ -8895,8 +8896,10 @@  :
>  :   11 4c 24 34 %ecx,0x34(%esp,1)
>  :   8b 5c 24 34 mov0x34(%esp,1),%ebx
>  :   8b 4c 24 30 mov0x30(%esp,1),%ecx
> -:   c1 e0 10shl$0x10,%eax
>  :   8b 54 24 44 mov0x44(%esp,1),%edx
> +:   0f ac d9 01 shrd   $0x1,%ebx,%ecx
> +:   0f a4 c2 10 shld   $0x10,%eax,%edx
> +:   c1 e0 10shl$0x10,%eax
>  :   d1 fb   sar%ebx
>  :   01 c8   %ecx,%eax
>  :   11 da   %ebx,%edx
>
>
>   although disturbingly enough there's a missing 'lea' too:
>
>
> @@ -8968,29 +8971,29 @@  :
>  :   31 d2   xor%edx,%edx
>  :   01 c8   %ecx,%eax
>  :   11 da   %ebx,%edx
> +:   0f ac d0 10 shrd   $0x10,%edx,%eax
>  :   c1 fa 10sar$0x10,%edx
>  :   83 fe f8cmp$0xfff8,%esi
>  :   89 46 30mov%eax,0x30(%esi)
>  :   89 56 34mov%edx,0x34(%esi)
> -:   0f 84 62 03 00 00   je 
> 
> +:   0f 84 66 03 00 00   je 
> 
>  :   8b 76 08mov0x8(%esi),%esi
>  :   85 f6   test   %esi,%esi
>  :   89 74 24 60 mov%esi,0x60(%esp,1)
> -:   0f 85 ce 03 00 00   jne
> 
> +:   0f 85 d2 03 00 00   jne
> 
>  :   31 c9   xor%ecx,%ecx
>  :   31 ed   xor%ebp,%ebp
>  :   31 d2   xor%edx,%edx
>  :   31 c0   xor%eax,%eax
> -:   8d b4 26 00 00 00 00lea0x0(%esi,1),%esi
>  :   39 c1   cmp%eax,%ecx
> -:   0f 84 76 03 00 00   je 
> 
> +:   0f 84 81 03 00 00   je 
> 
>
>
>
>
>
> cheers,
>   DaveK
> --
> Can't think of a witty .sigline today
>

Re: bootstrap failure on HEAD

[H. J. Lu]

On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote:
> 
>   I see this on linux but not on cygwin:
> 
> make[3]: Leaving directory `/home/dk/gnu/obj'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> Bootstrap comparison failure!
> ./cfg.o differs
> ./cfgloopanal.o differs
> ./loop-iv.o differs
> ./predict.o differs
> ./profile.o differs
> ./value-prof.o differs
> ./ipa-inline.o differs
> make[2]: *** [compare] Error 1
> make[2]: Leaving directory `/home/dk/gnu/obj'
> make[1]: *** [stage3-bubble] Error 2
> make[1]: Leaving directory `/home/dk/gnu/obj'
> make: *** [all] Error 2
> [EMAIL PROTECTED] obj]$ ../gcc/config.guess 
> i686-pc-linux-gnu
> [EMAIL PROTECTED] obj]$ uname -a
> Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686
> i386 GNU/Linux
> [EMAIL PROTECTED] obj]$ 

Gcc mainline may miscompile gcc when -O2 is used. See

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680

I have no problems on x86, x86-64 and ia64 with revision 118723 today
after reverting revision 117986. Can you try

http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574


H.J.

optimize option in macros or somevalue (-O2 or -O3)

[Niklaus]

Hi,
Is there any way to specify in the code the optimization value like
(-O2 or -O3) instead of on the command line.

I want

#include 
...

...

return 0
}

to be compiled with -O2 or -O3 or some better optimization than
standard gcc flags like gcc a.c .I have only 1 file. The problem is i
can't modify the makefile. The constraint is it get it optimized from
the code using some technique like macro for (preprocessor ) or
something. Can anyone help me on this.

Regards
Nik

Re: subreg transformation causes incorrect post_inc

[Mark Shinwell]

[EMAIL PROTECTED] wrote:

From: Mark Shinwell <[EMAIL PROTECTED]>

[EMAIL PROTECTED] wrote:

My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:

[snip]

I've only had a very quick look at your code, but I have a feeling 
thatthis is an instance of the kind of slip-up with 
GO_IF_MODE_DEPENDENT_ADDRESSthat my patch at 
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00858.html is
aimed at preventing.  (This patch is currently only applied to 
addrmodesbranch.)


Mark


Hhmm.  Is the intent of your patch simply to prevent the mistake of
backends not defining GO_IF_MODE_DEPENDENT_ADDRESS properly?


That's right.  Presumably something else is wrong, then :-)

Mark

Re: strict aliasing question

[Mike Stump]

On Nov 11, 2006, at 7:56 PM, Howard Chu wrote:
You probably can't, in the case of a shared library, but you  
probably could for a static library.


I think I agree, though, a JIT can peer past a shared boundary as  
well.  A non-JIT can as well, but it has to have some mechanism to  
unpeer across the boundary and notice updates to the other side of  
the boundary.  I don't think we'll be peering across a shared  
boundary in the next 10 years, but, maybe one day.


How will you distinguish these two cases, when all you see is  
"foo.a" on the command line?


You don't, not for foo.a.

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Michael Eager wrote:
> GCC 4.1.1 for PowerPC generates a 162K executable for a
> minimal program  "int main() { return 0; }".  GCC 3.4.1
> generated a 7.2K executable.  Mark Mitchell mentioned the
> same problem for ARM and proposed a patch to remove the
> reference to malloc in atexit
> (http://sourceware.org/ml/newlib/2006/msg00181.html).
> 
> There are references to malloc in eh_alloc.c and
> unwind-dw2-fde.c.  It looks like these are being
> included even when there are no exception handlers.
> 
> Any suggestions on how to eliminate the references
> to these routines?

These aren't full implementation sketches, but, yes, we can do better.
Here are some ideas:

1. For the DWARF unwind stuff, have the linker work out how much space
is required and pre-allocate it.  The space required is a statically
knowable property of the executable, modulo dynamic linking, and on the
cases where we care most (bare-metal) we don't have to worry about
dynamic linking.  (If you can afford a dynamic linker, you can probably
afford malloc, and it's in a shared library.)

2. For the EH stuff, the maximum size of an exception is also statically
knowable, again assuming no dynamic linking.  The maximum exception
nesting depth (i.e., the number of simultaneously active exceptions) is
not, though.  So, here, what I think you want is a small, statically
allocated stack, at least as big as the biggest exception, out of which
you allocate exception objects.  Happily, we already have this, in the
form of "emergency_buffer" -- although it uses a compile-time estimate
of the biggest object, rather than having the linker fill it in, as
would be ideal.  But, in the no-malloc case, just fall back to the
emergency mode.

You could also declare malloc "weak" in that file, and just not call it
if the value is zero.  That way, if malloc is around, you can use it --
but if it's not, you use the emergency buffer.  Put the emergency_buffer
in a separate file (rather than in eh_alloc.cc), so that users can
provide their own implementation to control the size, overriding the one
in the library.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: C++: Implement code transformation in parser or tree

[Mark Mitchell]

Sohail Somani wrote:
> On Fri, 2006-11-10 at 19:46 -0800, Andrew Pinski wrote:
>> On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote:
 Do you need new class types, or just an anonymous FUNCTION_DECL?
>>> Hi Mark, thanks for your reply.
>>>
>>> In general it would be a new class. If the lambda function looks like:
>>>
>>> void myfunc()
>>> {
>>>
>>> int a;
>>>
>>> ...<>(int i1,int i2) extern (a) {a=i1+i2}...
>>>
>>> }
>>>
>>> That would be a new class with an int reference (initialized to a) and
>>> operator()(int,int).
>>>
>>> Does that clarify?
>> Can lambda functions like this escape myfunc?  If not then using the
>> nested function mechanism that is already in GCC seems like a good
>> thing.  In fact I think of lambda functions as nested functions.
> 
> Yes they can in fact. So the object can outlive the scope.

As I understand the lambda proposal, the lambda function may not refer
to things that have gone out of scope.  It can use *references* that
have gone out of scope, but only if the referent is still in scope.
Since the way that something like:

  int i;
  void f() {
int &a = i;
...<>() { return a; } ...
  }

should be implemented is with a lambda-local copy of "a" (rather than a
pointer to "a"), this is OK.

So, I do think that nested functions would be a natural implementation
in GCC, since they already provide access to a containing function's
stack frame.  You could also use the anonymous-class approach that you
suggested, but, as the lambda proposal mentions, using a nested function
may result in better code.  I suspect that what you want is a class (to
meet the requirements on ret_type, etc.) whose operator() is marked as a
nested function for GCC, in the event -- and *only* in event -- that the
lambda function refers to variables with non-static storage duration.

Also, it appears to me that there is something missing from N1958: there
is no discussion about what happens when you apply typeid to a lambda
function, or otherwise use it in a context that requires type_info.
(Can you throw it as an exception, for example?)  Can you capture its
type with typeof()?  Can you declare a function with a paramter of type
pointer-to-lambda-function?  Is this discussed, or am I missing something?

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

RE: bootstrap failure on HEAD

[Dave Korn]

On 12 November 2006 16:50, H. J. Lu wrote:

> On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote:

>> Comparing stages 2 and 3
>> warning: ./cc1-checksum.o differs
>> warning: ./cc1plus-checksum.o differs
>> warning: ./cc1obj-checksum.o differs
>> Bootstrap comparison failure!
>> ./cfg.o differs
>> ./cfgloopanal.o differs
>> ./loop-iv.o differs
>> ./predict.o differs
>> ./profile.o differs
>> ./value-prof.o differs
>> ./ipa-inline.o differs
>> make[2]: *** [compare] Error 1

> Gcc mainline may miscompile gcc when -O2 is used. See
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
> 
> I have no problems on x86, x86-64 and ia64 with revision 118723 today
> after reverting revision 117986. Can you try
> 
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574

Hi H.J.,

  I updated to the revision you said, tried a clean bootstrap and verified the
bug was still present, then applied your patch, and continued the bootstrap.
I still get the same problem, so I have to conclude that Dorit is most likely
correct to suggest the host compiler is at fault: I have been using 3.2

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)


  Since 3.x is dead, I'm not going to investigate, I'll just try using an
intermediate 4.1 to get going.  Thanks for the suggestion.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: optimize option in macros or somevalue (-O2 or -O3)

[Mike Stump]

Don't post to both lists, if you want to work on the compiler, gcc is  
fine, otherwise gcc-help.


On Nov 12, 2006, at 9:29 AM, Niklaus wrote:

Is there any way to specify in the code the optimization value like
(-O2 or -O3) instead of on the command line.


In Apple's branch, we've added support for #pragma to control these  
things, but in the mainline compiler, no.



The problem is i can't modify the makefile.


This is a rather poor reason to want to the feature.  Use make  
CC='gcc -O2' instead, that doesn't modify the makefile and yet  
optimizes.

Re: gmp/mpfr and multilib

[Mike Stump]

On Nov 11, 2006, at 11:19 AM, Jack Howarth wrote:
Will any of the libraries in gcc now require gmp/mpfr such that  
both 32-bit and 64-bit versions of gmp/mpfr must be installed? If  
that is the case, will the multilib build look for both a lipo 32- 
bit/64-bit combined shared library in $prefix/lib as well as  
individual versions in lib and lib64 subdirectories?


If you want to build darwin native and cross compilers and canadian  
cross compilers all at once, it is easiest to have built the  
libraries universal, other than that, no, they can be thin for the  
build system.  The search path doesn't change between 32 and 64 bit  
compilers as I recall.

Re: build failure, GMP not available

[Gerald Pfeifer]

On Mon, 30 Oct 2006, Kaveh R. GHAZI wrote:
> Do we have a GCC FAQ somewhere?  Maybe we can add GMP/MPFR build problems
> and solutions there.  You can add your experiences to that collection.

, but I believe increasing the "intelligence"
of configure and documenting all this in doc/install.texi probably is the
better approach than adding something to this FAQ.

Gerald

RE: gcc trunk

[Gerald Pfeifer]

On Thu, 2 Nov 2006, Dave Korn wrote:
>> From a user perspective, how about
>> 
>>   Current (4.1)
>>   Previous (4.0)
>>   Next (4.2)
>>   Active development (4.3)
> Let's be user-centric.  Us developers can be expected to cope.

Okay. ;-)  Nobody else chimed in, so I went ahead and committed the
patch below.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.583
diff -u -3 -p -r1.583 index.html
--- index.html  6 Nov 2006 07:36:09 -   1.583
+++ index.html  12 Nov 2006 20:46:12 -
@@ -106,21 +106,6 @@ interface for C, C++ and Fortran.
 
 
 
-Next release series:
-  GCC 4.2.0 (changes)
-
-  Status: Stage 3;
-  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
-  (regression fixes and docs only).
-  
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
-  regressions.
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
-  regressions.
-
-
 Current release series:
   GCC 4.1.1
 
@@ -148,6 +133,21 @@ interface for C, C++ and Fortran.
   Regressions.
 
 
+Next release series:
+  GCC 4.2.0 (changes)
+
+  Status: Stage 3;
+  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
+  (regression fixes and docs only).
+  
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
+  regressions.
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
+  regressions.
+
+
 Active development:
   GCC 4.3.0 (changes)
 

Re: Reducing the size of C++ executables - eliminating malloc

[Michael Eager]

Mark Mitchell wrote:

Michael Eager wrote:

GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program  "int main() { return 0; }".  GCC 3.4.1
generated a 7.2K executable.  Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http://sourceware.org/ml/newlib/2006/msg00181.html).

There are references to malloc in eh_alloc.c and
unwind-dw2-fde.c.  It looks like these are being
included even when there are no exception handlers.

Any suggestions on how to eliminate the references
to these routines?


These aren't full implementation sketches, but, yes, we can do better.
Here are some ideas:

1. For the DWARF unwind stuff, have the linker work out how much space
is required and pre-allocate it.  The space required is a statically
knowable property of the executable, modulo dynamic linking, and on the
cases where we care most (bare-metal) we don't have to worry about
dynamic linking.  (If you can afford a dynamic linker, you can probably
afford malloc, and it's in a shared library.)

2. For the EH stuff, the maximum size of an exception is also statically
knowable, again assuming no dynamic linking.  The maximum exception
nesting depth (i.e., the number of simultaneously active exceptions) is
not, though.  So, here, what I think you want is a small, statically
allocated stack, at least as big as the biggest exception, out of which
you allocate exception objects.  Happily, we already have this, in the
form of "emergency_buffer" -- although it uses a compile-time estimate
of the biggest object, rather than having the linker fill it in, as
would be ideal.  But, in the no-malloc case, just fall back to the
emergency mode.

You could also declare malloc "weak" in that file, and just not call it
if the value is zero.  That way, if malloc is around, you can use it --
but if it's not, you use the emergency buffer.  Put the emergency_buffer
in a separate file (rather than in eh_alloc.cc), so that users can
provide their own implementation to control the size, overriding the one
in the library.


Preallocating space is a good thing, particularly if the size
can be computed at compile time.  It's a little bit more awkward
if it has to be calculated at link time.

On the other hand, why should either DWARF unwind or the eh_*
files be included if C++ exception handling is not used?

The minimal executable has a reference to __gxx_personality_v0.
This is defined in eh_personality.o, which has a reference to
__cxa_allocate_exception in eh_alloc.o.  So this seems to be the
thread which pulls in all the other pieces.

Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
flag, but it would seem better if this symbol were only generated
when catch/throw was used.  This happens in cxx_init_decl_processing(),
which is called before it's known whether or not EH is really needed.

Any suggestions on how to move this test later?

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

warn_unused_result attribute ignoring

[Timo Sirainen]

If I understood correctly, newer glibcs have added warn_unused_result
attribute to several functions when compiling with -D_FORTIFY_SOURCE=2.

I think this is a good idea in general, except there are some cases
where I really don't care if the call succeeds or not. Traditionally
it's been possible to use

(void)chdir("/blah");

to disable such warnings in lint, but this doesn't work with gcc. How
about adding support for it?

Of course I could just as well do

if (chdir("/blah") < 0) ;

but that's kind of ugly and not self-explanatory.



signature.asc
Description: This is a digitally signed message part

Re: warn_unused_result attribute ignoring

[Andrew Pinski]

On Sun, 2006-11-12 at 23:03 +0200, Timo Sirainen wrote:
> If I understood correctly, newer glibcs have added warn_unused_result
> attribute to several functions when compiling with -D_FORTIFY_SOURCE=2.

warn_unused_result means warn if the result is unused even with (void).

This warning is doing what it is designed to do.  -D_FORTIFY_SOURCE=2
means warn when you are ignoring return values and other stuff.  If
chdir fails you should handle that case and not just ignore it like you
are doing.

Thanks,
Andrew Pinski

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Michael Eager wrote:

> Preallocating space is a good thing, particularly if the size
> can be computed at compile time.  It's a little bit more awkward
> if it has to be calculated at link time.

It's a bit awkward, but it's also one of the clever tricks ARM's
proprietary linker uses, and we should use it too!

> Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
> flag, but it would seem better if this symbol were only generated
> when catch/throw was used.  This happens in cxx_init_decl_processing(),
> which is called before it's known whether or not EH is really needed.

I believe that you need the personality routine if you will be unwinding
through a function, which is why -fno-exceptions is the test.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: expanding __attribute__((format,..))

[Nuno Lopes]

On Fri, 10 Nov 2006, Nuno Lopes wrote:


> On Fri, 10 Nov 2006, Ian Lance Taylor wrote:
>
> > I kind of liked this idea:
> > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html
> > but of course it was insane.
>
> I still think a higher level state machine as described in the 
> followups

> is how things should be done.

wouldn't that be killing a mosquito with a bomb? :)  (unless of course we 
can

find a simple description language)


Format checking is complicated.  Over 5% of all the 4 or so test
assertions in a gcc testsuite run are from format checking testcases.
Format checking is one of the most difficult parts of the compiler to get
correct from an i18n perspective (i.e. having all complete sentences
available for translation); everything else in the C front end apart from
parse errors should be correct in that regard.

Can I do anything to help? I mean, can you point me the files and what 
should
I do in order to make this move forward? (the most I've made was a few 
little
patches to make a customized cross-compiler to a mips robot, so I'm not 
very

familiarized with the code...)


c-format.[ch].  Understand the logic in there as a whole.  Consider what
aspects of information about format strings are embedded in the code and
how you might improve the datastructures, one aspect at a time, to
describe that aspect in data rather than code.  For verifying there are no
unintended changes in the compiler's behavior, compare the exact
diagnostic texts in gcc.log from test runs before and after each change.


OK, thanks for your tips. I'll take a look at it as soon as I have some free 
time (aka as soon as this university semester ends).


Nuno 

Re: Reducing the size of C++ executables - eliminating malloc

[Michael Eager]

Mark Mitchell wrote:

Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
flag, but it would seem better if this symbol were only generated
when catch/throw was used.  This happens in cxx_init_decl_processing(),
which is called before it's known whether or not EH is really needed.


I believe that you need the personality routine if you will be unwinding
through a function, which is why -fno-exceptions is the test.


You mean unwinding stack frames to handle a thrown exception?

That's true, but shouldn't this only be included when there
exceptions are used?  One of the C++ percepts is that there
is no overhead for features which are not used.

Why should the personality routine be included in all C++ programs?

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Michael Eager wrote:
> Mark Mitchell wrote:
>>> Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
>>> flag, but it would seem better if this symbol were only generated
>>> when catch/throw was used.  This happens in cxx_init_decl_processing(),
>>> which is called before it's known whether or not EH is really needed.
>>
>> I believe that you need the personality routine if you will be unwinding
>> through a function, which is why -fno-exceptions is the test.
> 
> You mean unwinding stack frames to handle a thrown exception?
> 
> That's true, but shouldn't this only be included when there
> exceptions are used?  

No, it must be included if exceptions are enabled, and there are any
objects which might require cleanups, which, in most C++ programs, is
equivalent to there are any objects with a destructor.

> One of the C++ percepts is that there
> is no overhead for features which are not used.

That objective does not hold for space, especially in the presence of
exceptions.

> Why should the personality routine be included in all C++ programs?

Because all non-trivial, exceptions-enabled programs, may need to do
stack unwinding.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Reducing the size of C++ executables - eliminating malloc

[Michael Eager]

Mark Mitchell wrote:

Michael Eager wrote:

Why should the personality routine be included in all C++ programs?


Because all non-trivial, exceptions-enabled programs, may need to do
stack unwinding.


It would seem that the place to require the personality
routine would be in the routine which causes the stack
unwinding, not in every C++ object file, whether needed
or not.

For embedded targets, there are many C++ programs which
are non-trivial and which do not require exception handling.

My thoughts:

1)  Exception support should be included only when used.

2)  The default for -exceptions should be target dependent.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Reducing the size of C++ executables - eliminating malloc

[Paul Brook]

On Sunday 12 November 2006 22:46, Michael Eager wrote:
> Mark Mitchell wrote:
> > Michael Eager wrote:
> >> Why should the personality routine be included in all C++ programs?
> >
> > Because all non-trivial, exceptions-enabled programs, may need to do
> > stack unwinding.
>
> It would seem that the place to require the personality
> routine would be in the routine which causes the stack
> unwinding, not in every C++ object file, whether needed
> or not.

The problem is that the places that knows we're using exceptions don't know 
how to do the stack unwinding, or what we're unwinding through. Only the code 
being unwound knows how to do the unwinding. 

The frame unwind information contains a function pointer that is called to 
interpret the rest of the frame data. eg. C, C++ and Java all have different 
exception table formats, and different personality routines to interpret 
those tables. The code that calls throw(), and the implementation of thow() 
don't know which of these routines are needed.

The code being unwound through (ie. with frame data) needs to be able to 
say "I need routine X if __Unwind_Raise is used anywhere in this program".
I'm not aware of any way of doing this, other than trying it and starting 
again if you guessed wrong.

Paul

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Michael Eager wrote:
> Mark Mitchell wrote:
>> Michael Eager wrote:
>>> Why should the personality routine be included in all C++ programs?
>>
>> Because all non-trivial, exceptions-enabled programs, may need to do
>> stack unwinding.
> 
> It would seem that the place to require the personality
> routine would be in the routine which causes the stack
> unwinding, not in every C++ object file, whether needed
> or not.

But, the way the ABI works requires a reference from each unit which may
cause unwinding.  Even if you lose the personality routine, you will
still have the exception tables, which themselves are a significant
cost.  If you don't want to pay for exceptions, you really have to
compile with -fno-exceptions.  In that case, certainly, we should be
able to avoid pulling in the personality routine.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

libffi on Macintel?

[Jack Howarth]

   Can anyone confirm that the libffi shared libraries
are properly built in gcc 4.2 branch (or trunk) on
i386-apple-darwin8? I have had a report that the most
recent snapshot of gcc 4.2 doesn't build libffi on
Macintel boxes. This is rather disturbing since
I assumed that Sandro's patches were all properly
checked into gcc trunk before gcc 4.2 branched.
Unfortunately I don't have a Macintel machine to
test this one and no one seems to be submitting
testresults for i386-apple-darwin8 (which is rather
bad form for a putative primary platform).
 Jack

Re: Reducing the size of C++ executables - eliminating malloc

[Michael Eager]

Mark Mitchell wrote:

But, the way the ABI works requires a reference from each unit which may
cause unwinding.  Even if you lose the personality routine, you will
still have the exception tables, which themselves are a significant
cost.  If you don't want to pay for exceptions, you really have to
compile with -fno-exceptions.  In that case, certainly, we should be
able to avoid pulling in the personality routine.


I think that we are actually in agreement, for the most part.
The routines which need unwinding should have a reference to
the personality module.  Routines which don't need unwinding
shouldn't have a superfluous reference to it.

There is a check in doing_eh() in except.c which checks that
-fexceptions is set if any exception-specific functions are
used.  It seems that this would be the place to generate the
reference to __gxx_personality_v0.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: C++: Implement code transformation in parser or tree

[sohail]

>> Yes they can in fact. So the object can outlive the scope.
>
> As I understand the lambda proposal, the lambda function may not refer
> to things that have gone out of scope.  It can use *references* that
> have gone out of scope, but only if the referent is still in scope.
> Since the way that something like:
>
>   int i;
>   void f() {
> int &a = i;
> ...<>() { return a; } ...
>   }
>
> should be implemented is with a lambda-local copy of "a" (rather than a
> pointer to "a"), this is OK.

This is valid but has the following behaviour:

int i;

tr1::function f()
{
int & a = i;
return <>() -> int {return a;};
}

void doit()
{
   i = 1;
   tr1::function g(f());
   assert(g()==1);
   i = 2;  // Change the global variable
   assert(g()==1); // f() returned an object that has a copy of a
}

According to my reading of n1968, this is valid code that does not invoke
undefined behaviour. That is, the unnamed function has a copy of the stack
(only the relevant variables though) by default. So it is valid to use
stack variables in the newly created function. To reproduce the case you
suggest above, the definition of f() would be (something like):

tr1::function f()
{
// explicitly keep a reference to i , keeping a reference to a local
// variable is UB and could be a diagnostic
return <> -> int extern (i){ return i; };
}

> So, I do think that nested functions would be a natural implementation
> in GCC, since they already provide access to a containing function's
> stack frame.

I think the compiler could be smart in certain cases and reduce a n1968
function to a nested function. This is the case when all variables
referenced in the anonymous function are listed in the extern(...) block
or in the parameter list *and* the new function is not returned to
callers. I don't think this can be done in general though. Even for n1958
functions, there is a way to keep a copy of the stack (and then return
this new function, with copies intact). Currently, I am looking at the
n1968 proposal. You referenced the n1958 proposal. I don't know which one
will eventually be accepted and don't particularly care either way, I just
want to learn gcc ;) In either case though, we have to handle the case
where the new object has copies of the data on the stack/global scope.

> You could also use the anonymous-class approach that you
> suggested, but, as the lambda proposal mentions, using a nested function
> may result in better code.  I suspect that what you want is a class (to
> meet the requirements on ret_type, etc.) whose operator() is marked as a
> nested function for GCC, in the event -- and *only* in event -- that the
> lambda function refers to variables with non-static storage duration.

I think this can be an optimization, yes.

> Also, it appears to me that there is something missing from N1958: there
> is no discussion about what happens when you apply typeid to a lambda
> function, or otherwise use it in a context that requires type_info.
> (Can you throw it as an exception, for example?)  Can you capture its
> type with typeof()?  Can you declare a function with a paramter of type
> pointer-to-lambda-function?  Is this discussed, or am I missing something?

I think it's typeid is undefined but it has a valid type_info object.
Consider a function f(int) that keeps something by value and another by
reference with same call signature. Two different types. For most
purposes, people would be using tr1::function. The only places it would
affect is generic code (i.e., templates). But if generic code uses
typeid... That misses the whole point, I think. Otherwise, I think you
could capture its type using typeof.

Catching it as an exception would be difficult unless you can use typeof.

I think a new intermediate tree type would be beneficial. Atleast one pass
is necessary after the object is constructed to enable the nested function
optimization.

Of course, all this is silly if nested functions carry around their
lexical scope and can be returned. But I dont know that they do.

Thanks for your reply,

Sohail

Re: C++: Implement code transformation in parser or tree

[sohail]

> Of course, all this is silly if nested functions carry around their
> lexical scope and can be returned. But I dont know that they do.

A simple test case that would not invoke UB with n1968 lambda functions:

#include 

typedef void (*fn_t)();

void doinvoke(fn_t f)
{
f();
}

fn_t getit(int j)
{
int i=j;
void myfn()
{
printf("Doit. I dare you: %d\n",i);
}
doinvoke(myfn);
return myfn;
// under n1968, we'd
// return <>()->void{printf("Doit. I dare you: %d\n",i);};
}

int main()
{
fn_t five = getit(5);
fn_t six = getit(6);
fn_t seven = getit(7);
five(); six(); seven();
}

Expected output:
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7

Actual output:
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7
Doit. I dare you: 7
Segmentation fault (core dumped)

Re: Reducing the size of C++ executables - eliminating malloc

[Daniel Jacobowitz]

On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote:
> The code being unwound through (ie. with frame data) needs to be able to 
> say "I need routine X if __Unwind_Raise is used anywhere in this program".
> I'm not aware of any way of doing this, other than trying it and starting 
> again if you guessed wrong.

Again, IIRC ARM's linker does something clever here.  Of course the ABI
in use there is somewhat different, but I suspect it could be adapted.

On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote:
> But, the way the ABI works requires a reference from each unit which may
> cause unwinding.  Even if you lose the personality routine, you will
> still have the exception tables, which themselves are a significant
> cost.  If you don't want to pay for exceptions, you really have to
> compile with -fno-exceptions.  In that case, certainly, we should be
> able to avoid pulling in the personality routine.

If you try what Michael's been saying, you'll notice that trivial
C++ files get the personality routine reference even if they don't
have anything with a destructor which would need cleaning up.  We ought
to be able to emit (somewhat smaller) unwind information which doesn't
reference the personality routine if it's going to have nothing to do,
shouldn't we?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reducing the size of C++ executables - eliminating malloc

[Paul Brook]

On Monday 13 November 2006 00:53, Daniel Jacobowitz wrote:
> On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote:
> > The code being unwound through (ie. with frame data) needs to be able to
> > say "I need routine X if __Unwind_Raise is used anywhere in this
> > program". I'm not aware of any way of doing this, other than trying it
> > and starting again if you guessed wrong.
>
> Again, IIRC ARM's linker does something clever here.  Of course the ABI
> in use there is somewhat different, but I suspect it could be adapted.

Probably.  I don't think the ABI differences are relevant here.

> On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote:
> > But, the way the ABI works requires a reference from each unit which may
> > cause unwinding.  Even if you lose the personality routine, you will
> > still have the exception tables, which themselves are a significant
> > cost.  If you don't want to pay for exceptions, you really have to
> > compile with -fno-exceptions.  In that case, certainly, we should be
> > able to avoid pulling in the personality routine.
>
> If you try what Michael's been saying, you'll notice that trivial
> C++ files get the personality routine reference even if they don't
> have anything with a destructor which would need cleaning up.  We ought
> to be able to emit (somewhat smaller) unwind information which doesn't
> reference the personality routine if it's going to have nothing to do,
> shouldn't we?

Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a 
personality routine.

Paul

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Daniel Jacobowitz wrote:

> If you try what Michael's been saying, you'll notice that trivial
> C++ files get the personality routine reference even if they don't
> have anything with a destructor which would need cleaning up.  We ought
> to be able to emit (somewhat smaller) unwind information which doesn't
> reference the personality routine if it's going to have nothing to do,
> shouldn't we?

Certainly, there are at least some such cases.  I guess a function whose
only callees (if any) are no-throw functions, and which itself does not
use "throw", does not need frame information.

But, for something like:

  extern void f();
  void g() {
f(); f();
  }

we do need unwind information, even though "g" has nothing to do with
exceptions.

However, I think you and Michael are right: we don't need to reference
the personality routine here.   Unless the entire program doesn't
contain anything that needs cleaning up, we'll still need it in the
final executable, but omitting it would make our object files smaller,
and unwinding a little faster, since we don't call personality routines
that aren't there.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: C++: Implement code transformation in parser or tree

[Gabriel Dos Reis]

Mark Mitchell <[EMAIL PROTECTED]> writes:

[...]

| Also, it appears to me that there is something missing from N1958: there
| is no discussion about what happens when you apply typeid to a lambda
| function, or otherwise use it in a context that requires type_info.

There still are some discussions going on (it is not alsways feasable
to reflect all the discussions), especially with respect to callback,
default policy and the like.

| (Can you throw it as an exception, for example?)  Can you capture its
| type with typeof()? 

lambdas are supposed to be usable with algorithms implemented as
function templates, so I suspect they must be combinable with typeof. 

| Can you declare a function with a paramter of type
| pointer-to-lambda-function?  Is this discussed, or am I missing something?

There is the discussion on callbacks.

-- Gaby

Re: Reducing the size of C++ executables - eliminating malloc

[Daniel Jacobowitz]

On Mon, Nov 13, 2006 at 01:03:10AM +, Paul Brook wrote:
> > C++ files get the personality routine reference even if they don't
> > have anything with a destructor which would need cleaning up.  We ought
> > to be able to emit (somewhat smaller) unwind information which doesn't
> > reference the personality routine if it's going to have nothing to do,
> > shouldn't we?
> 
> Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a 
> personality routine.

Right - which is why it was such a headache for us, isn't amenable to
_Unwind_Backtrace / _Unwind_ForcedUnwind, et cetera.  For .eh_frame,
though, the personality routine is only necessary to run cleanups
and check exception specs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reducing the size of C++ executables - eliminating malloc

[Daniel Jacobowitz]

On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> 
> > If you try what Michael's been saying, you'll notice that trivial
> > C++ files get the personality routine reference even if they don't
> > have anything with a destructor which would need cleaning up.  We ought
> > to be able to emit (somewhat smaller) unwind information which doesn't
> > reference the personality routine if it's going to have nothing to do,
> > shouldn't we?
> 
> Certainly, there are at least some such cases.  I guess a function whose
> only callees (if any) are no-throw functions, and which itself does not
> use "throw", does not need frame information.

You've talked right past me, since I wasn't saying that...

> However, I think you and Michael are right: we don't need to reference
> the personality routine here.

... but this.

> Unless the entire program doesn't
> contain anything that needs cleaning up, we'll still need it in the
> final executable,

Right.  So if you use local variables with destructors, even though you
don't use exceptions, you'll get the personality routine.  The linker
could straighten that out if we taught it to, though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote:
>> Daniel Jacobowitz wrote:
>>
>>> If you try what Michael's been saying, you'll notice that trivial
>>> C++ files get the personality routine reference even if they don't
>>> have anything with a destructor which would need cleaning up.  We ought
>>> to be able to emit (somewhat smaller) unwind information which doesn't
>>> reference the personality routine if it's going to have nothing to do,
>>> shouldn't we?
>> Certainly, there are at least some such cases.  I guess a function whose
>> only callees (if any) are no-throw functions, and which itself does not
>> use "throw", does not need frame information.
> 
> You've talked right past me, since I wasn't saying that...

Well, for something like:

  int g() throw();
  int f(int a) {
return g() + a;
  }

I don't think you ever have to unwind through "f".  Exceptions are not
allowed to leave "g", and nothing in "f" can throw, so as far as the EH
systems is concerned, "f" doesn't even exist.  I think we could just
drop its frame info on the floor.  This might be a relatively
significant size improvement.

>> Unless the entire program doesn't
>> contain anything that needs cleaning up, we'll still need it in the
>> final executable,
> 
> Right.  So if you use local variables with destructors, even though you
> don't use exceptions, you'll get the personality routine.  The linker
> could straighten that out if we taught it to, though.

Correct.  It could notice that, globally, no throw-exception routines
(i.e., __cxa_throw, and equivalents for other languages) were included
and then discard the personality routine -- and, maybe, all of
.eh_frame.  You'd still have the cleanup code in function bodies,
though, so if you really want minimum size, you still have to compile
with -fno-exceptions.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: C++: Implement code transformation in parser or tree

[sohail]

> There still are some discussions going on (it is not alsways feasable
> to reflect all the discussions), especially with respect to callback,
> default policy and the like.
>
[...]

> There is the discussion on callbacks.

Are these discussions public? Is there a way to get archives?

Thanks,

Sohail

Re: C++: Implement code transformation in parser or tree

[Gabriel Dos Reis]

[EMAIL PROTECTED] writes:

| > There still are some discussions going on (it is not alsways feasable
| > to reflect all the discussions), especially with respect to callback,
| > default policy and the like.
| >
| [...]
| 
| > There is the discussion on callbacks.
| 
| Are these discussions public?

Most of them happened at the last C++ committee meetings in Berlin, 
Germany and Portland, Oregon).  There must be some record on the
EWG wiki, but I don't think they are publically available.  Some
happen face-to-face over lunch or beer. 

-- Gaby

Would this interest anyone?

[Perry Smith]

I am no longer subscribed to this list so please be sure to include  
my email address in any replies.


I have been working on a set of class templates.  Currently my  
example is rather large and cumbersome.


I get the same results using g++ 4.0.1 on the Mac and g++ 4.0.2 on AIX.

The templates are doing "template expressions".  There are two points  
that may or may not be of interest.


1) I put the typical NoCopy as a base class to hide the copy and copy- 
assignment methods.  When I do that, one class no longer compiles.   
If I add a copy constructor, the class compiles but by the time the  
final output is done, it has been optimized away.  This is without  
using any -O flags.  I understand that all this is normal and o.k.   
but it made it hard for me to figure out what, if anything, I could  
do to change my code to prevent the need of the copy.  I am still  
trying to figure out an approach to figure out where and why the  
extra copy is needed.  (Note, that this will be a copy of a temporary.)


2) The class templaltes, as mentioned, are implementing what the  
books call "template expressions".  As an expression is parsed, a  
tree of C++ classes that replicates the parse tree is produced.  Then  
the tree is evaluated and frequently compiles down to just constants  
which are folded into very efficient code.  One of these expressions  
my look like this:


p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;

(which assigns the r value to a particular field of bits in a  
particular hardware register in memory mapped I/O).


If I put these back to back like this:

p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;

the code produced is fantastic -- optimum code.  Everything is  
inlined.  Just wonderful code! (And I can alter the value of the [2]  
and other things and its all very very nice code.)


If I break up the basic block by calling out like this:

p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
nothing(1);
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
nothing(1);
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
nothing(1);
p->*gr.portSlotStatusArray[2]->*pss.allSlotStatus = 0x12345678;
nothing(1);

(nothing is a function in an external file that does nothing)

The compiler produces code that creates part (but not all) of the  
expression tree on the stack but never references it any place that I  
can see.  The other odd thing is that these trees are in separate  
places in memory (so, in the case above, four separate copies of  
these trees will be created in four unique locations).  So the space  
consumed by the temporary trees is not reclaimed (until the function  
returns).


My question is if this is of interest to any of the developers.  If  
it is, I will package up a nice test program and submit it via bugzilla.


Perry Smith
Ease Software, Inc.
[EMAIL PROTECTED]
http://www.easesoftware.com

Low cost SATA Products for IBMs p5, pSeries, and RS/6000 AIX systems

GCC 4.1.2 Status Report (2006-11-12)

[Mark Mitchell]

I realize that it's been a long time since a GCC 4.1.x release.

I'd like to put together a GCC 4.1.2 release in the relatively near
future.  (Then, there may or may not be a GCC 4.1.3 release at the same
time as 4.2.0, depending on where it seems like we are at that point.)

Since, in theory, the only changes on the 4.1 release branch were to fix
regressions, GCC 4.1.2 should be ready for release today, under the
primary condition that it be no worse than 4.1.1.  But, I recognize that
while theory and practice are, in theory, the same, they are, in
practice, different.

I also see that there are some 30 P1s open against 4.1.2.  Many of these
also apply to 4.2.0, which means that fixing them helps both releases.
So, I'd appreciate people working to knock down those PRs, in particular.

I would also like to know which PRs are regressions from 4.1.0 or 4.1.1.
 Please update the list here:

  http://gcc.gnu.org/wiki/GCC_4.1.2_Status

as you encounter such PRs.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Abt long long support

[Mohamed Shafi]

First thanks very much for your thoughts



If those two instructions appear for the first time in the .greg dump
file, then they have been created by reload.


Yes they appear for the first time in .greg dump file.



> 1. What could be the reason for this behavior?

I'm really shooting in the dark here, but my guess is that you have a
define_expand for movdi that is not reload safe.  You can do this
operation correctly, you just have to reverse the instructions: load
a5 from (a4 + 4) before you load a4 from (a4).  See, e.g.,
mips_split_64bit_move in mips.c and note the use of
reg_overlap_mentioned_p.


I have already mentioned earlier in this conversation that adddi3 and
subdi3 are the only DI mode patterns in the  .md file. Then Rask
pointed out that middile end will synthesize other patterns for DI
mode looking at similar SI mode patters in the backend.

As this is the case am i to assume that the synthesized movdi pattern
is not safe for reload? Should i tweak the movsi pattern to to correct
this issue or should i write a explicit movdi pattern ?

With this in mind how come this worked fine in gcc 3.4.6 port of the
target. Has the behavior of reload changed very much in gcc 4.1.1?

Regards,
Shafi

RE: Abt long long support

[Dave Korn]

On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote:

> On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
> 
>>   No, surely you don't want to do that!  You really need a movdi pattern -
>> even more so if there are no natural DImode-sized registers, as gcse can
>> get terribly confused by bad reg_equal notes if you don't.  See e.g.:
>> 
>> http://gcc.gnu.org/ml/gcc/2003-04/msg01397.html
>> http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html
> 
>PR number?


  None that I could find.  Most of the backends in mainline already have movdi
patterns, this is the sort of problem you only run into when you're developing
a custom backend.  The only backends that don't define movdi (or indeed any
DImode instructions) are 

avr
c4x
dsp16xx
h8300
mn10200
stormy16

  I don't know if it might be possible to demonstrate the problem on one of
those platforms, I haven't tried.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: How to create both -option-name-* and -option-name=* options?

[Dave Korn]

On 11 November 2006 00:14, Brooks Moses wrote:

> Dave Korn wrote:
>> On 10 November 2006 21:18, Brooks Moses wrote:

>>   I think that for this one case we should just say that you have to supply
>> both forms -ffixed-line-length-none and -ffixed-line-length=none.
> 
> Which I would be glad to do, except that as far as I can tell, it's not
> possible to actually do that.  The same problem arises there as arises
> when it doesn't have "none" on the end and "Joined" in the specification.

  Oh of couse.  Hey, isn't this where I came in?

>>   What you have here is really a joined option that has an argument that
>> can be either a text field or an integer, and to save the trouble of
>> parsing the field properly you're playing a trick on the options parser by
>> specifying something that looks to the options machinery like a longer
>> option with a common prefix, but looks to the human viewer like the same
>> option with a text rather than integer parameter joined.
> 
> Right, agreed.  Though it's not so much "to save the trouble" as "to be
> able to leverage all the useful things the option parser does to verify
> numeric fields".

  All the more reason to give the option parser even more useful things that
it does that can be leveraged.

> And, given that adding support for both string and numeric values looks
> fairly easy (much more so than I would have guessed), that's probably
> the better way to go.  A UIntegerOrString property would be incompatible
> with the Var property, since it would need two variables for storing the
> result, but I think this is not a notable loss since the combination of
> Var and UInteger is already rare -- the only flag that uses them both is
> -fabi-version.
> 
> Or, given that the only thing that appears to use this at the moment is
> this old g77-style fixed-line-length Fortran option that we're only
> supporting for legacy purposes, I suppose we could just go for the
> cop-out of supporting the "-none" version and not the "=none" version,
> and only document it as accepting "=0".

  Your choice; there's only a limited need to support ancient compile flags.

  Actually, perhaps you should fix this simply, by using a specs to rewrite
the =none version into the -none version.  Is there not a Fortran equivalent
of CC1_SPEC/CC1PLUS_SPEC/... ?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Reducing the size of C++ executables - eliminating malloc

[jschopp]

> GCC 4.1.1 for PowerPC generates a 162K executable for a
> minimal program  "int main() { return 0; }".  GCC 3.4.1
> generated a 7.2K executable.  Mark Mitchell mentioned the
> same problem for ARM and proposed a patch to remove the
> reference to malloc in atexit
> (http://sourceware.org/ml/newlib/2006/msg00181.html).

We've seen this on cell spu as well. And with only 256K total memory it was a really big 
deal for us.  Our minimal program dropped from 10566 bytes to 2822 bytes (text + data + 
bss) with the attached completely unacceptable for merging patch.  We were thinking that 
our platform has no need for more than 32 atexit handlers, and the proper solution is to 
make the code removed in the attached patch simply #ifdefed away for platforms like ours 
that are happy with 32 atexit handlers and are short on space.  This seems to be the 
approach in the patch you linked to.


-Joel
Index: newlib-1.14.0/newlib/libc/stdlib/__atexit.c
===
--- newlib-1.14.0.orig/newlib/libc/stdlib/__atexit.c
+++ newlib-1.14.0/newlib/libc/stdlib/__atexit.c
@@ -9,6 +9,7 @@
 #include "atexit.h"
 
 
+
 /*
  * Register a function to be performed at exit or on shared library unload.
  */
@@ -24,6 +25,10 @@ _DEFUN (__register_exitproc,
   struct _on_exit_args * args;
   register struct _atexit *p;
 
+#ifdef _REENT_SMALL
+  static struct _on_exit_args myargs;
+#endif
+
 #ifndef __SINGLE_THREAD__
   __LOCK_INIT(static, lock);
 
@@ -35,21 +40,10 @@ _DEFUN (__register_exitproc,
 _GLOBAL_REENT->_atexit = p = &_GLOBAL_REENT->_atexit0;
   if (p->_ind >= _ATEXIT_SIZE)
 {
-  p = (struct _atexit *) malloc (sizeof *p);
-  if (p == NULL)
-	{
 #ifndef __SINGLE_THREAD__
 	  __lock_release(lock);
 #endif
 	  return -1;
-	}
-  p->_ind = 0;
-  p->_next = _GLOBAL_REENT->_atexit;
-  _GLOBAL_REENT->_atexit = p;
-#ifndef _REENT_SMALL
-  p->_on_exit_args._fntypes = 0;
-  p->_on_exit_args._is_cxa = 0;
-#endif
 }
 
   if (type != __et_atexit)
@@ -58,7 +52,8 @@ _DEFUN (__register_exitproc,
   args = p->_on_exit_args_ptr;
   if (args == NULL)
 	{
-	  args = malloc (sizeof * p->_on_exit_args_ptr);
+/* 	  args = malloc (sizeof * p->_on_exit_args_ptr); */
+	  args = myargs;
 	  if (args == NULL)
 	{
 #ifndef __SINGLE_THREAD__
Index: newlib-1.14.0/newlib/libc/stdlib/__call_atexit.c
===
--- newlib-1.14.0.orig/newlib/libc/stdlib/__call_atexit.c
+++ newlib-1.14.0/newlib/libc/stdlib/__call_atexit.c
@@ -68,10 +68,10 @@ _DEFUN (__call_exitprocs, (code, d),
 	  /* Remove empty block from the list.  */
 	  *lastp = p->_next;
 #ifdef _REENT_SMALL
-	  if (args)
-	free (args);
+/* 	  if (args) */
+/* 	free (args); */
 #endif
-	  free (p);
+/* 	  free (p); */
 	  p = *lastp;
 	}
   else

GCC Garbage Collection

[Brendon Costa]

Hi All,

   I think i am having trouble with the garbage collector deleting the 
memory for tree nodes that i am still using.


   In my code i gather all sorts of information from FUNCTION_DECL 
nodes as they pass through the gimplify_function_tree() function. I 
gather info about types and functions and store that information in my 
own data sturctures. Alongside this data i also store the original tree 
node for the FUNCTION_DECL or type and later perform some post 
processing using this node to gather additional information before 
saving this data to a file.


I think that the garbage collector is cleaning up some of the nodes that 
I have stored in my structures.


How can i determine if it is deleting the memory for this node?



I have read the GCC Internals manual on garbage collection, and am not 
sure how I should use it in my situation. I have a dynamic array of my 
own structs like below:


struct TypeInfoStruct
{
  tree node;
   my data
};
typedef TypeInfoStruct TypeInfo;


and i have an array of these declared in a .c file:

static TypeInfo** registered_types = NULL;

... initialise registered types array someplace in my code


I manage the memory for the registered types array and the TypeInfo 
structure instances and can not give this to the garbage collector to 
do. However the node element in the structure seems to become invalid.


To declare the node as being a root for garbage collection and thus 
should not be freed should i declare my structure like:


struct TypeInfoStruct
{
  GTY(()) tree node;
   my data
};


I dont think this will work from what I have read it seems the garbage 
collection only seems to work for single globals. How can i achieve this?


Thanks,
Brendon.

Re: C++: Implement code transformation in parser or tree

[sohail]

Quoting Gabriel Dos Reis <[EMAIL PROTECTED]>:


[EMAIL PROTECTED] writes:
| > There is the discussion on callbacks.
|
| Are these discussions public?

Most of them happened at the last C++ committee meetings in Berlin,
Germany and Portland, Oregon).  There must be some record on the
EWG wiki, but I don't think they are publically available.  Some
happen face-to-face over lunch or beer.


I notice that your name is on the n1968 paper. Do you know which of  
the proposals is likely to make it? I'd suspect the n1968 one. I  
personally prefer the syntax of n1958(?) but that requires a  
significant amount of lookahead I think.


Thanks!

Re: GCC Garbage Collection

[Basile STARYNKEVITCH]

Le Mon, Nov 13, 2006 at 06:47:40AM +, Brendon Costa écrivait/wrote:
> Hi All,
> 
>I think i am having trouble with the garbage collector deleting the 
> memory for tree nodes that i am still using.

The wiki page 
   http://gcc.gnu.org/wiki/Memory_management
might help you

I had a quick glance at your mail, so I may be wrong, but I am not sure that
you configured correctly the build system so that thet GTY(()) macros get
processed correctly. Sadly, the gengtype generator does not recieve the list
of files to process thru the command line, but only in internal data.

Regards

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 
email: basilestarynkevitchnet 
mobile: +33 6 8501 2359 
8, rue de la Faïencerie, 92340 Bourg La Reine, France