headers
Jon Grant | 1 Aug 2011 01:20

Re: onlinedocs formated text too small to read

Hello

Georg-Johann Lay wrote, On 08/07/11 19:08:
[.]
> I can confirm that it's hardly readable on some systems.
> I use Opera and several FF versions, some worse, some a bit less worse.
>
> IMO it's definitely to small, I already thought about complaining, too.
>
> Johann

Could I ask, what would be the best way to progress this request? e.g. 
Should I create a bugzilla ticket.

Best regards, Jon
Permalink | Reply | 2 comments |
headers
Jiangning Liu | 1 Aug 2011 05:44
Favicon

RE: [RFC] Add middle end hook for stack red zone size

Joern,

Thanks for your valuable feedback! This is only a RFC, and I will send out formal patch along with ChangLog
later on. 

Basically, my patch is only to add new dependence in scheduler, and it only blocks some instruction
movements, so it is NO RISK to compiler correctness. For whatever stack pointer changes you gave in
different scenarios, the current code base should already work. My patch intends neither to replace old
dependences, nor maximize the scheduler capability due to the existence of red zone in stack. It is only to
block the memory access moving over stack pointer adjustment if distance is beyond red zone size, which is
an OS requirement due to interruption existence. 

Stack adjustment in epilogue is a very general usage in stack frame. It's quite necessary to solve the
general problem in middle-end rather than in back-end. Also, that old patch you attached is to solve the
data dependence between two memory accesses, but stack pointer doesn't really have data dependence with
memory access without using stack pointer, so they have different stories. Alternative solution of
without adding blunt scheduling barrier is we insert an independent pass before scheduler to create RTL
barrier by using the same interface stack_red_zone_size, but it would really be an over-design, if we add
a new pass only for this *small* functionality.

In my patch, *abs* of offset is being used, so you are right that it's possible to get false positive to be too
conservative, but there won't exist false negative, because my code would only add new dependences. 

Since the compilation is based on function, it would be OK if red zone size varies due to different ABI. Could
you please tell me exactly on what system being supported by GCC red zone size can be different for incoming
and outgoing? And also how scheduler guarantee the correctness in current code base? Anyway, I don't
think my patch will break the original solution.

Thanks,
-Jiangning
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rohit Arul Raj | 1 Aug 2011 08:42
Picon

Help with PPC Relocation options

Hello All,

I compiled a simple 1.c file with -mpcu=e500mc64 option and while
trying to create a relocatable, i am getting the following error:

$powerpc-elf-ld.exe -static -r 1.o
powerpc-elf-ld.exe: Relocatable linking with relocations from format
elf64-powerpc (1.o) to format elf32-powerpc (a.out) is not supported

$ powerpc-elf-ld.exe -static -r 1.o --oformat elf64-powerpc
powerpc-elf-ld.exe: Relocatable linking with relocations from format
elf64-powerpc (1.o) to format elf64-powerpc (a.out) is not supported

Is relocatable linking not allowed for 64bit PPC?

Regards,
Rohit
Permalink | Reply | 1 comment |
headers
Rohit Arul Raj | 1 Aug 2011 09:08
Picon

Re: Help with PPC Relocation options

On Mon, Aug 1, 2011 at 12:12 PM, Rohit Arul Raj <rohitarulraj <at> gmail.com> wrote:
> Hello All,
>
> I compiled a simple 1.c file with -mpcu=e500mc64 option and while
> trying to create a relocatable, i am getting the following error:
>
> $powerpc-elf-ld.exe -static -r 1.o
> powerpc-elf-ld.exe: Relocatable linking with relocations from format
> elf64-powerpc (1.o) to format elf32-powerpc (a.out) is not supported
>
>
> $ powerpc-elf-ld.exe -static -r 1.o --oformat elf64-powerpc
> powerpc-elf-ld.exe: Relocatable linking with relocations from format
> elf64-powerpc (1.o) to format elf64-powerpc (a.out) is not supported
>
> Is relocatable linking not allowed for 64bit PPC?
>
> Regards,
> Rohit
>

