Re: [RFC PATCH, i386]: Allow zero_extended addresses (+ problems with reload and offsetable address, "o" constraint)

2011-08-09 Thread Uros Bizjak 
On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak  wrote:

>> Moves are special as far as reload is concerned.  If there is already
>> a move instruction present *before* reload, it will get fixed up
>> according to its constraints as any other instruction.
>>
>> However, reload will *introduce* new moves as part of its operation,
>> and those will *not* themselves get reloaded.  Instead, reload simply
>> assumes that every plain move will just succeed without requiring
>> any reload; if this is not true, the target *must* provide a
>> secondary reload for this move.
>>
>> (Note that the secondary reload could also work by reloading the
>> target address into a temporary; that's up to the target to
>> implement.)
>
> Whoa, indeed.
>
> Using attached patch that reloads memory address instead of going
> through XMM register, the code for the testcase improves from:

Committed to mainline with following ChangeLog entry:

2011-08-09  Uros Bizjak  

PR target/49781
* config/i386/i386.md (reload_noff_load): New.
(reload_noff_store): Ditto.
* config/i386/i386.c (ix86_secondary_reload): Use
CODE_FOR_reload_noff_load and CODE_FOR_reload_noff_store to handle
double-word moves from/to non-offsetable addresses instead of
generating XMM temporary.

Re-bootstrapped and re-tested on x86_64-pc-linux-gnu {,-m32}.

Uros.

Re: Question about SMS scheduling windows

2011-08-09 Thread Richard Sandiford 
Ayal Zaks  writes:
>> (FWIW, libav did show up extra differences when using the patch
>> that I'd originally submitted.  They were due to the count_preds
>> and count_succs thing that you picked up in your review.)
>
>
> (These differences had no noticable consequences performance-wise, right?)

Well, because they were unintentional, I'm afraid I didn't measure them.
The committed version didn't have these differences.  (It was an assembly
source comparison, so I don't have a ready way of measuring the performance
of each affected loop.)

Richard

[pph] Merge from trunk rev 177573.

2011-08-09 Thread Diego Novillo 
This merge brings in Gab's trunk changes to line_map and my
refactoring of the streaming code.  It also allows us to
use C++ for the implementation (with the same caveats we have in
trunk, the code must be ifdef'd to build with both C and C++
compilers).

I will continue the next phase of the streaming refactoring in
branch.  This way, I will have a better idea of what hooks we
need and what hooks can go.  Once I have the separate cache
implemented, I will forward port the next stage of the
refactoring to trunk.

Tested on x86_64.


Diego.

Re: FDO and LTO on ARM

2011-08-09 Thread Mike Hommey 
On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
> On 8 August 2011 13:20, Mike Hommey wrote:
> >
> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> > One is bug 50022 that I filed today.
> >
> > Another is the following error in stlport headers:
> >  error: invalid use of incomplete type 'std::string {aka struct
> >  std::basic_string, std::allocator >}'
> >
> > I also tried GNU libstdc++ instead of stlport but I hit some other
> > errors that boil down to the following:
> >  error: 'std::wstring' has not been declared
> 
> They both look as though they could be caused by something as simple
> as failing to include  rather than a problem in GCC.  Could
> you send me more context for the errors (offlist if you prefer)?  I'll
> see if it's something we've changed in libstdc++, though given that
> STlport fails too it seems unlikely.

I identified the libstdc++ failure as a problem when building gcc:

configure:16321:  /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc -shared-libgcc 
-B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++ 
-L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/src 
-L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/src/.libs 
-B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/bin/
 
-B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/lib/
 -isystem 
/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/include
 -isystem 
/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/sys-include
-c -frtti -fexceptions -O2 -Os -g -DTARGET_POSIX_IO -fno-short-enums  
conftest.cpp >&5
conftest.cpp:35:18: error: 'INT_MIN' was not declared in this scope
conftest.cpp:36:18: error: 'INT_MAX' was not declared in this scope
(snip)
configure:16345: checking for enabled wchar_t specializations
configure:16347: result: no

Thus _GLIBCXX_USE_WCHAR_T is not defined, and as such, the typedef
for wstring isn't either.

I'll retry stlport and see if it's not something similar.

Mike

Re: FDO and LTO on ARM

2011-08-09 Thread Jonathan Wakely 
On 9 August 2011 13:57, Mike Hommey wrote:
> On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
>> On 8 August 2011 13:20, Mike Hommey wrote:
>> >
>> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
>> > One is bug 50022 that I filed today.
>> >
>> > Another is the following error in stlport headers:
>> >  error: invalid use of incomplete type 'std::string {aka struct
>> >  std::basic_string, std::allocator >}'
>> >
>> > I also tried GNU libstdc++ instead of stlport but I hit some other
>> > errors that boil down to the following:
>> >  error: 'std::wstring' has not been declared
>>
>> They both look as though they could be caused by something as simple
>> as failing to include  rather than a problem in GCC.  Could
>> you send me more context for the errors (offlist if you prefer)?  I'll
>> see if it's something we've changed in libstdc++, though given that
>> STlport fails too it seems unlikely.
>
> I identified the libstdc++ failure as a problem when building gcc:
>
> configure:16321:  /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc -shared-libgcc 
> -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++ 
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/src 
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/src/.libs 
> -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/bin/
>  
> -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/lib/
>  -isystem 
> /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/include
>  -isystem 
> /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/arm-linux-androideabi/sys-include
>     -c -frtti -fexceptions -O2 -Os -g -DTARGET_POSIX_IO -fno-short-enums  
> conftest.cpp >&5
> conftest.cpp:35:18: error: 'INT_MIN' was not declared in this scope
> conftest.cpp:36:18: error: 'INT_MAX' was not declared in this scope
> (snip)
> configure:16345: checking for enabled wchar_t specializations
> configure:16347: result: no
>
> Thus _GLIBCXX_USE_WCHAR_T is not defined, and as such, the typedef
> for wstring isn't either.

Ah ok - that happens when the C library doesn't provide all the
required wchar_t functions, fwprintf, mbrtowc etc.

Re: PING: PATCH: Use int64 for x86 options

2011-08-09 Thread H.J. Lu 
Is this OK for trunk?

On Sun, Aug 7, 2011 at 7:18 PM, H.J. Lu  wrote:
> On Sat, Aug 6, 2011 at 9:05 AM, H.J. Lu  wrote:
>> Ping.  AVX2 support depends on this patch.
>>
>
>>> ---
>>> 2011-08-04  H.J. Lu  
>>>            Igor Zamyatin 
>>>
>>>        * hwint.h (HOST_WIDE_INT_1): New.
>>>
>>>        * opt-functions.awk (switch_bit_fields): Initialize the
>>>        host_wide_int field.
>>>        (host_wide_int_var_name): New.
>>>        (var_type_struct): Check and return HOST_WIDE_INT.
>>>
>>>        * opt-read.awk: Handle HOST_WIDE_INT for "Variable".
>>>
>>>        * optc-save-gen.awk: Support HOST_WIDE_INT on var_target_other.
>>>
>>>        * opth-gen.awk: Use HOST_WIDE_INT_1 on HOST_WIDE_INT.  Properly
>>>        check masks for HOST_WIDE_INT.
>>>
>>>        * opts-common.c (set_option): Support HOST_WIDE_INT Flag_var.
>>>
>>>        * opts.h (cl_option): Add cl_host_wide_int.  Change var_value
>>>        to HOST_WIDE_INT.
>>>
>>>        * config/i386/i386-c.c (ix86_target_macros_internal): Replace int
>>>        with HOST_WIDE_INT for isa_flag.
>>>        (ix86_pragma_target_parse): Replace int with HOST_WIDE_INT for
>>>        isa variables.
>>>
>>>        * config/i386/i386.c (ix86_target_string): Replace int with
>>>        HOST_WIDE_INT for isa.  Use HOST_WIDE_INT_PRINT to print isa.
>>>        (ix86_target_opts): Replace int with HOST_WIDE_INT on mask.
>>>        (pta_flags): Removed.
>>>        (PTA_XXX): Redefined as (HOST_WIDE_INT_1 << X).
>>>        (pta): Use HOST_WIDE_INT on flags.
>>>        (builtin_isa): Use HOST_WIDE_INT on isa.
>>>        (ix86_add_new_builtins): Likewise.
>>>        (def_builtin): Use HOST_WIDE_INT on mask.
>>>        (def_builtin_const): Likewise.
>>>        (builtin_description): Likewise.
>>>
>>>        * config/i386/i386.opt (ix86_isa_flags): Replace int with
>>>        HOST_WIDE_INT.
>>>        (ix86_isa_flags_explicit): Likewise.
>>>        (x_ix86_isa_flags_explicit): Likewise.
>>>
>>
>>
>>
>> --
>> H.J.
>>
>
> HOST_BITS_PER_WIDE_INT isn't defined in target library.
> I need to check if HOST_BITS_PER_WIDE_INT is defined
> first.  Here is the updated patch.
>
>
>
> --
> H.J.
>



-- 
H.J.

Re: PING: PATCH: Use int64 for x86 options

2011-08-09 Thread Joseph S. Myers 
On Tue, 9 Aug 2011, H.J. Lu wrote:

> Is this OK for trunk?

No.  You don't need to ping so often; I'll look at it in due course once 
sufficient time has passed since the last posted revision (if a patch 
keeps getting new versions posted, I consider that evidence that I should 
wait a while before considering reviewing it because it's likely still to 
be unstable).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: PING: PATCH: Use int64 for x86 options

2011-08-09 Thread H.J. Lu 
On Tue, Aug 9, 2011 at 7:06 AM, Joseph S. Myers  wrote:
> On Tue, 9 Aug 2011, H.J. Lu wrote:
>
>> Is this OK for trunk?
>
> No.  You don't need to ping so often; I'll look at it in due course once
> sufficient time has passed since the last posted revision (if a patch
> keeps getting new versions posted, I consider that evidence that I should
> wait a while before considering reviewing it because it's likely still to
> be unstable).
>

Thanks.

-- 
H.J.

Re: [named address] rejects-valid: error: initializer element is not computable@load time

2011-08-09 Thread Ulrich Weigand 
Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > It's not a restriction so much, it's simply that TR 18037 does not say 
> > anything
> > about string literals at all, so they keep working as they do in standard C.
> 
> Take the following bit more elaborate example where you want to describe 
> a menu:
[snip]
> Thus you have no alternative and have to use menu1_t:
> 
> const char __as STR_YES[] = "Yes";
> const char __as STR_NO[]  = "No";
> const char __as STR_DUNNO[] = "Don't really know and will decide later";
> 
> const menu1_t menu3 =
> {
>  1,
>  {
>  STR_YES,
>  STR_NO,
>  STR_DUNNO
>  }
> };
> 
> With some menues you soon end up with dozens of unnecessary variables 
> just because TR 18037 has a blank area on it's map.

I agree that this is best approach.  You can even avoid the unnecessary
variables by using a compound literal with AS-qualified char array type,
and initialize the AS pointer to its address, like e.g. so:

const __as char *pallo = (const __as char []){"pallo"};

That's still a bit awkward, but that could be hidden via a macro ...

> This means that a line like
> const __as char * pallo = "pallo";
> can be very useful and that there is exactly one meaning that makes 
> sense: put "pallo" in __as because otherwise you won't be able to 
> reference that string.

That's not really true: on some targets, the generic address space
will indeed be a subset of __as, so you *can* assign the address of
a string literal in the generic space to an __as pointer variable.

Even on the SPU, this works when the assignment is not done at
initialization time:

const __ea char *p;
int test (void)
{
  p = "test";
}

This will generate code to convert the address of the literal "test"
in the generic address space into a __ea address and assign it to
the __ea pointer.

> Even more preferred would be to assign the only sensible meaning 
> (provided a target allows it), which should be legal as that extension 
> is implementation defined, anyway.

What is implementation defined is whether conversion of a pointer
to a different address space is allowed at *initialization* time
or not.

What is *not* implementation defined is that string literals are
always in the generic address space -- that's simply a requirement
of the standard.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [RFC PATCH, i386]: Allow zero_extended addresses (+ problems with reload and offsetable address, "o" constraint)

2011-08-09 Thread H.J. Lu 
On Tue, Aug 9, 2011 at 12:40 AM, Uros Bizjak  wrote:
> On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak  wrote:
>
>>> Moves are special as far as reload is concerned.  If there is already
>>> a move instruction present *before* reload, it will get fixed up
>>> according to its constraints as any other instruction.
>>>
>>> However, reload will *introduce* new moves as part of its operation,
>>> and those will *not* themselves get reloaded.  Instead, reload simply
>>> assumes that every plain move will just succeed without requiring
>>> any reload; if this is not true, the target *must* provide a
>>> secondary reload for this move.
>>>
>>> (Note that the secondary reload could also work by reloading the
>>> target address into a temporary; that's up to the target to
>>> implement.)
>>
>> Whoa, indeed.
>>
>> Using attached patch that reloads memory address instead of going
>> through XMM register, the code for the testcase improves from:
>
> Committed to mainline with following ChangeLog entry:
>
> 2011-08-09  Uros Bizjak  
>
>        PR target/49781
>        * config/i386/i386.md (reload_noff_load): New.
>        (reload_noff_store): Ditto.
>        * config/i386/i386.c (ix86_secondary_reload): Use
>        CODE_FOR_reload_noff_load and CODE_FOR_reload_noff_store to handle
>        double-word moves from/to non-offsetable addresses instead of
>        generating XMM temporary.
>
> Re-bootstrapped and re-tested on x86_64-pc-linux-gnu {,-m32}.
>

No regressions on x32 with GCC, glibc and SPEC CPU 2K/2006.

Thanks.

-- 
H.J.

Re: libgcc: strange optimization

2011-08-09 Thread Richard Earnshaw 
On 02/08/11 13:22, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson  wrote:
>> Michael Walle writes:
>>  >
>>  > Hi,
>>  >
>>  > > To confirm that try -fno-tree-ter.
>>  >
>>  > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>>  > assembly code:
>>  >
>>  > f2:
>>  >  addi sp, sp, -4
>>  >  sw   (sp+4), ra
>>  >  addi r2, r0, 10
>>  >  calli__ashrsi3
>>  >  addi r8, r0, 10
>>  >  scall
>>  >  lw   ra, (sp+4)
>>  >  addi sp, sp, 4
>>  >  bra
>>
>> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
> 
> It's of course only a workaround, not a real fix as nothing prevents
> other optimizers from performing the re-scheduling TER does.
> 
> I suggest to amend the documentation for local call-clobbered register
> variables to say that the only valid sequence using them is from a
> non-inlinable function that contains only direct initializations of the
> register variables from constants or parameters.
> 
> Or go one step further and deprecate local register variables alltogether
> (they IMHO don't make much sense, and rather the targets should provide
> a way to properly constrain asm inputs and outputs).
> 
> Richard.
> 
> 

Better still would be to change the specification and implementation of
local register variables to only guarantee them at the beginning of ASM
statements.  At other times they are simply the same as other local
variables.  Now we have a problem that the register allocator knows how
to solve.

In other words, if the user writes

bar (int y)
{
  register int x asm ("r0") = y;

  foo()

  asm volatile ("mov r1, r0");

}

The compiler will generate
(set (reg:SI 999 ) (reg:SI ))
(call "foo")
(set (reg:SI 0 "r0") (reg:SI 999 ))
(asm "mov r1, r0")
(set (reg:SI 999 ) (reg:SI 0 "r0"))

That is, it inserts appropriate set insns around asm blocks.  Of course,
the register allocator can try to allocate reg 999 to r0 and if it
succeeds, then the sets become dead.  But if it fails then at least the
code will continue to execute as intended.

R.

Re: [named address] ice-on-valid: in postreload.c:reload_cse_simplify_operands

2011-08-09 Thread Ulrich Weigand 
Georg-Johann Lay wrote:

> Thanks, it works.

OK, thanks for testing!

>   std Y+2,r31  ;  30  *movphi/3   [length = 7]
>   std Y+1,r30

I'm actually not seeing those (maybe I'm using a different code
base than you were using ...)

But I still see that the frame is created.  The problem is that IRA
thinks it needs to allocate a pseudo on the stack, and creates a
stack slot for it.  But then reload goes and just reloads the
pseudo into a hard register anyway, and simply doesn't need the
stack slot ... but it was already allocated and accounted for
such that get_frame_size () no longer returns 0.

