Goodbye

[FX]

As I explained in a lenghtier note to [EMAIL PROTECTED], lack of  
time and new projects mean I have to resign from my maintainership. I  
really want to thank all people outside the gfortran community who  
have been very kind and helpful, both by mail and on IRC. GCC is a  
great community to work in!



Committed as rev. 139507:

2008-08-23  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* MAINTAINERS: Move myself from Reviewers to Write after Approval.


Index: MAINTAINERS
===
--- MAINTAINERS (revision 139506)
+++ MAINTAINERS (working copy)
@@ -238,7 +238,6 @@
dataflowKenneth Zadeck  [EMAIL PROTECTED]
Fortran Janne Blomqvist [EMAIL PROTECTED]
Fortran Tobias Burnus   [EMAIL PROTECTED]
-FortranFran?ois-Xavier Coudert [EMAIL PROTECTED]
Fortran Jerry DeLisle   [EMAIL PROTECTED]
Fortran Erik Edelmann   [EMAIL PROTECTED]
Fortran Thomas Koenig   [EMAIL PROTECTED]
@@ -294,6 +293,7 @@
Josh Conner [EMAIL PROTECTED]
R. Kelley Cook  [EMAIL PROTECTED]
Christian Cornelssen[EMAIL PROTECTED]
+Fran?ois-Xavier Coudert[EMAIL PROTECTED]
Ian Dall[EMAIL PROTECTED]
David Daney [EMAIL PROTECTED]
Bud Davis   [EMAIL PROTECTED]

Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc

[Sebastian Redl]

Paolo Carlini wrote:

Paolo Carlini wrote:
I'm going to revert again the whole thing and wait for a different, 
safe, approach, sorry.
In the short time frame, i.e., something solid for 4.4.0, I would 
suggest two possible strategies:


1- Try to re-organize the new code in order to make possible using in 
*few* selected places _GLIBCXX_ATOMIC_BUILTINS_4 to enable / disable 
the new feature completely.
The necessary code changes for this are in the attached patch. Most of 
the code doesn't need to be touched, because the added code doesn't 
affect the non-exception_ptr case. The only thing that *needs* to change 
is that the reference counting is removed from __gxx_exception_cleanup. 
The reference count part of the __cxa_exception struct can stay - it's 
simply unused, except for the initialization in __cxa_throw.
Of course, that additional field and the initialization can be ifdefed 
out too, if you want.


The necessary configuration changes:
1) eh_ptr.cc must be excluded from compilation completely if the feature 
is unavailable.

2) The test cases must be excluded from the test runs.
3) It needs to be remembered whether propagation was included in the 
build. c++config needs to define _GLIBCXX_EXCEPTION_PTR_SUPPORTED on 
platforms where it was. The issue here is that I don't know if 
_GLIBCXX_ATOMIC_BUILTINS_4 keeps the value it had during the GCC build 
when client programs get compiled, and the client would get weird errors 
if it didn't. If it does, the new macro can simply be replaced.


I don't know how to do these configuration changes, so I couldn't 
actually test my patch yet.
2- Learn from guard.cc. In that libsupc++ implementation file, 
*certainly* atomic builtins are safely used, with fall-backs.
I'm afraid trying to learn something from that file is a futile exercise 
for me. It's a chaos of ifdefs that I simply don't understand. It seems 
to fall back to some global mutex for synchronization, which seems to be 
implemented entirely inline. (The mutex is part of libstdc++, so if it 
wasn't inline, you'd get the same link problems.)


Sebastian
Index: libsupc++/exception
===
--- libsupc++/exception (revision 139469)
+++ libsupc++/exception (working copy)
@@ -133,7 +133,8 @@
 
 #pragma GCC visibility pop
 
-#ifdef __GXX_EXPERIMENTAL_CXX0X__
+#if defined(__GXX_EXPERIMENTAL_CXX0X__) && \
+defined(_GLIBCXX_EXCEPTION_PTR_SUPPORTED)
 #include 
 #endif
 
Index: libsupc++/eh_throw.cc
===
--- libsupc++/eh_throw.cc   (revision 139469)
+++ libsupc++/eh_throw.cc   (working copy)
@@ -46,13 +46,17 @@
   if (code != _URC_FOREIGN_EXCEPTION_CAUGHT && code != _URC_NO_REASON)
 __terminate (header->terminateHandler);
 