Yeah got it.. "-m elf64ppc"

I was trying with '-m64' option which worked with  'powerpc-linux'
tool chain but doesn't work with 'powerpc-elf' toolchain.

Thanks,
Rohit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg-Johann Lay | 1 Aug 2011 10:40
Picon
Favicon

Re: onlinedocs formated text too small to read

Jon Grant wrote:
> Hello
> 
> Georg-Johann Lay wrote, On 08/07/11 19:08:
> [.]
>> I can confirm that it's hardly readable on some systems.
>> I use Opera and several FF versions, some worse, some a bit less worse.
>>
>> IMO it's definitely to small, I already thought about complaining, too.
>>
>> Johann
> 
> Could I ask, what would be the best way to progress this request? e.g.
> Should I create a bugzilla ticket.
> 
> Best regards, Jon

http://gcc.gnu.org/ml/gcc/2011-07/msg00106.html

CCed Gerald, I think he cares for that kind of things.

If he does not answer (it's vacation time) file a PR so that it won't be forgotten.

Johann
Permalink | Reply | 1 comment |
headers
Richard Guenther | 1 Aug 2011 11:14
Picon

Re: PATCH RFA: Build stages 2 and 3 with C++

2011/8/1 Marc Glisse <marc.glisse <at> inria.fr>:
> On Fri, 15 Jul 2011, Ian Lance Taylor wrote:
>
>> I would like to propose this patch as a step toward building gcc using a
>> C++ compiler.  This patch builds stage1 with the C compiler as usual,
>> and defaults to building stages 2 and 3 with a C++ compiler built during
>> stage 1.  This means that the gcc installed and used by most people will
>> be built by a C++ compiler.  This will ensure that gcc is fully
>> buildable with C++, while retaining the ability to bootstrap with only a
>> C compiler, not a C++ compiler.
>
> Nice step. Now that gcc can (mostly) build with g++, it would be great if it
> could build with a non-gnu compiler. More precisely, with a compiler that
> doesn't define __GNUC__. Indeed, the code is quite different in this case,
> as can be seen trying to compile gcc with CC='gcc -U__GNUC__' and CXX='g++
> -U__GNUC__' (there are other reasons why this won't work, but at least it
> shows some of the same issues I see with sunpro).
>
>
> To start with, the obstack_free macro casts a pointer to an int -> error.
> /data/repos/gcc/trunk/libcpp/directives.c:2048:7: error: cast from ‘char*’
> to ‘int’ loses precision [-fpermissive]
>
>
> Then, ENUM_BITFIELD(cpp_ttype) is expanded to unsigned int instead of the
> enum, and conversions from int to enum require an explicit cast in C++,
> giving many errors like:
> /data/repos/gcc/trunk/libcpp/charset.c:1615:79: error: invalid conversion
> from ‘unsigned int’ to ‘cpp_ttype’ [-fpermissive]
> /data/repos/gcc/trunk/libcpp/charset.c:1371:1: error:   initializing
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joseph S. Myers | 1 Aug 2011 11:53

Re: PATCH RFA: Build stages 2 and 3 with C++

On Mon, 1 Aug 2011, Richard Guenther wrote:

> I think it's the only viable solution (use the full enum for a non-GCC stage1
> C++ compiler).  We could help it somewhat by at least placing
> enum bitfields first/last in our bitfield groups.

Are GCC and other compilers declaring that they support the GNU C and C++ 
languages by defining __GNUC__ really the only compilers with this 
extension?  Feature tests for particular features are generally better 
than testing for whether the compiler in use is GCC.  (Using configure 
tests for things in ansidecl.h does require checking where in the gcc and 
src repositories those things are used, to make sure that the relevant 
configure tests are used everywhere necessary.)

