gcc/resource.h conflicts with sysroot/usr/include/resource.h (alpha-dec-vms)

[Jay K]

lpha-dec-vms-gcc -c   -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attri
bute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -
I. -I/src/gcc-4.5.0/gcc -I/src/gcc-4.5.0/gcc/. -I/src/gcc-4.5.0/gcc/../include 
-I/src/gcc-4.5.0/gcc/../libcpp/include -I/obj/gcc/vms/.
/gmp -I/src/gcc-4.5.0/gmp -I/obj/gcc/vms/./mpfr -I/src/gcc-4.5.0/mpfr 
-I/src/gcc-4.5.0/mpc/src  -I/src/gcc-4.5.0/gcc/../libdecnumber -
I/src/gcc-4.5.0/gcc/../libdecnumber/dpd -I../libdecnumber 
/src/gcc-4.5.0/gcc/c-lang.c -o c-lang.o
In file included from /src/gcc-4.5.0/gcc/resource.h:24:0,
 from 
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/wait.h:74,
 from 
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/stdlib.h:51,
 from /src/gcc-4.5.0/gcc/system.h:211,
 from /src/gcc-4.5.0/gcc/c-lang.c:24:

/src/gcc-4.5.0/gcc/hard-reg-set.h:42:39: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before 'HARD_REG_ELT_TYPE'


The problem is that there is both gcc/resource.h and 
sysroot/usr/include/resource.h.

When sysroot/usr/include/wait.h does:

#if defined _XOPEN_SOURCE_EXTENDED || !defined _POSIX_C_SOURCE
#   include         /* for siginfo_t */
#   include     /* for struct rusage */
#endif

it gets the wrong resource.h

for now I patched sysroot/usr/include/wait.h to #include "resource.h" instead.

Unfortunate fix is maybe to rename to gcc/gccresource.h?

 - Jay
 
  

Re: Building GCC & CFLAGS settings

[Andreas Schwab]

Steve Ellcey  writes:

> HJ seems to have the way to make it work, set CC to 'gcc -mlp64' instead
> of setting CC to 'gcc' and CFLAGS to '-mlp64' but that seems a bit
> counter-intuitive to the meaning of the flags.

'-mlp64' is an ABI-changing flag, so it is better to put it in CC, since
you are, in effect, using an incompatible compiler.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

a peculiar fpload problem on an inferior processor

[Amker.Cheng]

Hi :
   Our processor has an errata that the direct fpu load cannot work right,
so I have to substitute instruction sequence "load_into_gpr ; move_gpr_into_fpr"
for direct fpload insn.
  Currently I thought of two potential methods as following:

method 1:
   step1 :  keep a scratch register when expanding fpload;
   step2 :  split insn fpload into "load_into_gpr ; move_gpr_into_fpr"
sequence by using the reserved scratch register;

method 2:
   generate "load_into_gpr ; move_gpr_into_fpr" when expanding directly.

I have only tried the first method, which end up with the errro "insn
does not satisfy its constraints".
after tracing cc1, found that the problematic insn was generated by
reloading, which trying to
spill float register into memory, which itself using direct fpload.

here is the question : Is it possible to replace all direct fpload
with "load_into_gpr ; move_gpr_into_fpr"
sequence. I doubt it since the reload pass might generate direct
fpload insn for spilling fpu register.

BTW, I prefer to do the replacement in gcc, rather than assembler,
since it might produce lots of pipeline stalls.

So, any advice? Thank you all.

-- 
Best Regards.

Re: Question about Machine Description

[yazdanbakhsh]

Hi,

As I told I want to add  "ble" intruction in MIPS that works like "beq".

I used from the available branch_equality instruction that shows in the
following paragraph:

--
(define_insn "branch_equality"
  [(set (pc)
(if_then_else (match_operator:SI 0 "equality_op"
 [(match_operand:SI 1 
"register_operand" "d")
  (match_operand:SI 2 
"register_operand" "d")])
(match_operand 3 "pc_or_label_operand" "")
(match_operand 4 "pc_or_label_operand" "")))]
  ""
  "*
{
  ss_branch_likely = (final_sequence && INSN_ANNULLED_BRANCH_P (insn));
  return (operands[3] != pc_rtx)
? \"%*b%C0%?\\t%z1,%z2,%3\"
: \"%*b%N0%?\\t%z1,%z2,%4\";
}"
  [(set_attr "type" "branch")
   (set_attr "mode" "none")
   (set_attr "length"   "1")])
--
To add "ble" I changed "equality_op" in the header file to have "ble" as a
acceptable operation.but it didn't work. Do u have any idea? I also saw some
functions in the assembler that handle branchs. Should i changed assembler
for this purpose?

Best Regards



yazdanbakhsh wrote:
> 
> I have read all the documents, and changed some lines but nothing happened
> :(
> 
> Ian Lance Taylor-3 wrote:
>> 
>> yazdanbakhsh  writes:
>> 
>>> I want to change instruction blez to ble. ble compare two registers and
>>> jump
>>> to the target address if the condition is true.
>> 
>> Read the internals manual to understand how operand predicates and
>> constraints work.  See the hundreds of existing examples.  Ask if you
>> have specific questions.
>> 
>> Ian
>> 
>>> Ian Lance Taylor-3 wrote:
 
 yazdanbakhsh  writes:
 
> Please assume I'm working with the MIPS. There is a little difference
> between the MIPS and what I'm actually working on it. How can I remove
> immediate logical shift right/left from the compiler?
> I mean If I want the programmer writes an immediate shift, It is
> compiled
> to
> the two instructions:
>
> sll %2,%2,5
>
> changed to:
>
> addi %3,%0,5
> sllv %2,%2,%3
 
 Find the insn which generates sll.  Change the operand constraints and
 predicates to reject an immediate operand.
 
 E.g., in mips.md this is:
 
 (define_insn "*3"
   [(set (match_operand:GPR 0 "register_operand" "=d")
(any_shift:GPR (match_operand:GPR 1 "register_operand" "d")
   (match_operand:SI 2 "arith_operand" "dI")))]
   "!TARGET_MIPS16"
 {
   if (CONST_INT_P (operands[2]))
 operands[2] = GEN_INT (INTVAL (operands[2])
   & (GET_MODE_BITSIZE (mode) - 1));
 
   return "\t%0,%1,%2";
 }
   [(set_attr "type" "shift")
(set_attr "mode" "")])
 
 
 For operand 2, change the predicate to register_operand and remove the
 'I' constraint.
 
 Ian
 
 
>>>
>>> -- 
>>> View this message in context:
>>> http://old.nabble.com/Question-about-Machine-Description-tp1026428p28447744.html
>>> Sent from the gcc - Dev mailing list archive at Nabble.com.
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28471097.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Build report for gcc-4.5.0 - i686-pc-cygwin m68k-unknown-elf

[Alexandr Yeremenko]

$ ../../src/gcc-4.5.0/config.
guess
i686-pc-cygwin

$ m68k-elf-gcc -v
Using built-in specs.
COLLECT_GCC=m68k-elf-gcc
COLLECT_LTO_WRAPPER=/usr/gcc-m68k/libexec/gcc/m68k-elf/4.5.0/lto-wrapper.exe
Target: m68k-elf
Configured with: ../../src/gcc-4.5.0/configure --target=m68k-elf --prefix=/usr/g
cc-m68k --with-newlib --enable-languages=c --disable-shared --disable-libssp
Thread model: single
gcc version 4.5.0 (GCC)

Regards,
Alex

scheduling on VLIW architecture

[roy rosen]

Hi all.

I work on a VLIW architecture.
The sched2 pass adds a TImode to insns which should start a new issue group.
But, after this pass, other passes change the insns, so the sched2
work that was done is not correct anymore (the groups of insns might
be invalid).

In particular I see that the compgotos pass deletes and inserts jump
insns without being aware of the TI attributes which on my port leads
to an error.

What am I doing wrong? Should I move the sched2 pass to be the last?

Thanks, Roy.

Re: scheduling on VLIW architecture

[Steven Bosscher]

On Thu, May 6, 2010 at 11:47 AM, roy rosen  wrote:
> Hi all.
>
> I work on a VLIW architecture.
> The sched2 pass adds a TImode to insns which should start a new issue group.
> But, after this pass, other passes change the insns, so the sched2
> work that was done is not correct anymore (the groups of insns might
> be invalid).
>
> In particular I see that the compgotos pass deletes and inserts jump
> insns without being aware of the TI attributes which on my port leads
> to an error.
>
> What am I doing wrong? Should I move the sched2 pass to be the last?

Yes -- or at least this is what the ia64 back end does. See
config/ia64/ia64.c:ia64_reorg(), and look in passes.c for
pass_machine_reorg to see what else runs after pass_machine_reorg,
check if there is a pass that may still change insns for your port
(e.g. shorten-branches).

Ciao!
Steven

Re: a peculiar fpload problem on an inferior processor

[Dave Korn]

On 06/05/2010 10:00, Amker.Cheng wrote:

> here is the question : Is it possible to replace all direct fpload
> with "load_into_gpr ; move_gpr_into_fpr"
> sequence. I doubt it since the reload pass might generate direct
> fpload insn for spilling fpu register.

  It is possible.  Your expander can handle it before reload; to handle it
during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.

http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974

cheers,
  DaveK

Re: Build report for gcc-4.5.0 - i686-pc-cygwin m68k-unknown-elf

[Joel Sherrill]

On 05/06/2010 04:46 AM, Alexandr Yeremenko wrote:

$ ../../src/gcc-4.5.0/config.
guess
i686-pc-cygwin

$ m68k-elf-gcc -v
Using built-in specs.
COLLECT_GCC=m68k-elf-gcc
COLLECT_LTO_WRAPPER=/usr/gcc-m68k/libexec/gcc/m68k-elf/4.5.0/lto-wrapper.exe
Target: m68k-elf
Configured with: ../../src/gcc-4.5.0/configure --target=m68k-elf --prefix=/usr/g
cc-m68k --with-newlib --enable-languages=c --disable-shared --disable-libssp
Thread model: single
gcc version 4.5.0 (GCC)

   

FWIW m68k-rtems is a very close cousin of m68k-elf and I did
a C, C++ and Ada test run using a Coldfire uC5282 as the
target on 28 April.  We ran on Qemu so anyone can repeat this.

C/C++

http://www.rtems.org/pipermail/rtems-tooltestresults/2010-April/000346.html

Ada:

http://www.rtems.org/pipermail/rtems-tooltestresults/2010-April/000347.html

It looks pretty good but there are ~500 failures on C and ~300 on Ada.
If anyone would like to help investigate, it would be appreciated.

--joel
RTEMS

Regards,
Alex
   

role of "register" C keyword?

[Basile Starynkevitch]

Hello All,

What is the role of the "register" keyword [=storage class specifier]
in C (& C++) in the current GCC compiler?

IIRC, (from my human rusty memory, I don't have the documents on hand)
the current standard only requires that variable declared with the
register class should not have their adress taken thru the unary &
operator, and might have some imprecise phrasing about register being
a hint for optimisation. IIRC the C++ language might not have this
requirement (of prohibiting the & unary operator). 

Long time ago (probably in the GCC 2.95 & 3.2 time frame) I would
imagine that the "register" keyword indeed affected register
allocation, in the sense that variables declared with register where
indeed & preferentially put in a machine register. In the current GCC,
I would guess it is not the case anymore (the machine register
allocation is done by optimization passes).

Of course, I am not speaking of
http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html or
http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html ; in both case
the register keyword is highly significant. I am just speaking of old
C code like
  register int i;
  for (i=0; i<10; i++) t[i]=i;

I believe nobody codes this way in 2010.

If my guessing is correct, perhaps we might add a sentence in the
documentation, something like

"The register storage class specifier keyword does not influence the
optimization and performance of generated code. It only prohibits (for
C code) the unary prefix addess-of operator &"

Perhaps the place to add that sentence [if it is correct] might be
http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html or
http://gcc.gnu.org/onlinedocs/gcc/Qualifiers-implementation.html or
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

BTW, I might have read somewhere than in future C & C++ standards the
register keyword might change its meaning or be obsolete... Am I
dreaming, or is there some evolution to expect?

Comments are welcome.

Regards.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[RFC] Introduce -Ofast

[Richard Guenther]

This is a proposal to introduce an optimization level -Ofast
that can collect (target specific) optimization flags that
can affect runtime behavior such as -funsafe-math-optimizations
or -mrecip.

Currently none of the standard optimization levels have this
kind of affect and we should not change that (people might
argue that -funsafe-math-optimizations can go into -O3).

For floating-point intensive programs people often disregard
the various special (and target dependent) flags and/or do
not know about -ffast-math.  -Ofast on the other hand is
recognized by many compilers and is widely known to affect
program behavior in corner cases.

I would initially propose to make -Ofast be -O3 -ffast-math
and would strongly encourage target maintainers that consider
adding to -Ofast make sure that popular benchmarks for
their target still behave correctly when using -Ofast.

Any comments or objections?

After the discussion has died down I will propose a patch
to gcc-patches.

Thanks,
Richard.

Re: [RFC] Introduce -Ofast

[Tobias Burnus]

On 05/06/2010 04:24 PM, Richard Guenther wrote:
> I would initially propose to make -Ofast be -O3 -ffast-math
> and would strongly encourage target maintainers that consider
> adding to -Ofast make sure that popular benchmarks for
> their target still behave correctly when using -Ofast.

I am in favour of the suggestion.

How about also adding "-march=native" (for targets where it is
available)? Otherwise, one may end up, e.g. on x86, to compile for i386
- and then -O3 -ffast-math won't help. But also on other systems
configuring for the compile system is useful - but it should be
overridable. Another option one could consider is -funroll-loops.

(Intel's "-fast" also implies "-xHost". Pathscale (always) defaults to
"-march=auto", Portland also [unless "-tp..." is used].)

Tobias

C++0x Memory model and gcc

[Andrew MacLeod]

I've been working for a while on understanding how the new memory model 
and Atomics work, and what the impacts are on GCC.


It would be ideal to get as many of these changes into GCC 4.6 as 
possible. I've started work on some of the modifications and testing,  
and the overall impact on GCC shouldn't be *too* bad :-)


The plan is to localize the changes as much as possible, and any 
intrusive bits like optimization changes will be controlled by a flag 
enabling us to keep the current behaviour when we want it.


I've put together a document summarizing how the memory model works, and 
how I propose to make the changes. I've converted it to wiki pages.  
Maybe no one will laugh at my choice of document format this time :-)


The document is linked off the Atomics wiki page, or directly  here:  
http://gcc.gnu.org/wiki/Atomic/GCCMM


It consists mainly of describing the 2 primary aspects of the memory 
model which affects us

- Optimization changes to avoid introducing new data races
- Implementation of atomic variables and synchronization modes
as well as a new infrastructure to test these types of things.

I'm sure I've screwed something up while doing it, and I will proofread 
it later today again and tweak it further.


Please point out anything that isn't clear,  or is downright wrong. 
Especially in the testing methodology since its all new stuff.

Suggestions for improvements on any of the plan are welcome as well.

Andrew

Re: C++0x Memory model and gcc

[Richard Guenther]

On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod  wrote:
> I've been working for a while on understanding how the new memory model and
> Atomics work, and what the impacts are on GCC.
>
> It would be ideal to get as many of these changes into GCC 4.6 as possible.
> I've started work on some of the modifications and testing,  and the overall
> impact on GCC shouldn't be *too* bad :-)
>
> The plan is to localize the changes as much as possible, and any intrusive
> bits like optimization changes will be controlled by a flag enabling us to
> keep the current behaviour when we want it.
>
> I've put together a document summarizing how the memory model works, and how
> I propose to make the changes. I've converted it to wiki pages.  Maybe no
> one will laugh at my choice of document format this time :-)
>
> The document is linked off the Atomics wiki page, or directly  here:
>  http://gcc.gnu.org/wiki/Atomic/GCCMM
>
> It consists mainly of describing the 2 primary aspects of the memory model
> which affects us
> - Optimization changes to avoid introducing new data races
> - Implementation of atomic variables and synchronization modes
> as well as a new infrastructure to test these types of things.
>
> I'm sure I've screwed something up while doing it, and I will proofread it
> later today again and tweak it further.
>
> Please point out anything that isn't clear,  or is downright wrong.
> Especially in the testing methodology since its all new stuff.
> Suggestions for improvements on any of the plan are welcome as well.