+#ifdef _GLIBCXX_ATOMIC_BUILTINS_4
   if (__gnu_cxx::__exchange_and_add_dispatch (&header->referenceCount, -1) == 
0)
 {
+#endif
   if (header->exceptionDestructor)
 header->exceptionDestructor (header + 1);
 
   __cxa_free_exception (header + 1);
+#ifdef _GLIBCXX_ATOMIC_BUILTINS_4
 }
+#endif
 }
 
 
Index: libsupc++/eh_ptr.cc
===
--- libsupc++/eh_ptr.cc (revision 139469)
+++ libsupc++/eh_ptr.cc (working copy)
@@ -28,6 +28,10 @@
 // the GNU General Public License.
 
 #include 
+
+// Prevent exception_ptr.h from erroring out
+#define _GLIBCXX_EXCEPTION_PTR_SUPPORTED 1
+
 #include 
 #include 
 #include "unwind-cxx.h"
Index: libsupc++/exception_ptr.h
===
--- libsupc++/exception_ptr.h   (revision 139469)
+++ libsupc++/exception_ptr.h   (working copy)
@@ -38,6 +38,10 @@
 #ifndef __EXCEPTION_PTR_H__
 #define __EXCEPTION_PTR_H__
 
+#if !defined(_GLIBCXX_EXCEPTION_PTR_SUPPORTED)
+#error This platform does not support exception propagation.
+#endif
+
 #pragma GCC visibility push(default)
 
 #include 

Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc

[Paolo Carlini]

Hi,
1- Try to re-organize the new code in order to make possible using in 
*few* selected places _GLIBCXX_ATOMIC_BUILTINS_4 to enable / disable 
the new feature completely.
The necessary code changes for this are in the attached patch. Most of 
the code doesn't need to be touched, because the added code doesn't 
affect the non-exception_ptr case. The only thing that *needs* to 
change is that the reference counting is removed from 
__gxx_exception_cleanup. The reference count part of the 
__cxa_exception struct can stay - it's simply unused, except for the 
initialization in __cxa_throw.
Of course, that additional field and the initialization can be ifdefed 
out too, if you want.
Ok, great, seems a sane approach to me. On the positive side, we should 
also consider that each day more machines (certainly most the new ones 
in the server / desktop / notebook classes)  can use the new code.

The necessary configuration changes:
1) eh_ptr.cc must be excluded from compilation completely if the 
feature is unavailable.

2) The test cases must be excluded from the test runs.

Ok, I'll do this, it's rather straightforward.
3) It needs to be remembered whether propagation was included in the 
build. c++config needs to define _GLIBCXX_EXCEPTION_PTR_SUPPORTED on 
platforms where it was. The issue here is that I don't know if 
_GLIBCXX_ATOMIC_BUILTINS_4 keeps the value it had during the GCC build 
when client programs get compiled, and the client would get weird 
errors if it didn't. If it does, the new macro can simply be replaced.
Yes, no problem here too. In a first approximation, we can also avoid 
_GLIBCXX_EXCEPTION_PTR_SUPPORTED and just rely on 
_GLIBCXX_ATOMIC_BUILTINS_4. But if people would find that useful, we can 
at some point add code to acinclude.m4 to define at configure time 
_GLIBCXX_EXCEPTION_PTR_SUPPORTED consistently with the outcome for 
_GLIBCXX_ATOMIC_BUILTINS_4. Actually that strategy, defining at 
configure time fine-grained macros, one for each enabled / disabled 
C++0x feature which requires some sort of support not always available, 
seems a nice one in general, let's revisit the library about that in a 
few weeks, when we'll be feature complete for 4.4.0.


Paolo.

The Linux binutils 2.18.50.0.9 is released

[H.J. Lu]

This is the beta release of binutils 2.18.50.0.9 for Linux, which is
based on binutils 2008 0822 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 applied and
in what order they have been applied.

Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts

fnstsw %eax

fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use

fnstsw %ax

Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.

The new x86_64 assembler no longer accepts

monitor %eax,%ecx,%edx

You should use

monitor %rax,%ecx,%edx

or
monitor

which works with both old and new x86_64 assemblers. They should
generate the same opcode.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

movl (%eax),%ds
movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