> I frequently see IRA doing a very bad job for small register classes
> like here.  Maybe it's better to take it completely away from IRA
> and write the load as
> 
> (set (reg:HI)
>  (unspec:HI (post_inc:PHI (reg:PHI Z
> 
> Loading from __pgm is actually an unspec, i.e. reading two times from
> the same address will yield the same result.

This really seems to be a problem in IRA somewhere, but I'd guess it
would be better to fix in there instead of working around it.  Maybe
you should open a bug an get in touch with the IRA maintainers ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: libgcc: strange optimization

2011-08-09 Thread Ulrich Weigand 
Richard Earnshaw wrote:

> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements.  At other times they are simply the same as other local
> variables.  Now we have a problem that the register allocator knows how
> to solve.

This seems to be pretty much the same as my proposal here:
http://gcc.gnu.org/ml/gcc/2011-08/msg00064.html

But there was some push-back on requiring additional semantics
by some users ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: FDO and LTO on ARM

2011-08-09 Thread Marc Glisse 

On Tue, 9 Aug 2011, Mike Hommey wrote:


This one only happens with using the -std=gnu++0x flag.

The attached preprocessed file builds fine without -std=gnu++0x, and
fails with -std=gnu++0x. Note the same original file didn't fail with
the same stlport and -std=gnu++0x with gcc 4.6.


Shorter:

class string;
void f(const string&);
string x();
struct locale {
string y() const;
};
template  void g(const locale& l) {
f(x()); // OK
f(l.y()); // FAIL in C++0X
}

g++ apparently instantiates more eagerly in C++0X than in C++03.

--
Marc Glisse

Re: FDO and LTO on ARM

2011-08-09 Thread Mike Hommey 
On Mon, Aug 08, 2011 at 02:20:37PM +0200, Mike Hommey wrote:
> I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> One is bug 50022 that I filed today.
> 
> Another is the following error in stlport headers:
>   error: invalid use of incomplete type 'std::string {aka struct
>   std::basic_string, std::allocator >}'
> 
> I also tried GNU libstdc++ instead of stlport but I hit some other
> errors that boil down to the following:
>   error: 'std::wstring' has not been declared

Once I get past these, linkage of libxul.so fails with:
/root/android-ndk-r6/toolchains/arm-linux-androideabi-4.6.99.20110806/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.7.0/../../../../arm-linux-androideabi/bin/ld:
../../dist/lib/libjs_static.a(jsbool.o)(.text+0x1e): unresolvable
R_ARM_THM_CALL relocation against symbol `__gcov_indirect_call_profiler'
/root/android-ndk-r6/toolchains/arm-linux-androideabi-4.6.99.20110806/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.7.0/../../../../arm-linux-androideabi/bin/ld:
final link failed: Nonrepresentable section on output

I need to check what's going on.

Mike

ARM summit at Plumbers 2011

2011-08-09 Thread Steve McIntyre 
Hi folks,

Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.

We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect [2] event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:

 * ARM hard-float
   + What is it and why does it matter?
   + How can distributions keep compatible (i.e. gcc triplet to
 describe the port)?

 * Adding support for ARM as an architecture to the Linux Standard
   Base (LSB)
   + Does it matter?
   + What's needed?

 * FHS - multi-arch coming soon, how do we proceed?

 * 3D support on ARM platforms
   + Open GL vs. GLES - which is appropriate?

but I'm sure that other people will think of more issues they'd like
to discuss. :-)

If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.

[1] http://www.linuxplumbersconf.org/2011/
[2] http://connect.linaro.org/

Cheers,
--
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: libgcc: strange optimization

2011-08-09 Thread Hans-Peter Nilsson 
On Tue, 9 Aug 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
> > Better still would be to change the specification and implementation of
> > local register variables to only guarantee them at the beginning of ASM
> > statements.  At other times they are simply the same as other local
> > variables.  Now we have a problem that the register allocator knows how
> > to solve.
>
> This seems to be pretty much the same as my proposal here:
> http://gcc.gnu.org/ml/gcc/2011-08/msg00064.html
>
> But there was some push-back on requiring additional semantics
> by some users ...

Don't feel bad, at least we seem to have overwhelming consensus
on what to do for local asm-declared register variables when
they feed asm statements! :)

I found an example where I have an asm-declared register that
was used not just for the primary asm statement, but I'm ok with
those other uses not using the declared register, just as warned
by the documentation.  (I don't think gcc can better assign
another register, but that's beside the point.)

brgds, H-P

gcc-4.4-20110809 is now available

2011-08-09 Thread gccadmin 
Snapshot gcc-4.4-20110809 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110809/
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/branches/gcc-4_4-branch 
revision 177606

You'll find:

 gcc-4.4-20110809.tar.bz2 Complete GCC

  MD5=da7a42a4cf0d1ded9ec8dc9bedc17660
  SHA1=e517b52d01d10f283d4c900e5d821cb0090a7b4e

Diffs from 4.4-20110802 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.

An unusual x86_64 code model

2011-08-09 Thread Jed Davis 
The vSphere Hypervisor (ESXi) kernel runs on x86_64 and loads all text
and data sections (for the kernel itself and for modules) within a 2GB
window that lives around virtual address 0x4180 (65.5 TiB). 
Thus, 32-bit absolute addresses won't work, but %rip-relative addressing
is fine.  Additionally, because this is a kernel, the usual issues of
"shared text" that discourage text relocations are inapplicable.

What this means in terms of GCC is: the usual small code model won't
work, nor -mcmodel=kernel, because they assume signed 32-bit addresses.
The large code model probably will work, but that turns everything into
movabs and indirect calls, which is unnecessarily inefficient.  The
closest approximation is -fPIC or -fPIE, but that assumes we want to
implement the PLT/GOT machinery in our loader, which we don't; it imposes
overhead for no benefit.

The existing workaround, which predates my personal involvement, is to
use -fPIE together with a -include'd file that uses a #pragma to set the
default symbol visibility to hidden, which suppresses the PLTness.
That works on GCC 4.1, but with newer versions that no longer affects
implicitly declared functions (which turn up occasionally in third-party
drivers), or coverage instrumentation's calls to __gcov_init, or probably
other things that have not yet been discovered.  Also, it was never an
ideal solution, except in that it didn't require modifying the compiler
(at the time).

Thus, I'm trying to find the right solution.  My current attempt is to
add an -mno-plt flag in i386.opt, and add it to the list of reasons not
to print "@PLT" after symbol names.  This seems to work, although I've
only done minimal testing so far.

But is that the right way to do that, do people think?  Or should I
look into making this its own -mcmodel option?  (Which would raise the
question of what to call it -- medsmall? smallhigh? altkernel?)  Or is
there some other way that this ought to be done?

Thanks,
--Jed

RE: FDO and LTO on ARM

2011-08-09 Thread Fu, Chao-Ying 
> 
> I identified the libstdc++ failure as a problem when building gcc:
> 
> configure:16321:  /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc 
> -shared-libgcc -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++ 
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/
> src 
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/
> src/.libs 
> -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/p
> rebuilt/linux-x86/arm-linux-androideabi/bin/ 
> -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/p
> rebuilt/linux-x86/arm-linux-androideabi/lib/ -isystem 
> /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/pre
> built/linux-x86/arm-linux-androideabi/include -isystem 
> /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/pre
> built/linux-x86/arm-linux-androideabi/sys-include-c 
> -frtti -fexceptions -O2 -Os -g -DTARGET_POSIX_IO 
> -fno-short-enums  conftest.cpp >&5
> conftest.cpp:35:18: error: 'INT_MIN' was not declared in this scope
> conftest.cpp:36:18: error: 'INT_MAX' was not declared in this scope
> (snip)
> configure:16345: checking for enabled wchar_t specializations
> configure:16347: result: no
> 

  I hit the same issue sometime ago.  This is a bug in NDK platform android-9 
"wchar.h".
To fix it, just add  into wchar.h.
Ex:
# git diff wchar.h
diff --git a/ndk/platforms/android-9/include/wchar.h b/ndk/platforms/android-9/i
index 9b744a5..fb8714c 100644
--- a/ndk/platforms/android-9/include/wchar.h
+++ b/ndk/platforms/android-9/include/wchar.h
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 


Regards,
Chao-ying

Re: An unusual x86_64 code model

2011-08-09 Thread Andrew Pinski 
On Tue, Aug 9, 2011 at 4:26 PM, Jed Davis  wrote:
> The existing workaround, which predates my personal involvement, is to
> use -fPIE together with a -include'd file that uses a #pragma to set the
> default symbol visibility to hidden, which suppresses the PLTness.
> That works on GCC 4.1, but with newer versions that no longer affects
> implicitly declared functions (which turn up occasionally in third-party
> drivers), or coverage instrumentation's calls to __gcov_init, or probably
> other things that have not yet been discovered.  Also, it was never an
> ideal solution, except in that it didn't require modifying the compiler
> (at the time).

Have you tried -fvisibility=hidden option ?

Thanks,
Andrew Pinski

Re: libgcc: strange optimization

2011-08-09 Thread Hans-Peter Nilsson 
On Tue, 9 Aug 2011, Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements.

Only for those asm statements taking the same asm-register
variables as arguments.

>  At other times they are simply the same as other local
> variables.  Now we have a problem that the register allocator knows how
> to solve.
>
> In other words, if the user writes
>
> bar (int y)
> {
>   register int x asm ("r0") = y;
>
>   foo()
>
>   asm volatile ("mov r1, r0");
>
> }
>
> The compiler will generate
> (set (reg:SI 999 ) (reg:SI ))
> (call "foo")
> (set (reg:SI 0 "r0") (reg:SI 999 ))
> (asm "mov r1, r0")
> (set (reg:SI 999 ) (reg:SI 0 "r0"))

It should rather eliminate the variable x and its assignment as
it isn't used in a way properly conveyed to gcc: the occurrence
of the string "r0" in the asm should not be considered.

I like Ulrich Weigand's proposal better, not the least because
it's how it's already documented to work.

brgds, H-P