First let me say that the C++ memory model is crap when it
forces data-races to be avoided for unannotated data like
the examples for packed data.

Well, I hope that instead of just disabling optimizations you
will help to improve their implementation to be able to optimize
in a conformant manner.

Richard.

> Andrew
>
>
>
>

Re: C++0x Memory model and gcc

[Joseph S. Myers]

On Thu, 6 May 2010, Andrew MacLeod wrote:

> - Implementation of atomic variables and synchronization modes
> as well as a new infrastructure to test these types of things.

I presume you've read the long thread starting at 
 regarding the issues 
involved in implementing the atomics (involving compiler and libc 
cooperation to provide stdatomic.h), and in particular ensuring that code 
built for one CPU remains safe on later CPU variants that may have more 
native atomic operations.

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

Re: C++0x Memory model and gcc

[Richard Guenther]

On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
 wrote:
> On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod  wrote:
>> I've been working for a while on understanding how the new memory model and
>> Atomics work, and what the impacts are on GCC.
>>
>> It would be ideal to get as many of these changes into GCC 4.6 as possible.
>> I've started work on some of the modifications and testing,  and the overall
>> impact on GCC shouldn't be *too* bad :-)
>>
>> The plan is to localize the changes as much as possible, and any intrusive
>> bits like optimization changes will be controlled by a flag enabling us to
>> keep the current behaviour when we want it.
>>
>> I've put together a document summarizing how the memory model works, and how
>> I propose to make the changes. I've converted it to wiki pages.  Maybe no
>> one will laugh at my choice of document format this time :-)
>>
>> The document is linked off the Atomics wiki page, or directly  here:
>>  http://gcc.gnu.org/wiki/Atomic/GCCMM
>>
>> It consists mainly of describing the 2 primary aspects of the memory model
>> which affects us
>> - Optimization changes to avoid introducing new data races
>> - Implementation of atomic variables and synchronization modes
>> as well as a new infrastructure to test these types of things.
>>
>> I'm sure I've screwed something up while doing it, and I will proofread it
>> later today again and tweak it further.
>>
>> Please point out anything that isn't clear,  or is downright wrong.
>> Especially in the testing methodology since its all new stuff.
>> Suggestions for improvements on any of the plan are welcome as well.
>
> First let me say that the C++ memory model is crap when it
> forces data-races to be avoided for unannotated data like
> the examples for packed data.
>
> Well, I hope that instead of just disabling optimizations you
> will help to improve their implementation to be able to optimize
> in a conformant manner.

And btw, if you are thinking on how to represent the extra
data-dependencies required for the consistency models think
of how to extend whatever you need in infrastructure for that
to also allow FENV dependencies - it's a quite similar problem
(FENV query/set are the atomic operations, usual arithmetic
is what the dependency is to).  It's completely non-trivial
(because it's scalar code, not memory accesses).  For
atomics you should be able to just massage the alias-oracle
data-dependence routines (maybe).

Richard.

Re: C++0x Memory model and gcc

[Andrew MacLeod]

Joseph S. Myers wrote:

On Thu, 6 May 2010, Andrew MacLeod wrote:

  

- Implementation of atomic variables and synchronization modes
as well as a new infrastructure to test these types of things.



I presume you've read the long thread starting at 
 regarding the issues 
involved in implementing the atomics (involving compiler and libc 
cooperation to provide stdatomic.h), and in particular ensuring that code 
built for one CPU remains safe on later CPU variants that may have more 
native atomic operations.


  
Im not actually doing the implementation of Atomics themselves right 
now, Lawrence is looking at that. Im focusing on the GCC optimization 
requirements, changes and testing.  I'll leave issues like you point out 
there to the guys like like that stuff :-)


I couldn't understand a lot  of the atomic synchronization stuff from 
existing documentation, so I figured that part might help others 
understand it better too.  It still gives me a headache.