mov (%eax),%ds
mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support

movw (%eax),%ds
movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

Please report any bugs related to binutils 2.18.50.0.9 to
[EMAIL PROTECTED]

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.18.50.0.8:

1. Update from binutils 2008 0822.
2. Add Intel AES+AVX support.
3. Add syscall and sysret for Cpu64 in x86 assembler.
4. Fix i386/x86-64 TLS 2 support.
5. Disable gas generated debug info when compiler generates it.  PR
gas/6656.
6. Fix an assembler .set bug.  PR 6848.
7. Remove 2MB section gap from linker output.  PR ld/6833.
8. Fix stab warnings caused linker errors.  PR 6478.
9. Remove AVX registers from DWARF register map.
10. Fix linking Linux .o against FreeBSD .so.  PR 4424.
11. Fix objcopy --extract-symbol.  PR 6774.
12. Improve gold.
13. Improve mips GOT and non-PIC support.
14. Fix various arms bugs.
15. Fix various bfin bugs.
16. Fix various frv bugs.
17. Fix various h8300 bugs.
18. Fix various ppc bugs.
19. Fix various spu bugs.
20. Fix various xtensa bugs.

Changes from binutils 2.18.50.0.7:

1. Update from binutils 2008 0709.
2. Allow vmovd with 64bit operand in x86 assembler.
3. Improve -msse-check in x86 assembler.
4. Fix an AVX assembler bug in Intel syntax.  PR 6517.
5. Improve error message in Intel syntax for x86 assembler.  PR 6518.
6. Add the ".sse_check" directive to x86 assembler.
7. Improve gold.
8. Improve objcopy/strip.  PR 2995/6473.
9. Improve objdump -g.  PR 6483.
10. Improve ld --sort-common.  PR 6430.
11. Add multi-GOT support for m68k.
12. Fix various arm bugs.
13. Fix various avr bugs.
14. Fix various hppa bugs.
15. Fix various m68k bugs.
16. Fix various mips bugs.
17. Fix various mmix bugs.
18. Fix various ppc bugs.
19. Fix various spu bugs.
20. Fix various xtensa bugs.

Changes from binutils 2.18.50.0.6:

1. Update from binutils 2008 0502.
2. Add Intel EPT and MOVBE support.
3. Correct Intel FMA operand order.
4. Change Intel CLMUL to Intel PCLMUL.
5. Add -msse-check to x86 assembler to warn SSE instruction where
there is AVX equivalent.
6. Provide backward compatibility for ELF object files with more
than 64K sections generated by the older binutils.  PR 6412.
7. Improve FDPIC support.
8. Add -wL switch to readelf to dump decoded contents of .debug_line.
9. Add -ag switch to assembler show general information in listings.
10

Re: Please, do not use the merged revisions log as the commit message when merging

[Gerald Pfeifer]

On Sun, 17 Aug 2008, Ralf Wildenhues wrote:
> It should be on svnwrite.html

Something like the following?  (Not committed yet.)

Gerald

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.15
diff -u -3 -p -r1.15 svnwrite.html
--- svnwrite.html   19 Jan 2007 21:04:10 -  1.15
+++ svnwrite.html   23 Aug 2008 19:16:32 -
@@ -28,7 +28,7 @@ www documents is still done using Testing changes
   Checking in a change
   Example check-in session
-  Creating branches
+  Creating and using branches
 
 
 
@@ -384,7 +384,7 @@ Committed revision 105933.
 And that's it!
 
 
-Creating branches
+Creating and using branches
 
 To create a branch for development, simply copy the trunk directory
 to a directory in /branches as follows:
@@ -398,5 +398,9 @@ svn cp svn+ssh://username@gcc.gnu
 svn.html#devbranches.
 
 
+When merging changes from mainline (or another branch) to a branch,
+do not copy the entire set of ChangeLog entries.  Just use something
+like "Merge from mainline" or similar.
+
 
 

Re: How to use gcc source and try new optmization techniques

[Rohan Sreeram]

Matt and Pranav,

That's right. I wanted to understand the CFG and optimization inside gcc.
>From what I see I will have to get a grip on the GCC architecture before I can 
>start experimentation.

That would include basic blocks, CFG, and other loop optmization code in there.

Thanks,
Rohan

- Original Message 
From: Matthew <[EMAIL PROTECTED]>
To: Rohan Sreeram <[EMAIL PROTECTED]>
Sent: Wednesday, August 20, 2008 10:30:07 PM
Subject: Re: How to use gcc source and try new optmization techniques

I'm in a similar position, but some pointers.

> 1) Understand the control flow graphs being generated by GCC, which I could 
> build using the -fdump-tree-cfg option.

Look very closely at the basic blocks and the loop optimizers.
basic-block.h, cfg*.[h|c]
- in the basic blocks, the fields "succs" and "preds" will be of large
importance to you. As near as I can tell the CFG is built as part of
the basic blocks themselves.

> 2) Write code that could convert CFG to a different graph.
> 3) Use this new graph for optimization.
> 4) Use the optimized graph to generate machine code (say Intel architecture 
> for now).

So long as your transformation can be expressed in GCC's IR, then code
gen should be taken care of by back ends. Of course, bad transform
means bad code.

>
> Please let me know how I could leverage the GCC code for this purpose, and if 
> you any suggestions/comments for me you are most welcome ! :)
>
> Thanks,
> Rohan

The GCC internals documents will be important, however they are not
perfect (especially if you choose to develop on the trunk). The GCC
wiki in certain areas is far stronger than the internals document,
however in others is far weaker. The GCC IRC channel on oftc.net is
helpful for very specific questions, and is good to get a feel for the
community.

I'd be really interested in hearing your experience with GCC after
you've worked in it for a while, seeing how it matches up with my own.
-- 
Matt G.


  

Re: How to use gcc source and try new optmization techniques

[Rohan Sreeram]

Thanks Seema. The data flow analysis plugin is really interesting work.

I will take a look at the links given by you.

Rohan.

- Original Message 
From: Seema Ravandale <[EMAIL PROTECTED]>
To: Rohan Sreeram <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 11:35:10 PM
Subject: Re: How to use gcc source and try new optmization techniques

Hi Rohan,

I have already worked on cfg data structure, plugin "data flow pass" on cfg.
For this purpose, following links would be useful.

http://www.cse.iitb.ac.in/~uday/gcc-workshop/?file=downloads

more info can be available at

http://www.cse.iitb.ac.in/grc/

- Seema

On Thu, Aug 21, 2008 at 6:51 AM, Pranav Bhandarkar
<[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I may not have correctly understood your questions but from what I
> understand I think you mean to ask how you could easily plug in your
> optimization pass into GCC so as to test your implementation of some
> optimization.
>
> Well, the way to do that would be to understand the pass structure and
> decide where in the order of passes should your pass be inserted i.e
> after which and before which other pass should your optimization pass
> fit in. Look at passes.c to see how the order of passes is specified.
>
> Once you have told the compiler when to execute your pass (primarily
> through passes.c) and provided your optimization has been correctly
> implemented in the context of GCC you should be good to go.
>
> HTH,
> Pranav
>
> On Wed, Aug 20, 2008 at 7:45 PM, Rohan Sreeram <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am a student in Utah State University researching on compilers 
> > optimization techniques.
> > I wanted to know how I could use gcc for experimenting with optimization.
> >
> > Here is what I intend to do:
> >
> > 1) Understand the control flow graphs being generated by GCC, which I could 
> > build using the -fdump-tree-cfg option.
> > 2) Write code that could convert CFG to a different graph.
> > 3) Use this new graph for optimization.
> > 4) Use the optimized graph to generate machine code (say Intel architecture 
> > for now).
> >
> > Please let me know how I could leverage the GCC code for this purpose, and 
> > if you any suggestions/comments for me you are most welcome ! :)
> >
> > Thanks,
> > Rohan
> >
> >
> >
> >
> >


  

Re: How to use gcc source and try new optmization techniques

[Rohan Sreeram]

Thanks Manuel.

I plan to study GCC internals and acquaint myself with the different 
optimization techniques.
As Matt mentioned I would need to use material from both the wiki and internals 
for this.

Rohan

- Original Message 
From: Manuel López-Ibáñez <[EMAIL PROTECTED]>
To: Seema Ravandale <[EMAIL PROTECTED]>
Cc: Rohan Sreeram <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 4:17:12 AM
Subject: Re: How to use gcc source and try new optmization techniques

Rohan,

