IRA: matches insn even though !reload_in_progress
The following pattern shall be generated by insn combine
and then be split by pre-reload split:
(define_insn_and_split "*mulsqihi3.const"
[(set (match_operand:HI 0 "register_operand"
"=&r")
(mult:HI (sign_extend:HI (match_operand:QI 1
"register_operand" "a"))
(match_operand:HI 2 "u8_operand"
"n")))]
"AVR_HAVE_MUL
&& !reload_completed
&& !reload_in_progress"
{ gcc_unreachable(); }
"&& 1"
[(set (match_dup 3)
(match_dup 2))
; *mulsu
(mult:HI (sign_extend:HI (match_dup 1))
(zero_extend:HI (match_dup 3)))]
{
operands[3] = gen_reg_rtx (QImode);
})
All works, and in .asmcons insns look like that:
(insn 7 6 8 2 (set (reg:HI 48)
(const_int 155 [0x9b])) wmul.c:29 10 {*movhi}
(nil))
(insn 8 7 21 2 (set (reg:HI 46)
(mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
(reg:HI 48))) wmul.c:29 38 {*mulsqihi3}
(expr_list:REG_DEAD (reg:HI 48)
(expr_list:REG_DEAD (reg:QI 24 r24 [ x ])
(nil
IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
into the gcc_unreachable() even though !reload_in_progress etc should
keep IRA/reload from generating the insn.
After IRA/reload the code is:
(insn 8 6 21 2 (set (reg:HI 24 r24 [46])
(mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
(const_int 155 [0x9b]))) wmul.c:29 39 {*mulsqihi3.const}
(nil))
which of course must crash.
How do I write a pre-reload combine + pre-reload split correctly?
I'd like to avoid clobber reg.
Thanks much for any hint.
Johann
Re: IRA: matches insn even though !reload_in_progress
Georg-Johann Lay wrote:
> The following pattern shall be generated by insn combine
> and then be split by pre-reload split:
>
> (define_insn_and_split "*mulsqihi3.const"
> [(set (match_operand:HI 0 "register_operand"
> "=&r")
> (mult:HI (sign_extend:HI (match_operand:QI 1
> "register_operand" "a"))
> (match_operand:HI 2 "u8_operand"
> "n")))]
> "AVR_HAVE_MUL
>&& !reload_completed
>&& !reload_in_progress"
> { gcc_unreachable(); }
> "&& 1"
> [(set (match_dup 3)
> (match_dup 2))
>; *mulsu
>(mult:HI (sign_extend:HI (match_dup 1))
> (zero_extend:HI (match_dup 3)))]
> {
> operands[3] = gen_reg_rtx (QImode);
> })
>
> All works, and in .asmcons insns look like that:
>
> (insn 7 6 8 2 (set (reg:HI 48)
> (const_int 155 [0x9b])) wmul.c:29 10 {*movhi}
> (nil))
>
> (insn 8 7 21 2 (set (reg:HI 46)
> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
> (reg:HI 48))) wmul.c:29 38 {*mulsqihi3}
> (expr_list:REG_DEAD (reg:HI 48)
> (expr_list:REG_DEAD (reg:QI 24 r24 [ x ])
> (nil
>
> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
> into the gcc_unreachable() even though !reload_in_progress etc should
> keep IRA/reload from generating the insn.
>
> After IRA/reload the code is:
>
> (insn 8 6 21 2 (set (reg:HI 24 r24 [46])
> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
> (const_int 155 [0x9b]))) wmul.c:29 39 {*mulsqihi3.const}
> (nil))
>
> which of course must crash.
>
> How do I write a pre-reload combine + pre-reload split correctly?
> I'd like to avoid clobber reg.
This solution with (clobber (scratch:QI)) appears to work.
(clobber (match_scratch:QI 3 "=&d")) does not.
(define_insn_and_split "*mulsqihi3.const"
[(set (match_operand:HI 0 "register_operand" "=&r")
(mult:HI (sign_extend:HI (match_operand:QI 1
"register_operand" "a"))
(match_operand:HI 2 "u8_operand"
"n")))
(clobber (scratch:QI))]
"AVR_HAVE_MUL
&& !reload_completed
&& !reload_in_progress"
{ gcc_unreachable(); }
"&& 1"
[(set (match_dup 3)
(match_dup 2))
; *mulsu
(mult:HI (sign_extend:HI (match_dup 1))
(zero_extend:HI (match_dup 3)))]
{
if (SCRATCH == GET_CODE (operands[3]))
operands[3] = gen_reg_rtx (QImode);
})
Is that the correct approach?
Johann
Re: IRA: matches insn even though !reload_in_progress
Georg-Johann Lay wrote:
> Georg-Johann Lay wrote:
>> The following pattern shall be generated by insn combine
>> and then be split by pre-reload split:
>>
>> (define_insn_and_split "*mulsqihi3.const"
>> [(set (match_operand:HI 0 "register_operand"
>> "=&r")
>> (mult:HI (sign_extend:HI (match_operand:QI 1
>> "register_operand" "a"))
>> (match_operand:HI 2 "u8_operand"
>> "n")))]
>> "AVR_HAVE_MUL
>>&& !reload_completed
>>&& !reload_in_progress"
>> { gcc_unreachable(); }
>> "&& 1"
>> [(set (match_dup 3)
>> (match_dup 2))
>>; *mulsu
>>(mult:HI (sign_extend:HI (match_dup 1))
>> (zero_extend:HI (match_dup 3)))]
>> {
>> operands[3] = gen_reg_rtx (QImode);
>> })
>>
>> All works, and in .asmcons insns look like that:
>>
>> (insn 7 6 8 2 (set (reg:HI 48)
>> (const_int 155 [0x9b])) wmul.c:29 10 {*movhi}
>> (nil))
>>
>> (insn 8 7 21 2 (set (reg:HI 46)
>> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
>> (reg:HI 48))) wmul.c:29 38 {*mulsqihi3}
>> (expr_list:REG_DEAD (reg:HI 48)
>> (expr_list:REG_DEAD (reg:QI 24 r24 [ x ])
>> (nil
>>
>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
>> into the gcc_unreachable() even though !reload_in_progress etc should
>> keep IRA/reload from generating the insn.
>>
>> After IRA/reload the code is:
>>
>> (insn 8 6 21 2 (set (reg:HI 24 r24 [46])
>> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
>> (const_int 155 [0x9b]))) wmul.c:29 39 {*mulsqihi3.const}
>> (nil))
>>
>> which of course must crash.
>>
>> How do I write a pre-reload combine + pre-reload split correctly?
>> I'd like to avoid clobber reg.
>
> This solution with (clobber (scratch:QI)) appears to work.
> (clobber (match_scratch:QI 3 "=&d")) does not.
>
> (define_insn_and_split "*mulsqihi3.const"
> [(set (match_operand:HI 0 "register_operand" "=&r")
> (mult:HI (sign_extend:HI (match_operand:QI 1
> "register_operand" "a"))
> (match_operand:HI 2 "u8_operand"
> "n")))
>(clobber (scratch:QI))]
> "AVR_HAVE_MUL
>&& !reload_completed
>&& !reload_in_progress"
> { gcc_unreachable(); }
> "&& 1"
> [(set (match_dup 3)
> (match_dup 2))
>; *mulsu
>(mult:HI (sign_extend:HI (match_dup 1))
> (zero_extend:HI (match_dup 3)))]
> {
> if (SCRATCH == GET_CODE (operands[3]))
> operands[3] = gen_reg_rtx (QImode);
> })
>
> Is that the correct approach?
The answer it "no" because IRA does not synthesize the insn, but
reload fails to synthesize it, too.
So that pattern is just dead code :-(
Johann
announce: MELT plugin 0.8 for GCC 4.6
Hello All
It is my pleasure to announce the MELT plugin version 0.8 for GCC 4.6
(the Gnu Compiler Collection)
MELT is a domain specific language (and a plugin implementing it) for GCC
extensions.
The MELT language provides several high-level features (pattern-matching,
functional/object/reflective programming, ease of interface to GCC internals)
and is
translated to C.
MELT is a free software (GPLv3 licensed, FSF copyrighted).
###
NEWS for 0.8 MELT plugin for gcc-4.6
July 11th, 2011: Release of MELT plugin 0.8 for GCC 4.6
as melt-0.8-plugin-for-gcc-4.6 on http://gcc-melt.org/
New features:
* support for pragmas for MELT
* the MELT garbage collector is called less often, using the
PLUGIN_GGC_START hook.
* several new c-iterators and c-matchers.
* added static analyzing pass gccframe, useful for melt-runtime.c
* reject nested defun-s, you should use letrec or let...
* the MELT plugin is built with its MELT-Plugin-Makefile
* debug_msg, assert_msg ... should work, thanks to MELT_HAVE_DEBUG
preprocessor flag, even when melt.so is a plugin for a GCC without
checks enabled.
* melt-runtime.h has a melt_gcc_version integer variable and
melt-runtime.c should be given MELT_GCC_VERSION preprocessor
constant.
* runfile mode compiles quickly (with debug_msg support). Add new mode
translatequickly to compile quickly (with debug_msg & assert_msg
support).
* the MELT building procedure builds various variants of MELT modules,
The 'optimized' variant is built with -O2 but don't support
(debug_msg ...) or (assert_msg ...). The 'quicklybuilt' variant is
built with -O0 and supports debug_msg & assert_msg. The
'debugnoline' variant is mostly useful with gdb, and also supports
debug_msg & assert_msg. These variants should be interoperable, you
could have a warmelt* module with 'optimized' variant and an
xtramelt* module in 'quicklybuilt' bariant.
Many bugfixes
(but some bugs remain)
Thanks to Pierre Vittet for code contributions (notably thru Google
Summer of Code), Alexandre Lissy and Allan McRae for bug reports.
(MELT development is partly funded thru OpenGPU [FUI call] & GlobalGCC
[ITEA call] projects by French DGCIS).
###
The bugs reported in the various previous release candidates for MELT 0.8
plugin should
have been fixed.
--
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 mine, sont seulement les miennes} ***
Re: RTEMS Port of GCJ Progress Report
On 08/07/11 18:31, Jie Liu wrote: > This is the second report after “GCJ Porting for RTEMS Status > Report”[1]. During this time, I am > --- Focusing on running the testsuite and fix encountered problem > --- Submitting patches to related community > > In details, I have got the testsuite result for boehm-gc, libffi and > libjava, which can be seen in rtemsgcj project’s trunk[2]. For > problems encountered in boehm-gc, they are fixed under Ivan’s help, > and the problems can be seen in mailing list[3](Just search rtems for > related information). For problems encountered in libjava, I have send > a mail to java-patches[4], some problems have been fixed while others > still in fixing. > > The patches have been send to related communities, although libjava’s > patch still needs modify. OK. You have to address Bryce's concerns, but I'm happy for the patch to go in once you've done that. Looking at the test results, there are very serious problems with both threads and exceptions. Andrew.
Re: announce: MELT plugin 0.8 for GCC 4.6
Hello, I have been able to compile and install successfully (32 bits). I have modified the README to add that there is several libs to install (ppl, cloog, mpfr...). Pierre Vittet On Mon, 11 Jul 2011 14:15:33 +0200, Basile Starynkevitch wrote: > Hello All > > It is my pleasure to announce the MELT plugin version 0.8 for GCC 4.6 > (the Gnu Compiler Collection) > > MELT is a domain specific language (and a plugin implementing it) for > GCC extensions. > The MELT language provides several high-level features (pattern-matching, > functional/object/reflective programming, ease of interface to GCC > internals) and is > translated to C. > > MELT is a free software (GPLv3 licensed, FSF copyrighted). > ### > NEWS for 0.8 MELT plugin for gcc-4.6 > > July 11th, 2011: Release of MELT plugin 0.8 for GCC 4.6 > as melt-0.8-plugin-for-gcc-4.6 on http://gcc-melt.org/ > > > New features: > * support for pragmas for MELT > > * the MELT garbage collector is called less often, using the >PLUGIN_GGC_START hook. > > * several new c-iterators and c-matchers. > > * added static analyzing pass gccframe, useful for melt-runtime.c > > * reject nested defun-s, you should use letrec or let... > > * the MELT plugin is built with its MELT-Plugin-Makefile > > * debug_msg, assert_msg ... should work, thanks to MELT_HAVE_DEBUG >preprocessor flag, even when melt.so is a plugin for a GCC without >checks enabled. > > * melt-runtime.h has a melt_gcc_version integer variable and >melt-runtime.c should be given MELT_GCC_VERSION preprocessor >constant. > > * runfile mode compiles quickly (with debug_msg support). Add new mode >translatequickly to compile quickly (with debug_msg & assert_msg >support). > * the MELT building procedure builds various variants of MELT modules, > >The 'optimized' variant is built with -O2 but don't support >(debug_msg ...) or (assert_msg ...). The 'quicklybuilt' variant is >built with -O0 and supports debug_msg & assert_msg. The >'debugnoline' variant is mostly useful with gdb, and also supports >debug_msg & assert_msg. These variants should be interoperable, you >could have a warmelt* module with 'optimized' variant and an >xtramelt* module in 'quicklybuilt' bariant. > > Many bugfixes > (but some bugs remain) > > Thanks to Pierre Vittet for code contributions (notably thru Google > Summer of Code), Alexandre Lissy and Allan McRae for bug reports. > > (MELT development is partly funded thru OpenGPU [FUI call] & GlobalGCC > [ITEA call] projects by French DGCIS). > ### > > The bugs reported in the various previous release candidates for MELT > 0.8 plugin should > have been fixed. *** README-MELT-PLUGIN 2011-07-11 14:07:48.0 +0200 --- README-MELT-PLUGIN_MODIF2011-07-11 18:09:07.0 +0200 *** file is indeed the one related to your g *** 80,85 --- 80,94 step 3 + You need to install the following additionnal library to compile MELT (in dev version) : + - libgmp (>=4.3.2) + - libmpfr (>=2.4.2) + - libmpc (>=0.8.1) + - libppl (>=0.11) + - libcloog-ppl (0.15) or libcloog (>=0.16) + + step 4 + Your plugin MELT directory should contain a Makefile which is a symlink to a MELT-Plugin-Makefile file. Please look into that file. (Most of the work is done in melt-build.mk, included from it).
gcc bitfield order control
Hello
I have a build with a lot of structures in a big-endian style layout.
[I recognise that bit-fields are not portable due to their ordering
not being locally MSB first like the regular bit shift operation <<
is.i.e.(1<<2) == 4 ]
typedef struct reg32 {
union {
_uint32 REG32;
struct {
_uint32 BIT31:1;
_uint32 BIT30:1;
_uint32 BITS:30;
} B;
} R;
} reg32_t;
On a little-endian ARM build. Using :
arm-none-eabi-gcc (Sourcery G++ Lite 2010.09-51) 4.5.1
Writing reg.R.REG32 = 1, results in BIT31 containing 1. Rather than
the "1" being in the "BITS" field.
My thought is I'll need to swap every structure to be in little-endian
style ordering. Does anyone have any other ideas how to handle this
with gcc?
I was thinking to write a little program to make the changes to the header file.
Please include my email address in any replies.
Best regards, Jon
Re: IRA: matches insn even though !reload_in_progress
Sameera Deshpande wrote:
Please answer to the lists, thanks.
> Hi Johann,
>
> Try using clobber (match_operand:QI 3 "register_operand" "")
>
> gen_reg_rtx may not work in this case. Please have a look at
> define_split description in GCC the internal documents. It says: "The
> preparation-statements are similar to those statements that are
> specified for define_expand (see Expander Definitions) and are
> executed before the new RTL is generated to prepare for the generated
> code or emit some insns whose pattern is not fixed. Unlike those in
> define_expand, however, these statements must not generate any new
> pseudo-registers. Once reload has completed, they also must not
> allocate any space in the stack frame."
This is to be a pre-reload split as outlined by Michael Meissner in
"Upgrading your GCC port to use modern features" from GCC 2009 Summit.
gen_reg_rtx is ok in split1 which runs pre-reload and even with -O0.
All works fine except that IRA/reload does not respect the
!reload_in_progress && !reload_competed
insn condition.
Johann
> Hope this helps,
>
> - Thanks and regards,
> Sameera D
>
>
> **-Original Message-
> **From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> **Georg-Johann Lay
> **Sent: 11 July 2011 12:28
> **To: gcc@gcc.gnu.org
> **Subject: Re: IRA: matches insn even though !reload_in_progress
> **
> **Georg-Johann Lay wrote:
> **> Georg-Johann Lay wrote:
> **>> The following pattern shall be generated by insn combine
> **>> and then be split by pre-reload split:
> **>>
> **>> (define_insn_and_split "*mulsqihi3.const"
> **>> [(set (match_operand:HI 0 "register_operand"
> **>> "=&r")
> **>> (mult:HI (sign_extend:HI (match_operand:QI 1
> **>> "register_operand" "a"))
> **>> (match_operand:HI 2 "u8_operand"
> **>> "n")))]
> **>> "AVR_HAVE_MUL
> **>>&& !reload_completed
> **>>&& !reload_in_progress"
> **>> { gcc_unreachable(); }
> **>> "&& 1"
> **>> [(set (match_dup 3)
> **>> (match_dup 2))
> **>>; *mulsu
> **>>(mult:HI (sign_extend:HI (match_dup 1))
> **>> (zero_extend:HI (match_dup 3)))]
^^^
Bad typo, of course, but fixing it does not help, of course.
> **>> {
> **>> operands[3] = gen_reg_rtx (QImode);
> **>> })
> **>>
> **>> All works, and in .asmcons insns look like that:
> **>>
> **>> (insn 7 6 8 2 (set (reg:HI 48)
> **>> (const_int 155 [0x9b])) wmul.c:29 10 {*movhi}
> **>> (nil))
> **>>
> **>> (insn 8 7 21 2 (set (reg:HI 46)
> **>> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
> **>> (reg:HI 48))) wmul.c:29 38 {*mulsqihi3}
> **>> (expr_list:REG_DEAD (reg:HI 48)
> **>> (expr_list:REG_DEAD (reg:QI 24 r24 [ x ])
> **>> (nil
> **>>
> **>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc
> **runs
> **>> into the gcc_unreachable() even though !reload_in_progress etc
> **should
> **>> keep IRA/reload from generating the insn.
> **>>
> **>> After IRA/reload the code is:
> **>>
> **>> (insn 8 6 21 2 (set (reg:HI 24 r24 [46])
> **>> (mult:HI (sign_extend:HI (reg:QI 24 r24 [ x ]))
> **>> (const_int 155 [0x9b]))) wmul.c:29 39 {*mulsqihi3.const}
> **>> (nil))
> **>>
> **>> which of course must crash.
> **>>
> **>> How do I write a pre-reload combine + pre-reload split correctly?
> **>> I'd like to avoid clobber reg.
> **>
> **> This solution with (clobber (scratch:QI)) appears to work.
> **> (clobber (match_scratch:QI 3 "=&d")) does not.
> **>
> **> (define_insn_and_split "*mulsqihi3.const"
> **> [(set (match_operand:HI 0 "register_operand" "=&r")
> **> (mult:HI (sign_extend:HI (match_operand:QI 1
> **> "register_operand" "a"))
> **> (match_operand:HI 2 "u8_operand"
> **> "n")))
> **>(clobber (scratch:QI))]
> **> "AVR_HAVE_MUL
> **>&& !reload_completed
> **>&& !reload_in_progress"
> **> { gcc_unreachable(); }
> **> "&& 1"
> **> [(set (match_dup 3)
> **> (match_dup 2))
> **>; *mulsu
> **>(mult:HI (sign_extend:HI (match_dup 1))
> **> (zero_extend:HI (match_dup 3)))]
> **> {
> **> if (SCRATCH == GET_CODE (operands[3]))
> **> operands[3] = gen_reg_rtx (QImode);
> **> })
> **>
> **> Is that the correct approach?
> **
> **The answer it "no" because IRA does not synthesize the insn, but
> **reload fails to synthesize it, too.
> **
> **So that pattern is just dead code :-(
> **
> **Johann
> **
Re: IRA: matches insn even though !reload_in_progress
On 07/11/11 13:27, Georg-Johann Lay wrote: >>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs >>> into the gcc_unreachable() even though !reload_in_progress etc should >>> keep IRA/reload from generating the insn. That can't work because reload_in_progress isn't set during IRA. >> This solution with (clobber (scratch:QI)) appears to work. >> (clobber (match_scratch:QI 3 "=&d")) does not. You need to find out why. (clobber (scratch)) is meaningless. Bernd
Re: IRA: matches insn even though !reload_in_progress
Bernd Schmidt wrote:
> On 07/11/11 13:27, Georg-Johann Lay wrote:
IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
into the gcc_unreachable() even though !reload_in_progress etc should
keep IRA/reload from generating the insn.
>
> That can't work because reload_in_progress isn't set during IRA.
>
>>> This solution with (clobber (scratch:QI)) appears to work.
>>> (clobber (match_scratch:QI 3 "=&d")) does not.
>
> You need to find out why. (clobber (scratch)) is meaningless.
>
> Bernd
(clobber (scratch:QI))
is the RTX representation of (clobber (match_scratch:QI n "=&r"))
before register allocation. It's replaced by the split:
{
if (SCRATCH == GET_CODE (operands[3]))
operands[3] = gen_reg_rtx (QImode);
}
and after the split the scratch is gone and no clobber needed.
(clobber (match_operand:QI n "register_operand" "r"))
is not what I want because I do not want a combine-split, I want
combine + post-combine-pre-reload-split.
A combine-split will only work in certain circumstances, i.e. the
split pattern must have a specific anatomy and combine must come up
with a register. The combine-split is indication of split-point.
For a post-combine split, combine need not come up with a register and
the split can be more general. The drawback is that the new insns
can't be fed back into combine again.
In Michael Meissner's example there are only pure pre-reload splits
together with standard insns/expanders. But there is no example for
pre-reload split needing clobber and insn synthesized in combine pass.
Johann
Re: IRA: matches insn even though !reload_in_progress
Bernd Schmidt wrote:
> On 07/11/11 13:27, Georg-Johann Lay wrote:
IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
into the gcc_unreachable() even though !reload_in_progress etc should
keep IRA/reload from generating the insn.
>
> That can't work because reload_in_progress isn't set during IRA.
Ok, thanks.
I always wondered how to test for these thinks like ire_in_progress or
combine_completed.
Using current_pass->static_pass_number or ->name is nor really a good
idea...
I managed now to do a pre-reload split like so:
(define_insn_and_split "*mulhi3.uconst"
[(set (match_operand:HI 0 "register_operand" "=&r")
(mult:HI (match_operand:HI 1 "register_operand" "r")
(match_operand:HI 2 "u8_operand""n")))
(clobber (match_scratch:QI 3"=&d"))]
"AVR_HAVE_MUL"
"#"
"&& 1"
[(set (match_dup 3)
(match_dup 2))
; "*muluqihi3"
(set (match_dup 0)
(mult:HI (zero_extend:HI (match_dup 3))
(match_dup 1)))]
{
operands[2] = GEN_INT (trunc_int_for_mode (INTVAL (operands[2]),
QImode));
if (SCRATCH == GET_CODE (operands[3]))
operands[3] = gen_reg_rtx (QImode);
})
The dumps show that the split actually is done pre-reload :-)
However, suppose a test case like that:
int y15;
int ymul8_15 (int x, int y)
{
y15 = y * 15;
return x * 15;
}
The intention of the split is to do it as early as possible in order
for constants like 15 to be CSEd. However, the compile reads:
ymul8_15:
ldi r20,lo8(15) ; 32 *movqi/2[length = 1]
mul r20,r22 ; 33 *muluqihi3 [length = 5]
movw r18,r0
mul r20,r23
add r19,r0
clr __zero_reg__
sts y15+1,r19; 9 *movhi/3[length = 4]
sts y15,r18
movw r18,r24 ; 31 *movhi/1[length = 1]
ldi r20,lo8(15) ; 34 *movqi/2[length = 1]
mul r20,r18 ; 35 *muluqihi3 [length = 5]
movw r24,r0
mul r20,r19
add r25,r0
clr __zero_reg__
ret ; 38 return [length = 1]
Note insn 32 and insn 34.
Both get 15 in r20 and r20 is not clobbered anywhere. Yet, r20 is
loaded two times with 15.
The reason is that IRA (or reload, don't see it from the dumps)
combines the insns again to:
(insn 29 31 24 2 (parallel [
(set (reg:HI 24 r24 [49])
(mult:HI (reg:HI 18 r18)
(const_int 15 [0xf])))
(clobber (reg:QI 20 r20))
]) wmul.c:71 46 {*mulhi3.uconst}
(nil))
And then post-reload split splits again, giving the two sets.
Ideas?
I need the *insn so that combine can synthesize it, but IRA/reload
does mess up the nice code and undo the split.
Johann
Re: gcc bitfield order control
> Does anyone have any other ideas how to handle this with gcc? I started a thread on this a few months ago: http://gcc.gnu.org/ml/gcc/2011-07/msg00142.html I'll use this as an excuse to work in it today :-)
Re: gcc bitfield order control
On 11 July 2011 17:24, DJ Delorie wrote: > >> Does anyone have any other ideas how to handle this with gcc? > > I started a thread on this a few months ago: > > http://gcc.gnu.org/ml/gcc/2011-07/msg00142.html http://gcc.gnu.org/ml/gcc/2011-03/msg00112.html maybe? :) > I'll use this as an excuse to work in it today :-) >
Re: IRA: matches insn even though !reload_in_progress
On 07/11/11 18:12, Georg-Johann Lay wrote:
> The reason is that IRA (or reload, don't see it from the dumps)
> combines the insns again to:
>
> (insn 29 31 24 2 (parallel [
> (set (reg:HI 24 r24 [49])
> (mult:HI (reg:HI 18 r18)
> (const_int 15 [0xf])))
> (clobber (reg:QI 20 r20))
> ]) wmul.c:71 46 {*mulhi3.uconst}
> (nil))
Find out where it does that (breakpoint on make_insn_raw if the insn is
newly created; watchpoint on its PATTERN (insn->u.fld[4].rt_rtx I think)
otherwise.
Bernd
Re: C++ bootstrap of GCC - still useful ?
Eric Botcazou writes: >> The immediate blocker to using C++ in gcc is the Ada frontend. >> --enable-build-with-cxx and --enable-languages=ada do not work together. > > Could you elaborate? When I configure with --enable-build-with-cxx --enable-languages=c,c++,ada I get the appended. The problem is that the Ada code is looking for C symbol names but the names in the .o files are mangled for C++. Ian gcc -static-libgcc -o gnatbind ada/b_gnatb.o ada/adaint.o ada/argv.o ada/exit.o ada/cio.o ada/cstreams.o ada/env.o ada/final.o ada/init.o ada/initialize.o ada/seh_init.o ada/link.o ada/targext.o ada/raise.o ada/tracebak.o ada/ada.o ada/a-clrefi.o ada/a-comlin.o ada/a-elchha.o ada/a-except.o ada/ali-util.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/bcheck.o ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o ada/casing.o ada/csets.o ada/debug.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/fmap.o ada/fname.o ada/g-hesora.o ada/g-htable.o ada/s-os_lib.o ada/s-string.o ada/gnat.o ada/gnatbind.o ada/gnatvsn.o ada/hostparm.o ada/interfac.o ada/lib.o ada/namet.o ada/nlists.o ada/opt.o ada/osint-b.o ada/osint.o ada/output.o ada/rident.o ada/s-addope.o ada/s-assert.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-parame.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strhas.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scng.o ada/scans.o ada/scil_ll.o ada/sdefault.o ada/sem_aux.o ada/sinfo.o ada/sinput.o ada/sinput-c.o ada/snames.o ada/stand.o ada/stringt.o ada/switch-b.o ada/switch.o ada/style.o ada/styleg.o ada/stylesw.o ada/system.o ada/table.o ada/targparm.o ada/tree_io.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/widechar.o ggc-none.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -g ada/b_gnatb.o: In function `adainit': /home/ian/gcc/build-with-cxx-ada/gcc/ada/b_gnatb.adb:122: undefined reference to `__gnat_install_handler' ada/b_gnatb.o: In function `main': /home/ian/gcc/build-with-cxx-ada/gcc/ada/b_gnatb.adb:250: undefined reference to `__gnat_initialize' /home/ian/gcc/build-with-cxx-ada/gcc/ada/b_gnatb.adb:255: undefined reference to `__gnat_finalize' ada/init.o: In function `__gnat_error_handler': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/init.c:661: undefined reference to `ada__exceptions__raise_from_signal_handler(Exception_Data*, char const*)' ada/a-comlin.o: In function `ada__command_line__argument': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-comlin.adb:75: undefined reference to `__gnat_len_arg' /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-comlin.adb:77: undefined reference to `__gnat_fill_arg' ada/a-comlin.o: In function `ada__command_line__argument_count': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-comlin.adb:94: undefined reference to `__gnat_arg_count' ada/a-comlin.o: In function `ada__command_line__command_name': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-comlin.adb:123: undefined reference to `__gnat_len_arg' /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-comlin.adb:126: undefined reference to `__gnat_fill_arg' ada/a-elchha.o: In function `__gnat_last_chance_handler': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-elchha.adb:137: undefined reference to `__gnat_unhandled_terminate' ada/a-except.o: In function `__gnat_to_stderr_char': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-except.adb:1314: undefined reference to `put_char_stderr' ada/a-except.o: In function `ada__exceptions__process_raise_exception': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/a-except.adb:748: undefined reference to `_gnat_builtin_longjmp' ada/fmap.o: In function `fmap__update_mapping_file': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/fmap.adb:498: undefined reference to `__gnat_lseek' ada/s-os_lib.o: In function `system__os_lib__copy_file': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/s-os_lib.adb:569: undefined reference to `__gnat_lseek' ada/s-os_lib.o: In function `system__os_lib__copy_file__copy_to': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/s-os_lib.adb:482: undefined reference to `__gnat_copy_attribs' /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/s-os_lib.adb:487: undefined reference to `__gnat_copy_attribs' ada/s-os_lib.o: In function `system__os_lib__copy_time_stamps': /home/ian/gcc/build-with-cxx-ada/gcc/../../trunk/gcc/ada/s-os_lib.adb:637: undefined reference t
Re: IRA: matches insn even though !reload_in_progress
On 07/11/11 18:42, Bernd Schmidt wrote:
> On 07/11/11 18:12, Georg-Johann Lay wrote:
>> The reason is that IRA (or reload, don't see it from the dumps)
>> combines the insns again to:
>>
>> (insn 29 31 24 2 (parallel [
>> (set (reg:HI 24 r24 [49])
>> (mult:HI (reg:HI 18 r18)
>> (const_int 15 [0xf])))
>> (clobber (reg:QI 20 r20))
>> ]) wmul.c:71 46 {*mulhi3.uconst}
>> (nil))
>
> Find out where it does that (breakpoint on make_insn_raw if the insn is
> newly created; watchpoint on its PATTERN (insn->u.fld[4].rt_rtx I think)
> otherwise.
Ok, so I'm guessing it's the validate_replace_rtx call in
update_equiv_regs. If I understand correctly, you're doing this to get
the constant CSEd - is that right? If so, have you tried using an
expander rather than a split (no CSE passes after combine)?
Bernd
Re: C++ bootstrap of GCC - still useful ?
> When I configure with > --enable-build-with-cxx --enable-languages=c,c++,ada > I get the appended. The problem is that the Ada code is looking for C > symbol names but the names in the .o files are mangled for C++. Right, or rather than we want to use the C compiler to compile all those files (e.g. init.c, argv.c), not the C++ compiler. Arno
Re: C++ bootstrap of GCC - still useful ?
On Jul 11, 2011, at 12:53 PM, Arnaud Charlet wrote: >> When I configure with >>--enable-build-with-cxx --enable-languages=c,c++,ada >> I get the appended. The problem is that the Ada code is looking for C >> symbol names but the names in the .o files are mangled for C++. > > Right, or rather than we want to use the C compiler to compile all those > files (e.g. init.c, argv.c), not the C++ compiler. Isn't 'extern "C" ' the standard way to handle this sort of thing? paul
Re: IRA: matches insn even though !reload_in_progress
Bernd Schmidt wrote:
> On 07/11/11 18:42, Bernd Schmidt wrote:
>> On 07/11/11 18:12, Georg-Johann Lay wrote:
>>> The reason is that IRA (or reload, don't see it from the dumps)
>>> combines the insns again to:
>>>
>>> (insn 29 31 24 2 (parallel [
>>> (set (reg:HI 24 r24 [49])
>>> (mult:HI (reg:HI 18 r18)
>>> (const_int 15 [0xf])))
>>> (clobber (reg:QI 20 r20))
>>> ]) wmul.c:71 46 {*mulhi3.uconst}
>>> (nil))
>> Find out where it does that (breakpoint on make_insn_raw if the insn is
>> newly created; watchpoint on its PATTERN (insn->u.fld[4].rt_rtx I think)
>> otherwise.
>
> Ok, so I'm guessing it's the validate_replace_rtx call in
> update_equiv_regs. If I understand correctly, you're doing this to get
> the constant CSEd - is that right? If so, have you tried using an
> expander rather than a split (no CSE passes after combine)?
>
> Bernd
Ya, it's to get potential duplicate constants CSEd out.
I see now. In this particular case I could use an expander because
it's a standard insn.
However, I have also cases where it is not a standard insn like
(define_insn_and_split "*mulsqihi3.sconst"
[(set (match_operand:HI 0 "register_operand" "=r")
(mult:HI (sign_extend:HI (match_operand:QI 1
"register_operand" "r"))
(match_operand:HI 2 "s8_operand"
"Cs8")))
(clobber (match_scratch:QI 3 "=&d"))]
I started some hacking:
avr.c:
#include "tree-pass.h"
bool
avr_gate_split1 (void)
{
if (current_pass->static_pass_number
< pass_match_asm_constraints.pass.static_pass_number)
return true;
return false;
}
And the splitter:
(define_insn_and_split "*mulsqihi3.sconst"
[(set (match_operand:HI 0 "register_operand" "=&r")
(mult:HI (sign_extend:HI (match_operand:QI 1
"register_operand" "d"))
(match_operand:HI 2 "s8_operand"
"Cs8")))
(clobber (match_scratch:QI 3 "=&d"))]
"AVR_HAVE_MUL
&& avr_gate_split1()"
"#"
"&& 1"
[(set (match_dup 3)
(match_dup 2))
; *muls
(set (match_dup 0)
(mult:HI (sign_extend:HI (match_dup 1))
(sign_extend:HI (match_dup 3]
{
operands[2] = GEN_INT (trunc_int_for_mode (INTVAL (operands[2]),
QImode));
if (SCRATCH == GET_CODE (operands[3]))
operands[3] = gen_reg_rtx (QImode);
})
It works!
Test case:
int y15;
int x15;
void cmul_15 (char x, char y)
{
y15 = y * 15;
x15 = x * 15;
}
Without the gate, the 15 is loaded 2 times and with the gate just once.
So the question is:
Can this be done without the hack?
Or is avr_gate_split1 something that is ok to commit?
Johann
Re: C++ bootstrap of GCC - still useful ?
On Mon, Jul 11, 2011 at 11:53 AM, Arnaud Charlet wrote: >> When I configure with >> --enable-build-with-cxx --enable-languages=c,c++,ada >> I get the appended. The problem is that the Ada code is looking for C >> symbol names but the names in the .o files are mangled for C++. > > Right, or rather than we want to use the C compiler to compile all those > files (e.g. init.c, argv.c), not the C++ compiler. Do you want a C compiler for that, or do you in fact just need an extern "C" language specification for those symbols? I would have thought the latter. -- Gaby
Re: gcc bitfield order control
> > http://gcc.gnu.org/ml/gcc/2011-07/msg00142.html > > http://gcc.gnu.org/ml/gcc/2011-03/msg00112.html maybe? :) Yes, that one. Had both windows open :-P
A visualization of GCC's passes, as a subway map
For fun over the weekend I wrote a python script (using my gcc-python-plugin[1]) to render an SVG diagram of GCC's optimization passes (or, at least, based on my understanding of them). This diagram shows the various GCC optimization passes, arranged vertically, showing child passes via indentation. The lifetime of the various properties that they maintain is shown, giving the pass that initially creates the data (if any), the pass that destroys it (if any), and each pass that requires a particular property (based on the PROP_* flags). I've attempted to make it look a little like a subway train schematic map, where the properties are train lines, and the passes are the stations they stop at; the initial/final passes are the termini. The resulting SVG can be seen at the top of: http://readthedocs.org/docs/gcc-python-plugin/en/latest/tables-of-passes.html Direct link to SVG, in case the above gets mangled on your browser: http://readthedocs.org/docs/gcc-python-plugin/en/latest/_images/passes.svg (550 x 3302 pixels; about 250k in size). The script can be seen here (it uses pycairo to abstract the drawing operations): http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=generate-passes-svg.py Hope this is fun/helpful (and that I'm correctly interpreting the data!) Dave [1] https://fedorahosted.org/gcc-python-plugin/
Re: Bug#629142: autogen: FTBFS: Various aborts
On 07/11/11 10:14, Kurt Roeckx wrote: That means that hurd has a non-standard definition for _IOWR. #ifdef HURD #define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t) #endif 5.12 still failed with the same error message. Then "HURD" is not #defined in hurd. I had to read glibc/gcc source code to tease out that name, but I guess I read wrong. What _is_ the #define that says the compile is for hurd? On other platforms, the _IOWR macro just works. HURD itself is broken. I've been told it's __GNU__ I would surely hope not. The reason being is that there is this campaign on to get everyone to use GNU/Linux as the name of the platform commonly referred to as "Linux". If __GNU__ were used to mean "GNU/Hurd", then it would severely muddy the waters about what is meant by GNU. So, please tell me the marker is __hurd__ (or some variation) and not __GNU__. It would be _so_ wrong. Perhaps it is __gnu_hurd__ ?? It would be *really* *cool* if there were a page lying around somewhere that one could reference. Here are the results of grepping the entire gcc compiler source tree: $ find * -type f|fgrep -v '/.svn/' | xargs egrep -i $'^[ \t]*#[ \t]*if.*hurd' boehm-gc/include/private/gcconfig.h:# ifdef HURD boehm-gc/os_dep.c:#if defined(IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# if defined(IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# ifdef HURD boehm-gc/os_dep.c:# if defined(HURD) boehm-gc/os_dep.c:# if defined (IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# if defined(_sigargs) || defined(HURD) || !defined(SA_SIGINFO) boehm-gc/os_dep.c:# if defined(HPUX) || defined(LINUX) || defined(HURD) \ boehm-gc/os_dep.c:# if defined(HURD) gcc/testsuite/gcc.dg/cpp/assert4.c:#if defined __gnu_hurd__ It takes a long time.
Re: C++ bootstrap of GCC - still useful ?
On 07/10/2011 11:20 PM, Laurent GUERBY wrote: On Sun, 2011-07-10 at 20:03 +0200, Toon Moene wrote: Last month I got past year's electricity bill - it turns out that I am now (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) using 3200 KWh a year - to the tune of 1100 Euros. So the question whether a run is useful is certainly relevant :-) Since I pay the electricity bill of some compile farm machines I understand you here :). New generation of hardware has made significant progress on energy efficiency: my latest built PC is a Intel core i7 2600 4 cores 8 threads 3.4 GHz 4x4 GB of RAM with 40 GB SSD + 2TB HDD, 80+ gold PSU and it idles around 30W and uses 110W full CPU load. PC cost is around 800 EUR in France (19.6% VAT included). According to your data it should reduce your bill by a factor of three (365W => 110W), so it should pay itself in around a year: 720 EUR less on your yearly electricity bill, assuming you counted only your PC power consumption in your figures. And bonus nearly no noise in a case with 2 or 3 120mm fans. I haven't had a chance to test AMD A8 processors but I will do soon. One of the most frustrating aspects of this is that I cannot just write an Invitation To Tender for a 1000-1200 Euro PC (I have been involved with that process for KNMI's High Performance Computer now for over 15 years). If I could do that, I would be able to: 1) Choose from several vendors. 2) Evaluate both "speed-of-execution" and "energy-efficiency" in a consistent way. 3) Evaluate the use of AMD vs Intel processors independent of the vendor of choice. 4) Get the vendor to install the Operating-System-of-choice (Debian Testing) and run my benchmarks, so that I'll be able to check their assumptions. Instead, what I am currently doing to plan the replacement of the 2007 vintage machine that runs just two feet away from me, is to: 1) Gather information about upcoming Intel and AMD CPU's. 2) Estimate when they will hit the "Home and Small Business Market". 3) Hope that such a machine will indeed be priced between 1000-1200 Euro's. 4) Hope that the vendor who delivered me the current machine will have a competitive offer (note that I want to stay with my current vendor - I yet have to see another PC vendor making a machine that's obviously geared towards teenagers storing bittorrent-downloaded movies, that actually is able to work 16 hours+ per day on *real science* at full capacity without breaking down after years of service). Sigh. -- 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/wiki/GFortran#news
Re: C++ bootstrap of GCC - still useful ?
> When I configure with > --enable-build-with-cxx --enable-languages=c,c++,ada > I get the appended. The problem is that the Ada code is looking for C > symbol names but the names in the .o files are mangled for C++. OK, this is known: a couple of tweaks to the Makefile (to use g++ instead of gcc to link) are needed and extern "C" must be added all over the place, see: http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html I can post an updated patch if you want, but saying that the Ada front-end blocks the use of C++ in gcc is unfair; it is (and has always been) neutral. -- Eric Botcazou
Re: C++ bootstrap of GCC - still useful ?
Eric Botcazou writes: >> When I configure with >> --enable-build-with-cxx --enable-languages=c,c++,ada >> I get the appended. The problem is that the Ada code is looking for C >> symbol names but the names in the .o files are mangled for C++. > > OK, this is known: a couple of tweaks to the Makefile (to use g++ instead of > gcc to link) are needed and extern "C" must be added all over the place, see: > http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html > > I can post an updated patch if you want, but saying that the Ada front-end > blocks the use of C++ in gcc is unfair; it is (and has always been) neutral. My apologies, I didn't mean to attack. I tried it, and it failed building Ada. That's all I meant. If there is an up to date patch, I'm happy to review it if it would help. But perhaps an Ada maintainer would prefer to do the review, I don't know what the usual policy is as I've never approved an Ada patch. I have a patch ready to go which would use C++ in stages 2 and 3. I can't propose that patch right now because it fails when building Ada. If we get Ada fixed, I will propose it. Ian
Re: C++ bootstrap of GCC - still useful ?
> If there is an up to date patch, I'm happy to review it if it would > help. But perhaps an Ada maintainer would prefer to do the review, I > don't know what the usual policy is as I've never approved an Ada patch. The patch is here: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00845.html > I have a patch ready to go which would use C++ in stages 2 and 3. I > can't propose that patch right now because it fails when building Ada. > If we get Ada fixed, I will propose it. OK, let's fix --enable-build-with-cxx with Ada. Thanks for clarifying. -- Eric Botcazou
Re: C++ bootstrap of GCC - still useful ?
Eric Botcazou writes: >> If there is an up to date patch, I'm happy to review it if it would >> help. But perhaps an Ada maintainer would prefer to do the review, I >> don't know what the usual policy is as I've never approved an Ada patch. > > The patch is here: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00845.html Thanks. I'm not sure that always setting LINKER=$(CXX) in gnattools/Makefile.in is correct. It seems to me that that should vary based on --enable-build-with-cxx, as is done in gcc/Makefile.in. But I don't know much about building Ada, and perhaps this is right. Otherwise the patch looks fine to me, for whatever that is worth. Ian
Re: C++ bootstrap of GCC - still useful ?
> I'm not sure that always setting LINKER=$(CXX) in gnattools/Makefile.in > is correct. It seems to me that that should vary based on > --enable-build-with-cxx, as is done in gcc/Makefile.in. But I don't > know much about building Ada, and perhaps this is right. Good catch, thanks, will fix. -- Eric Botcazou
Re: C++ bootstrap of GCC - still useful ?
On Mon, 2011-07-11 at 13:58 -0700, Ian Lance Taylor wrote: > Eric Botcazou writes: > > >> If there is an up to date patch, I'm happy to review it if it would > >> help. But perhaps an Ada maintainer would prefer to do the review, I > >> don't know what the usual policy is as I've never approved an Ada patch. > > > > The patch is here: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00845.html > > Thanks. > > I'm not sure that always setting LINKER=$(CXX) in gnattools/Makefile.in > is correct. It seems to me that that should vary based on > --enable-build-with-cxx, as is done in gcc/Makefile.in. But I don't > know much about building Ada, and perhaps this is right. Hi, Paolo did suggest something like that: http://gcc.gnu.org/ml/gcc/2009-06/msg00639.html << I think you should rather do "CC=../../xgcc -B../../" \ + "CXX=../../g++ -B../../" \ "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \ + "CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS)" \ and copy the setting of COMPILER and LINKER from gcc/Makefile.in into gcc/ada/gcc-interface/Makefile.in: ENABLE_BUILD_WITH_CXX = @ENABLE_BUILD_WITH_CXX@ ifneq ($(ENABLE_BUILD_WITH_CXX),yes) COMPILER = $(CC) COMPILER_FLAGS = $(CFLAGS) LINKER = $(CC) LINKER_FLAGS = $(CFLAGS) else COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) LINKER = $(CXX) LINKER_FLAGS = $(CXXFLAGS) endif Paolo >> Now I don't know if we intend to support build without CXX in the near future :). Sincerely, Laurent
Re: A visualization of GCC's passes, as a subway map
2011/7/12 David Malcolm : > For fun over the weekend I wrote a python script (using my > gcc-python-plugin[1]) to render an SVG diagram of GCC's optimization > passes (or, at least, based on my understanding of them). > > This diagram shows the various GCC optimization passes, arranged > vertically, showing child passes via indentation. Interesting. I also have a plugin (http://code.google.com/p/gcc-vcg-plugin) which can be used to dump the gcc pass lists in vcg format. Cheers, Mingjie
Re: C++ bootstrap of GCC - still useful ?
> Paolo did suggest something like that: > > http://gcc.gnu.org/ml/gcc/2009-06/msg00639.html > << > I think you should rather do > > "CC=../../xgcc -B../../" \ > + "CXX=../../g++ -B../../" \ > "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \ > + "CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS)" \ > > and copy the setting of COMPILER and LINKER from gcc/Makefile.in into > gcc/ada/gcc-interface/Makefile.in: > > ENABLE_BUILD_WITH_CXX = @ENABLE_BUILD_WITH_CXX@ > ifneq ($(ENABLE_BUILD_WITH_CXX),yes) > COMPILER = $(CC) > COMPILER_FLAGS = $(CFLAGS) > LINKER = $(CC) > LINKER_FLAGS = $(CFLAGS) > else > COMPILER = $(CXX) > COMPILER_FLAGS = $(CXXFLAGS) > LINKER = $(CXX) > LINKER_FLAGS = $(CXXFLAGS) > endif I'm not sure because I don't think we want to compile the C files of the Ada runtime with the C++ compiler. We want to do that only for the compiler. -- Eric Botcazou
Re: C++ bootstrap of GCC - still useful ?
> I'm not sure because I don't think we want to compile the C files of the Ada > runtime with the C++ compiler. We want to do that only for the compiler. Right, we definitely don't want to use the C++ compiler for building the Ada run-time. Arno