Andrew

Re: C++0x Memory model and gcc

[Andrew MacLeod]

Richard Guenther wrote:

On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
 wrote:
  

First let me say that the C++ memory model is crap when it
forces data-races to be avoided for unannotated data like
the examples for packed data.



And it isn't consistent across the board, since neighbouring bits 
normally don't qualify and can introduce data races. I don't like it 
when a solution has exceptions like that. It is what it is however, and 
last I heard the plan was for C to adopt the changes as well. 

Well, I hope that instead of just disabling optimizations you
will help to improve their implementation to be able to optimize
in a conformant manner.

I don't want to disable any more than required. SSA names aren't 
affected since they are local variables only,  its only operations on 
shared memory, and I am hopeful that I can minimize the restrictions 
placed on them.  Some will be more interesting than others... like 
CSE... you can still perform CSE on a global as long as you don't 
introduce a NEW load on some execution path that didn't have before. 
What fun.


And btw, if you are thinking on how to represent the extra
data-dependencies required for the consistency models think
of how to extend whatever you need in infrastructure for that
to also allow FENV dependencies - it's a quite similar problem
(FENV query/set are the atomic operations, usual arithmetic
is what the dependency is to).  It's completely non-trivial
(because it's scalar code, not memory accesses).  For
atomics you should be able to just massage the alias-oracle
data-dependence routines (maybe).
  


That's what I'm hoping actually..

Andrew.

Re: Question about Machine Description

[yazdanbakhsh]

Hi,

I changed the .md and .c file:

I add these lines to the .md file:

-
(define_insn "ble1"
  [(set (pc)
(if_then_else: SI (le:SI (match_operand:SI 0 "register_operand" "=d,d")
(match_operand:SI 1 "register_operand" "=d,d"))
  (label_ref (match_operand 2 "" ""))
  (pc)))]
  ""
  "ble1\\t%0,%1,%2"

 [(set_attr "type" "branch")
  (set_attr "mode" "SI")])

(define_expand "cbranchsi4"
  [(set (pc)
(if_then_else: SI (le:SI (match_operand:SI 0 "register_operand" "=d,d")
(match_operand:SI 1 "register_operand" "=d,d"))
  (label_ref (match_operand 2 "" ""))
  (pc)))]
  ""
  "
{
  gen_conditional_le (operands[0],operands[1],operands[2]);
  DONE;
}")
-

and add these lines to the .c file:

***
gen_conditional_le(rtx comp1, rtx comp2, rtx final_label)
{
printf("my operation called");
emit_insn(gen_ble1(comp1, comp2, final_label));
return TRUE;
}
***

but it didn't work...
I want the following C code is compiled to just one instruction:

if(a<=b)
  c = 10;

asembly:
 ble1 $1,$2,0x...

(a ===> $1 and b===> $2)

I appreciate it if you would guide me through this issue.

best regards

Ian Lance Taylor-3 wrote:
> 
> yazdanbakhsh  writes:
> 
>> I have read all the documents, and changed some lines but nothing
>> happened :(
> 
> That is good, but to get help you really need to ask specific
> questions.  Show us an insn pattern, tell us what you are trying to
> do, tell us what you did, tell us what happened.
> 
> Ian
> 
>> Ian Lance Taylor-3 wrote:
>>> 
>>> yazdanbakhsh  writes:
>>> 
 I want to change instruction blez to ble. ble compare two registers and
 jump
 to the target address if the condition is true.
>>> 
>>> Read the internals manual to understand how operand predicates and
>>> constraints work.  See the hundreds of existing examples.  Ask if you
>>> have specific questions.
>>> 
>>> Ian
>>> 
 Ian Lance Taylor-3 wrote:
> 
> yazdanbakhsh  writes:
> 
>> Please assume I'm working with the MIPS. There is a little difference
>> between the MIPS and what I'm actually working on it. How can I
>> remove
>> immediate logical shift right/left from the compiler?
>> I mean If I want the programmer writes an immediate shift, It is
>> compiled
>> to
>> the two instructions:
>>
>> sll %2,%2,5
>>
>> changed to:
>>
>> addi %3,%0,5
>> sllv %2,%2,%3
> 
> Find the insn which generates sll.  Change the operand constraints and
> predicates to reject an immediate operand.
> 
> E.g., in mips.md this is:
> 
> (define_insn "*3"
>   [(set (match_operand:GPR 0 "register_operand" "=d")
>   (any_shift:GPR (match_operand:GPR 1 "register_operand" "d")
>  (match_operand:SI 2 "arith_operand" "dI")))]
>   "!TARGET_MIPS16"
> {
>   if (CONST_INT_P (operands[2]))
> operands[2] = GEN_INT (INTVAL (operands[2])
>  & (GET_MODE_BITSIZE (mode) - 1));
> 
>   return "\t%0,%1,%2";
> }
>   [(set_attr "type" "shift")
>(set_attr "mode" "")])
> 
> 
> For operand 2, change the predicate to register_operand and remove the
> 'I' constraint.
> 
> Ian
> 
> 

 -- 
 View this message in context:
 http://old.nabble.com/Question-about-Machine-Description-tp1026428p28447744.html
 Sent from the gcc - Dev mailing list archive at Nabble.com.
>>> 
>>> 
>>
>> -- 
>> View this message in context:
>> http://old.nabble.com/Question-about-Machine-Description-tp1026428p28449607.html
>> Sent from the gcc - Dev mailing list archive at Nabble.com.
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28476454.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: role of "register" C keyword?

[Jonathan Wakely]

On 06/05/2010, Basile Starynkevitch wrote:
>
> IIRC, (from my human rusty memory, I don't have the documents on hand)
> the current standard only requires that variable declared with the
> register class should not have their adress taken thru the unary &
> operator, and might have some imprecise phrasing about register being
> a hint for optimisation. IIRC the C++ language might not have this
> requirement (of prohibiting the & unary operator).

In C++ it's only a hint, which the compiler is free to ignore. Its use
will be deprecated in C++1x.

Re: role of "register" C keyword?

[Toon Moene]

On 05/06/2010 08:35 PM, Jonathan Wakely wrote:


On 06/05/2010, Basile Starynkevitch wrote:


[ register  variable ]


In C++ it's only a hint, which the compiler is free to ignore. Its use
will be deprecated in C++1x.


Indeed, g++ won't even complain about taking its address (much to my 
surprise):


$ cat a.cc
#include "stdio.h"
main (){
int b(int *a);
register int a;
printf("%d\n", b(&a));
}
$ g++ -v a.cc
...
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)
...

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Broken GCC mirror sites

[Krzysztof Żelechowski]

Regarding your page "GCC mirror sites" http://gcc.gnu.org/mirrors.html>:

* ftp://ftp.fu-berlin.de/unix/languages/gcc/> is empty.
* ftp://ftp.gwdg.de/pub/misc/gcc/> is broken.
* http://www.mpi-inf.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc> is 
broken.

Please remove these entries.

Cheers,
Chris

Re: Broken GCC mirror sites

[Eberhard Moenkeberg]

Hi,

On Thu, 6 May 2010, Krzysztof ?elechowski wrote:


Regarding your page "GCC mirror sites" http://gcc.gnu.org/mirrors.html>:

* ftp://ftp.fu-berlin.de/unix/languages/gcc/> is empty.
* ftp://ftp.gwdg.de/pub/misc/gcc/> is broken.
* http://www.mpi-inf.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc> is
broken.

Please remove these entries.


What do you mean - "broken"?

I am running daily updates at ftp.gwdg.de with 
rsync://gcc.gnu.org/gcc-ftp/.



Viele Gruesse
Eberhard Moenkeberg (emoe...@gwdg.de, e...@kki.org)

--
Eberhard Moenkeberg
Arbeitsgruppe IT-Infrastruktur
E-Mail: emoe...@gwdg.de  Tel.: +49 (0)551 201-1551
-
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG)
Am Fassberg 11, 37077 Goettingen
URL:http://www.gwdg.de E-Mail: g...@gwdg.de
Tel.:   +49 (0)551 201-1510Fax:+49 (0)551 201-2150
Geschaeftsfuehrer:   Prof. Dr. Bernhard Neumair
Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe
Sitz der Gesellschaft: Goettingen
Registergericht:   Goettingen  Handelsregister-Nr. B 598
-

Re: Question about Machine Description

[Ian Lance Taylor]

yazdanbakhsh  writes:

> (define_expand "cbranchsi4"
>   [(set (pc)
>   (if_then_else: SI (le:SI (match_operand:SI 0 "register_operand" "=d,d")
> (match_operand:SI 1 "register_operand" "=d,d"))
> (label_ref (match_operand 2 "" ""))
> (pc)))]
>   ""
>   "
> {
>   gen_conditional_le (operands[0],operands[1],operands[2]);
>   DONE;
> }")

The cbranchsi4 expander will be called to generate all conditional
branches.  You are only generating a ble, which is not going work.
The insn pattern of an expander is simply the default insn that it
generates.  When you end the expander code with DONE, the insn pattern
is ignored.  If you want to take this approach you need to handle all
supported conditional branches here.

See many examples in existing backends.  Besides the extensive
internal documentation, there are dozens of working examples that you
can look at to see how to implement this.


> but it didn't work...

In your next message please tell us how it failed, not merely the fact
that it failed.

Ian

Re: role of "register" C keyword?

[Ian Lance Taylor]

Basile Starynkevitch  writes:

> Long time ago (probably in the GCC 2.95 & 3.2 time frame) I would
> imagine that the "register" keyword indeed affected register
> allocation, in the sense that variables declared with register where
> indeed & preferentially put in a machine register.

I don't think the "register" keyword ever affected register allocation
in gcc.  For that you have to go back to compilers of the 1970s.

The register keyword does still have a use, though, in a gcc
extension: gcc uses it in combination with asm to implement register
variables.

> "The register storage class specifier keyword does not influence the
> optimization and performance of generated code. It only prohibits (for
> C code) the unary prefix addess-of operator &"

That would be appropriate in a general chapter on compiler
optimization.  As far as I know we don't have one, but I certainly
wouldn't be opposed to adding one.

Ian

Re: Broken GCC mirror sites

[Holger Weiß]

* Krzysztof Zelechowski  [2010-05-06 22:00]:
> Regarding your page "GCC mirror sites" http://gcc.gnu.org/mirrors.html>:
> 
> * ftp://ftp.fu-berlin.de/unix/languages/gcc/> is empty.

It's not.

> * ftp://ftp.gwdg.de/pub/misc/gcc/> is broken.

In what way?

> Please remove these entries.

Or just ask the mirror maintainers to fix the problem---if there is any.

Holger

-- 
FTP Admins FU Berlin 

Re: [RFC] Introduce -Ofast

[Ian Lance Taylor]

Richard Guenther  writes:

> This is a proposal to introduce an optimization level -Ofast
> that can collect (target specific) optimization flags that
> can affect runtime behavior such as -funsafe-math-optimizations
> or -mrecip.

Sounds like a good idea to me.  I don't like the name -Ofast, which is
ambiguous, but I see that there is precedent in the PathScale and PGI
compilers.  I don't think a potentially confusing name is enough of a
reason to buck the trend.

Ian

Re: role of "register" C keyword?

[Jakub Jelinek]

On Thu, May 06, 2010 at 01:22:27PM -0700, Ian Lance Taylor wrote:
> Basile Starynkevitch  writes:
> 
> > Long time ago (probably in the GCC 2.95 & 3.2 time frame) I would
> > imagine that the "register" keyword indeed affected register
> > allocation, in the sense that variables declared with register where
> > indeed & preferentially put in a machine register.
> 
> I don't think the "register" keyword ever affected register allocation
> in gcc.  For that you have to go back to compilers of the 1970s.
> 
> The register keyword does still have a use, though, in a gcc
> extension: gcc uses it in combination with asm to implement register
> variables.

register keyword has other uses, e.g. for -O0 code variables declared
with register keyword can be put into registers, while variables declared
without it always get stack slots.

Jakub

Re: role of "register" C keyword?

[Daniel Jacobowitz]

On Thu, May 06, 2010 at 01:22:27PM -0700, Ian Lance Taylor wrote:
> Basile Starynkevitch  writes:
> 
> > Long time ago (probably in the GCC 2.95 & 3.2 time frame) I would
> > imagine that the "register" keyword indeed affected register
> > allocation, in the sense that variables declared with register where
> > indeed & preferentially put in a machine register.
> 
> I don't think the "register" keyword ever affected register allocation
> in gcc.  For that you have to go back to compilers of the 1970s.

I think it does, without optimization.  There's some unique GDB tests
that use this.  It causes them to be live between statements in a
machine register instead of always stored in stack slots.

This might not be current information though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: C++0x Memory model and gcc

[Ian Lance Taylor]

Andrew MacLeod  writes:

> I've been working for a while on understanding how the new memory
> model and Atomics work, and what the impacts are on GCC.

Thanks for looking at this.

One issue I didn't see clearly was how to actually implement this in
the compiler.  For example, speculated stores are fine for local stack
variables, but not for global variables or heap memory.  We can
implement that in the compiler via a set of tests at each potential
speculated store.  Or we can implement it via a constraint expressed
directly in the IR--perhaps some indicator that this specific store
may not merge with conditionals.  The latter approach is harder to
design but I suspect will be more likely to be reliable over time.
The former approach is straightforward to patch into the compiler but
can easily degrade as people who don't understand the issues work on
the code.

I don't agree with your proposed command line options.  They seem fine
for internal use, but I think very very few users would know when or
whether they should use -fno-data-race-stores.  I think you should
downgrade those options to a --param value, and think about a
multi-layered -fmemory-model option.  E.g.,
-fmemory-model=single
Assume single threaded execution, which also means no signal
handlers.
-fmemory-model=fast
The user is responsible for all synchronization.  Accessing
the same memory words from different threads may break
unpredictably.
-fmemory-model=safe
The compiler will do its best to protect you.

Ian

Re: C++0x Memory model and gcc

[Andrew MacLeod]

Ian Lance Taylor wrote:

Andrew MacLeod  writes:

  

I've been working for a while on understanding how the new memory
model and Atomics work, and what the impacts are on GCC.



Thanks for looking at this.

One issue I didn't see clearly was how to actually implement this in
the compiler.  For example, speculated stores are fine for local stack
variables, but not for global variables or heap memory.  We can
implement that in the compiler via a set of tests at each potential
speculated store.  Or we can implement it via a constraint expressed
directly in the IR--perhaps some indicator that this specific store
may not merge with conditionals.  The latter approach is harder to
design but I suspect will be more likely to be reliable over time.
The former approach is straightforward to patch into the compiler but
can easily degrade as people who don't understand the issues work on
the code.
  


which is why the ability to regression test it is so important :-).  

Right now its my intention to modify the optimizations based on the flag 
settings. Some cases will be quite tricky.  If we're CSE'ing something 
in the absence of atomics, and it is shared memory, it is still possible 
to move it if there is already a load from that location on all paths.  
So the optimization itself will need to taught how to figure that out.


ie

if ()
 a_1 = glob
else
 if ()
 b_2 = glob
  else
 c_3 = glob

we can still common glob and produce

tmp_4 = glob
if ()
 a_1 = tmp_4
else
 if ()
   b_2 = tmp_4
 else
   c_3 = tmp4

all paths loaded glob before, so we can do this safely.

but if we had:

if ()
 a_1 = glob
else
 if ()
b_2 = notglob
 else
c_3 = glob

then we can no longer do anything since we'd be introducing a new load 
of 'glob' on the path that sets b_2 which wasn't performed before. If 
there was another load of glob somewhere before the first 'if', then 
commoning becomes possible again.


Some other cases won't be nearly so tricky, thankfully :-). I do think 
we need to do it in the optimizations because of some of the complex 
situations which can arise. We can at least try to do a good job and 
then punt if it gets too hard.


Now, thankfully, on most architectures we care about, hardware detection 
of data race loads isn't an issue.  So most of the time  its only the 
stores that we need to be careful about introducing new ones.  Im hoping 
the actual impact to codegen is low most of the time





I don't agree with your proposed command line options.  They seem fine
for internal use, but I think very very few users would know when or
whether they should use -fno-data-race-stores.  I think you should
  


I'm fine with alternatives. I'm focused mostly on the internals and I 
want an individual flag for each of those things to cleanly separate 
them out.  How we expose it I'm ambivalent about as long as testing can 
turn it them on and off individually. 

There will be people using software data race detectors which may want 
to be able to turn things on or off from the system default. I think 
-fmemory-model=   with options enabling at a minimum some form of 'off', 
'system default', and 'on' would probably work for external exposure.


Andrew

[Fwd: Cron nice ionice -n6 /home/bernie/bin/git-update-toolchain.sh]

[Bernie Innocenti]

Can we kill this empty branch from svn?

- Mensaje reenviado 
De: Cron Daemon 
Para: ber...@infradead.org
Asunto: Cron  nice ionice
-n6 /home/bernie/bin/git-update-toolchain.sh
Fecha: Thu, 06 May 2010 19:41:42 +

W: -empty_dir: branches/ibm/power7-meissner


-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

Re: Broken GCC mirror sites

[Krzysztof Żelechowski]

Dnia czwartek, 6 maja 2010 o 22:23:47 Holger Weiß napisał(a):
> * Krzysztof Zelechowski  [2010-05-06 22:00]:
> > Regarding your page "GCC mirror sites"
> > http://gcc.gnu.org/mirrors.html>:
> >
> > * ftp://ftp.fu-berlin.de/unix/languages/gcc/> is empty.
> 
> It's not.
> 
> > * ftp://ftp.gwdg.de/pub/misc/gcc/> is broken.
> 
> In what way?
> 
> > Please remove these entries.
> 
> Or just ask the mirror maintainers to fix the problem---if there is any.
> 
> Holger
> 

Sorry, it is a Konqueror problem then.
Chris

gcc-4.5-20100506 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 159136

You'll find:

gcc-4.5-20100506.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20100506.tar.bz2 C front end and core compiler

gcc-ada-4.5-20100506.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20100506.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20100506.tar.bz2  C++ front end and runtime

gcc-java-4.5-20100506.tar.bz2 Java front end and runtime

gcc-objc-4.5-20100506.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20100506.tar.bz2The GCC testsuite

Diffs from 4.5-20100429 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.

Re: [RFC] Introduce -Ofast

[Dave Korn]

On 06/05/2010 21:25, Ian Lance Taylor wrote:
> Richard Guenther  writes:
> 
>> This is a proposal to introduce an optimization level -Ofast
>> that can collect (target specific) optimization flags that
>> can affect runtime behavior such as -funsafe-math-optimizations
>> or -mrecip.
> 
> Sounds like a good idea to me.  I don't like the name -Ofast, which is
> ambiguous, but I see that there is precedent in the PathScale and PGI
> compilers.  I don't think a potentially confusing name is enough of a
> reason to buck the trend.

  Maybe then we should also add -Osmall and -Of, just to be thoroughly
symmetric and orthogonal :)

cheers,
  DaveK