Welcome to GCC and I hope you achieve what you want. I would recommend
you check our wiki:

http://gcc.gnu.org/wiki

which has some very useful links:

http://gcc.gnu.org/wiki/GettingStarted

It is a wiki, so feel free to correct mistakes, improve stuff and add
links. If you want to create a page for your project, please do so.

Seema, I see a link to the workshop but not a link to the GCC resource
center you linked. Would you like adding one under "Tutorials,
HOWTOs".

Cheers,

Manuel.


2008/8/21 Seema Ravandale <[EMAIL PROTECTED]>:
> Hi Rohan,
>
> I have already worked on cfg data structure, plugin "data flow pass" on cfg.
> For this purpose, following links would be useful.
>
> http://www.cse.iitb.ac.in/~uday/gcc-workshop/?file=downloads
>
> more info can be available at
>
> http://www.cse.iitb.ac.in/grc/
>
> - Seema
>
> On Thu, Aug 21, 2008 at 6:51 AM, Pranav Bhandarkar
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I may not have correctly understood your questions but from what I
>> understand I think you mean to ask how you could easily plug in your
>> optimization pass into GCC so as to test your implementation of some
>> optimization.
>>
>> Well, the way to do that would be to understand the pass structure and
>> decide where in the order of passes should your pass be inserted i.e
>> after which and before which other pass should your optimization pass
>> fit in. Look at passes.c to see how the order of passes is specified.
>>
>> Once you have told the compiler when to execute your pass (primarily
>> through passes.c) and provided your optimization has been correctly
>> implemented in the context of GCC you should be good to go.
>>
>> HTH,
>> Pranav
>>
>> On Wed, Aug 20, 2008 at 7:45 PM, Rohan Sreeram <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > I am a student in Utah State University researching on compilers 
>> > optimization techniques.
>> > I wanted to know how I could use gcc for experimenting with optimization.
>> >
>> > Here is what I intend to do:
>> >
>> > 1) Understand the control flow graphs being generated by GCC, which I 
>> > could build using the -fdump-tree-cfg option.
>> > 2) Write code that could convert CFG to a different graph.
>> > 3) Use this new graph for optimization.
>> > 4) Use the optimized graph to generate machine code (say Intel 
>> > architecture for now).
>> >
>> > Please let me know how I could leverage the GCC code for this purpose, and 
>> > if you any suggestions/comments for me you are most welcome ! :)
>> >
>> > Thanks,
>> > Rohan
>> >
>> >
>> >
>> >
>> >
>

GCC for win32 platform

[Tayeb Meftah]

hello for all GCC Users
please do you know any GCC compiler for win32 platform (excepte for the MinGW 
project and cigwin) ?
thanks
_
Téléchargez le nouveau Windows Live Messenger !
http://get.live.com/messenger/overview

c++0x 4.4, =default definition outside template class fails.

[Simon Hill]

I've just installed g++ 4.4 and I'm playing with some of the c++0x features.

The below page describes the =default and =delete syntax. (Used to
manipulate the special member functions default/copy constructor,
destructor and copy assign).
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm

I've managed to get parts of my code working, but it seems that
defining as default a template class's special member functions
outside the class definition doesn't work.
I'm not really sure if it should, but looking at the suggested
modifications to the spec [8.4 paragraph 7] (in the above document), I
_think_ it's saying that it should work.

The problem is that the compiler fails to generate the function
(foo::~foo() in the following code), which causes the linker to
report an undefined reference.

I didn't post this as a bug report as I'm not 100% sure it is a bug.


=== THIS CODE FAILS TO COMPILE ===
template 
class foo {
  public:
foo() =default; // <<--- this works fine.
~foo();
};

template 
foo::~foo() =default; <<--- ERROR: This doesn't get built by the compiler.
// foo::~foo() {}; <<-- replacing with this line fixes the error.

int main() {

foo fi;

return 0;
}
===


=== THIS CODE COMPILES ===
class foo {
  public:
foo() =default;
~foo();
};

foo::~foo() =default;

int main() {

foo fi;
return 0;

}
===

NOTE: The reason I noticed this was that I was trying to default a
virtual destructor.
This should work, but I'm guessing that it must be done outside the
function definition, because it doesn't work inside.
However, if the above is a bug, this may also be a bug.