headers
gccadmin | 21 Nov 23:49
Favicon

gcc-4.4-20081121 is now available

Snapshot gcc-4.4-20081121 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081121/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 142103

You'll find:

gcc-4.4-20081121.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.4-20081121.tar.bz2         C front end and core compiler

gcc-ada-4.4-20081121.tar.bz2          Ada front end and runtime

gcc-fortran-4.4-20081121.tar.bz2      Fortran front end and runtime

gcc-g++-4.4-20081121.tar.bz2          C++ front end and runtime

gcc-java-4.4-20081121.tar.bz2         Java front end and runtime

gcc-objc-4.4-20081121.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.4-20081121.tar.bz2    The GCC testsuite

Diffs from 4.4-20081114 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 21 Nov 20:23
Favicon

Re: Restrict implementation considered harmful

Michael Matz <matz <at> suse.de> writes:

>> This program appears to me to be invalid according to C99 6.7.3.1,
>> which is the only definition of restrict that we have.
>> 
>>     If P is assigned the value of a pointer expression E that is based
>>     on another restricted pointer object P2, associated with block B2,
>>     then either the execution of B2 shall begin before the execution
>>     of B, or the execution of B2 shall end prior to the assignment.
>>     If these requirements are not met, then the behavior is undefined.
>> 
>> In your program, P is q and P2 is p.  Block B and B2 are the same
>> block: the only block in foo.  It is obviously not the case that the
>> block executes before itself.  So I believe the assignment "q = p + 1"
>> is undefined behaviour.
>
> But the testcases in the PR can easily be transformed to fulfill this 
> requirement.  E.g.:
>
> int __attribute__((noinline))
> foo (int *__restrict p, int i)
> {
>   if (1)
>     {
>       int *__restrict q = p + 1;
>       if (1)
>         {
>           int *__restrict r = q - i;
>           int v, w;
>           v = *r;
(Continue reading)

Permalink | Reply | 0 comments |
headers
IainS | 21 Nov 16:55

__Unwind_GetIPInfo on Darwin 8.11

hi,

a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
However, I'm finding a huge number of failures with g++ caused by the  
fact that  __Unwind_GetIPInfo is not defined.

When 'make checking', I conventionally move the built libgcc_s. 
1.dylib and libgcc_s.10.4.dylib to one side prior to testing (so that  
the Apple-supplied system version is used).

__Unwind_GetIPInfo is not present in the stock:
  /usr/lib/libgcc_s.1.dylib or /Developer/SDKs/MacOSX10.4u.sdk/usr/ 
lib/libgcc_s.1.dylib

[the symbol IS present in libgcc_s.1.dylib built from trunk]

---
Is this the expected behavior?  (there doesn't appear to be an update  
to the library version).

If so - I guess that anyone building with 4.4 would have to supply an  
updated libgcc ???

cheers,
Iain
Permalink | Reply | 0 comments |
headers
Diego Novillo | 21 Nov 12:37
Favicon
Gravatar

Re: [RFC] Remove -frtl-abstract-sequences in 4.5

On Thu, Nov 20, 2008 at 21:19, Weddington, Eric
<eweddington <at> cso.atmel.com> wrote:

> Are you also proposing to do the re-implementation as you describe above (as a gimple pass, in IPA mode)?

Not necessarily, but it's a possibility.  Initially I'm more
interested in removing code that is not useful and apparently not
widely used.  Proposing its removal is a good way of measuring
interest.

Diego.
Permalink | Reply | 0 comments |
headers
Richard Guenther | 21 Nov 12:18
Favicon

Restrict implementation considered harmful


With looking at PRs 37742 and 37955 I reminded myself of our broken
restrict implementation which tries to model restrict semantics
within our type-based alias set framework.  The implementation
heavily relies on correct tracking of restrict bases
(DECL_BASED_ON_RESTRICT_P/DECL_GET_RESTRICT_BASE) - but this
is completely bogus even for trivial testcases like

int foo (int *__restrict p)
{
  int *__restrict q;
  int v;
  q = p + 1;
  q = q - 1;
  v = *q;
  *p = 1;
  return v + *q;
}
extern void abort (void);
int main()
{
  int i = 0;
  if (foo (&i) != 1)
    abort ();
  return 0;
}

where q is not set to be based on p (and in general with SSA form
its impossible to properly track this as the information is per
decl, not per SSA nae).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rodolfo Lima | 21 Nov 12:05

C++0x Concepts development schedule

Hi, I wonder if there's any kind schedule available on the development
Concepts proposal into GCC. I know there's a related branch in svn, but
it seems stale as of 11/2008.

Please don't take this as a pressure to get things going. I just want to
know the time frame it will be ready, I'm sort of excited because of the
possibilities it unleashes. I'd really like to help on this task, but I
never worked on GCC internals, and helping implement concepts for it
isn't the best or more efficient way to start :)

Best regards and thanks for the awesome compiler you guys put out,
Rodolfo Lima
Permalink | Reply | 1 comment |
headers
Joel Porquet | 21 Nov 11:19

Fwd: Mips, -fpie and TLS management

2008/11/20 Daniel Jacobowitz <drow <at> false.org>:
> On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
>> Gcc is using local-exec tls model instead of global-dynamic. The
>> option -fpie is supposed to act as -fpic though (dixit the manual).
>> Here is the first problem...
>
> Could you explain the problem with this?  The choice of local-exec vs
> global-dynamic does not affect whether code is position independent.

I agree that wether the code is pic or not and the tls model are quite
independent.
According to the manual, the default policy for TLS is affected by the
pic model though:

-ftls-model=model
...
          The default without -fpic is "initial-exec"; with -fpic the
default is "global-dynamic".

> It's a difference between linking an executable versus linking a
> shared library; this is one of the distinctions between -fpie and
> -fpic.

Yes for the linking stage but for the object compilation, -fpie should
be almost the same.

>> But then readelf tells me:
>>
>> Relocation section '.rel.dyn' at offset 0x3d4 contains 2 entries:
>>  Offset     Info    Type            Sym.Value  Sym. Name
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timo Kreuzer | 21 Nov 02:25

Problem with x64 SEH macro implementation for ReactOS

Hi,

First sorry for crossposting, but someone said I should post here, so
here we go:

I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
codes to mark the code positions where the try block starts / ends and
of the except landing pad. The emitted .eh_frame section is parsed after
linking and converted into Windows compatible unwind info / scope tables.
This works quite well so far.

Now the problem: The exception filter and the finally clause are being
created as nested functions. Now I need to know (in the parsing step
after linking) the addresses of these functions and that they belong to
the corresponding try / except statement. Best would be emitting the
address of the nested function as .cfi_escape, but that doesn't really
work. 1) .cfi_escape only takes bytes, not rvas and 2) the C compiler
doesn't want to give me the address of the nested function at compile time.

I ended up with a dirty hack, referencing the "parent code" from the
inline function with a lea opcode:

{
    __label__ label1;
label1:
    asm volatile (".cfi_escape 0x50, 0x01\n");
    int nested_function()
    {
        asm volatile ("lea %0, %%eax" : : "m"(*(volatile
int*)(&&label1)) : "eax" )
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.J. Lu | 20 Nov 17:33

Re: benchmarking

On Thu, Nov 20, 2008 at 7:44 AM, Marco Correia
<marco.v.correia <at> gmail.com> wrote:
> hi,
>
> I noticed that a number of benchmarks I use to run to test my library run
> about 10% slower with gcc-4.3.1 compared to gcc-4.2.3. Would someone here be
> interested on more details, or is this normal ?
>

See

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

--

-- 
H.J.
Permalink | Reply | 0 comments |
headers
Joel Porquet | 20 Nov 17:27

Mips, -fpie and TLS management

Hi,

I'm trying to compile a Position Independent Executable with a TLS but
gcc doesn't generate the expected code (at least, what i expect).
Here's an example:

__thread int test_loc;

void func()
{
    test_loc = 2;
}

I compile the object with:

CFLAGS=-nostdinc -nostdlib -fno-builtin \
           -Wall \
           -fomit-frame-pointer \
           -mips2 -EL -mno-branch-likely \
           -mabicalls \
           -G0 \
           -Os

CPIE=-fpie

app.o: app.c
        mipsel-unknown-elf-gcc $(CPIE) -c -o app.o app.c $(CFLAGS)

Then the generated code is:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Samuel Tardieu | 20 Nov 17:26
Favicon
Gravatar

Re: ada.h _ECHO

>>>>> "andrew" == andrew m goth <andrew.m.goth <at> l-3com.com> writes:

andrew> For the non-__STDC__ case, why is the macro called _ECHO on
andrew> one line and ECHO on the next?

Given that GNAT can only be compiled with GNAT, I bet the non __STDC__
case has not been exercized for years and can simply be removed.

  Sam
--

-- 
Samuel Tardieu -- sam <at> rfc1149.net -- http://www.rfc1149.net/
Permalink | Reply | 0 comments |

Gmane