(Actually, C++03 appears to support enum bit-fields - it's only for C that 
they are a GNU extension - so can't we just enable them unconditionally 
when building as C++?)

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 2 comments |
headers
Richard Guenther | 1 Aug 2011 11:59
Picon

Re: PATCH RFA: Build stages 2 and 3 with C++

On Mon, Aug 1, 2011 at 11:53 AM, Joseph S. Myers
<joseph <at> codesourcery.com> wrote:
> On Mon, 1 Aug 2011, Richard Guenther wrote:
>
>> I think it's the only viable solution (use the full enum for a non-GCC stage1
>> C++ compiler).  We could help it somewhat by at least placing
>> enum bitfields first/last in our bitfield groups.
>
> Are GCC and other compilers declaring that they support the GNU C and C++
> languages by defining __GNUC__ really the only compilers with this
> extension?  Feature tests for particular features are generally better
> than testing for whether the compiler in use is GCC.  (Using configure
> tests for things in ansidecl.h does require checking where in the gcc and
> src repositories those things are used, to make sure that the relevant
> configure tests are used everywhere necessary.)
>
> (Actually, C++03 appears to support enum bit-fields - it's only for C that
> they are a GNU extension - so can't we just enable them unconditionally
> when building as C++?)

Oh, sure - that's even better.

Richard.
Permalink | Reply | 0 comments |
headers
Marc Glisse | 1 Aug 2011 12:05
Picon
Picon
Favicon

Re: PATCH RFA: Build stages 2 and 3 with C++

On Mon, 1 Aug 2011, Joseph S. Myers wrote:

> On Mon, 1 Aug 2011, Richard Guenther wrote:
>
>> I think it's the only viable solution (use the full enum for a non-GCC stage1
>> C++ compiler).  We could help it somewhat by at least placing
>> enum bitfields first/last in our bitfield groups.
>
> Are GCC and other compilers declaring that they support the GNU C and C++
> languages by defining __GNUC__ really the only compilers with this
> extension?  Feature tests for particular features are generally better
> than testing for whether the compiler in use is GCC.  (Using configure
> tests for things in ansidecl.h does require checking where in the gcc and
> src repositories those things are used, to make sure that the relevant
> configure tests are used everywhere necessary.)

I just checked, and indeed sunpro supports this extension as well in C.

> (Actually, C++03 appears to support enum bit-fields - it's only for C that
> they are a GNU extension - so can't we just enable them unconditionally
> when building as C++?)

Great, I didn't know that. That's a much better solution.

--

-- 
Marc Glisse
Permalink | Reply | 0 comments |
headers
Jiangning Liu | 1 Aug 2011 12:14
Favicon

RE: [RFC] Add middle end hook for stack red zone size

The answer is ARM can. However, if you look into the bugs PR30282 and 
PR38644, PR44199, you may find in history, there are several different cases

in different ports reporting the similar failures, covering x86, PowerPC and

ARM. You are right, they were all fixed in back-ends in the past, but we
should 
fix the bug in a general way to make GCC infrastructure stronger, rather 
than fixing the problem target-by-target and case-by-case! If you further 
look into the back-end fixes in x86 and PowerPC, you may find they looks 
quite similar in back-ends. 

Thanks,
-Jiangning

> -----Original Message-----
> From: gcc-patches-owner <at> gcc.gnu.org [mailto:gcc-patches-owner <at> gcc.gnu.org]
> On Behalf Of Jakub Jelinek
> Sent: Monday, August 01, 2011 5:12 PM
> To: Jiangning Liu
> Cc: 'Joern Rennecke'; gcc <at> gcc.gnu.org; gcc-patches <at> gcc.gnu.org;
> vmakarov <at> redhat.com; dje.gcc <at> gmail.com; Richard Henderson; Ramana
> Radhakrishnan; 'Ramana Radhakrishnan'
> Subject: Re: [RFC] Add middle end hook for stack red zone size
> 
> On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
> > It's quite necessary to solve the general problem in middle-end rather
than in
> back-end.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane