Re: GCC 4.7.0RC: Mangled names in cc1
Hi, Gabriel Dos Reis skribis: > On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès > wrote: [...] >> What about writing it in C++? Function objects could be passed around >> to achieve a similar result, at the expense of conciseness and >> interoperability with C. > > Does not compute. If you are using nested functions, you are not > interested in C interoperability in the first place. Sorry, I meant GNU C. Ludo’.
Re: GCC 5 & modularity
On Mar 19, 2012 5:56 AM, "Basile Starynkevitch" wrote: > > On Sun, 18 Mar 2012 20:49:24 + > Jonathan Wakely wrote: > > > On 18 March 2012 16:56, Basile Starynkevitch wrote: > > > > > > * a garbage collector. Even a modular GCC need some memory management > > > policy (and > > > ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside > > > a compiler > > > because a compiler has much more complex and circular data structures, > > > and much less > > > hierarchically organized, that a graphical tookit has). > > > > As has been pointed out to you before, shared_ptr is designed to be > > useful even with circular structures. Please read about weak_ptr. > > > Then why has it not being used before? I don't understand the question. Are you asking why shared_ptr hasn't been used in GCC before? Surely that's obvious, the GCC code is still written in C and no C++ templates have been introduced to the code yet. Maybe shared_ptr isn't the right tool for memory management in GCC, but if it's rejected then I hope it will be for valid reasons, not because of misinformation about being unsuitable for code with circular references.
Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)
On Fri, Mar 16, 2012 at 6:19 PM, David Malcolm wrote: > It seems that GCC has provided an API for registering plugins, but no > API for the plugins to then actually use... Perhaps the C++ move would > be alleviated by having an actually C API for plugins to use? I started > writing a possible API for plugins, the idea being to port my python > plugin to this as a middle layer, but it strikes me that this could also > be used for the embedding case as well. So perhaps the first step might > be to implement the plugin API, and that could evolve into the > inter-library API that the different parts of a more modular GCC could > use to talk to each other? > > The proposed API might look like this: > > /* > Pure C for maximum compatibility > All macros begin with a "GCC_" prefix > All symbols begin with a "gcc_" prefix with _ separators, though I > happen to prefer the CPython style (e.g. "GccBasicBlock_GetIndex"); > bikeshed away! > (You may only call such a symbol when you have the Big GCC Lock?) > All types begin with a "gcc_" prefix (again, I'd prefer CPython style > e.g. "struct GccBasicBlock"). > How acceptable is it to autogenerate parts of the API? (this is what > I do in my python plugin; naturally I use python for this). > */ > > /* Compatibility macros: */ > #define GCC_API(RETURN_TYPE) extern RETURN_TYPE > > /* All types are opaque; internally these might simply embed one of > gcc's real types as its single field; integration with GC could be > interesting though: */ > typedef struct gcc_cfg gcc_cfg; > typedef struct gcc_basic_block gcc_basic_block; > typedef struct gcc_edge gcc_edge; > > /* Declarations: control flow graphs */ > > /* gcc_cfg: */ > GCC_API(gcc_basic_block *) > gcc_cfg_get_entry(gcc_cfg *cfg); > > GCC_API(gcc_basic_block *) > gcc_cfg_get_exit(gcc_cfg *cfg); > > /* gcc_basic_block: */ > GCC_API(int) > gcc_basic_block_get_index(const gcc_basic_block *bb); > > /* gcc_edge: */ > GCC_API(gcc_basic_block *) > gcc_edge_get_src(gcc_edge *e); > > GCC_API(gcc_basic_block *) > gcc_edge_get_dest(gcc_edge *e); > > /* ...etc... */ > Yes, I think we desperately need something like the above. And I was strongly against our current "plugin API" because of all the reasons you cite. But it seems that the people driving plugins meant that plugins should be able to do everything an embedded GCC pass can do. I think an API like you propose with clear direction towards 1) providing simple and forward-compatible ways of, first of all _introspection_ (to make static analyses possible) 2) and _instrumentation_ (to make dynamic analyses possible) and not for implementing everything that GCC can (that will be never forward/backward compatible). The above should eventually be possible on the different IL kinds GCC has, but first and foremost targeting plain GIMPLE (+ SSA) plus the CFG and the CGRAPH parts should be enough. Providing python/guile/whatever bindings for such simple(!) C plugin API should then eventually embedded into GCC itself. But no, I'm not volunteering (I'm volunteering to do the review work). The above has the same issue as the "we-want-to-be-more-like-LLVM" stuff - it lacks the people to actually implement it, and GCC at its present state still has to evolve, we can't and do not want to just spend a complete release or two with just turning GCC upside-down. Richard.
Re: subreg:HI of PSI HW register issue
> On 03/09/2012 11:20 AM, Aurelien Buhrig wrote: >> Hi, >> >> It seems there is an issue around subreg:HI of PSI hardware register, >> which occurs either during expand or reload (GCC 4.6.1). >> >> For my big endian target, >> (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but >> (subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO). > >> - Is it correct that gcc emits such a subreg pattern in Pmode=PSI during >> expand ? Or should it be in ptr_mode=SImode (in this case, both >> (subreg:HI (reg:SI) 0/2) are representable)? > > This, I think. I have a port with a rather similar situation, and I'm > betting you also have a failure in gcc.c-torture/execute/20040625-1.c. I > don't want to promise anything but I may have something for you next > week-ish. > > > Bernd Hi Bernd, Any update on this? Thanks, Aurélien
Re: GCC 4.7.0RC: Mangled names in cc1
On Mon, Mar 19, 2012 at 4:57 AM, Ludovic Courtès wrote: > Hi, > > Gabriel Dos Reis skribis: > >> On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès >> wrote: > > [...] > >>> What about writing it in C++? Function objects could be passed around >>> to achieve a similar result, at the expense of conciseness and >>> interoperability with C. >> >> Does not compute. If you are using nested functions, you are not >> interested in C interoperability in the first place. > > Sorry, I meant GNU C. Interoperability is a two-way street; it means you have to live in the intersection understood by both languages. -- Gaby
Re: GCC 5 & modularity
On Mon, Mar 19, 2012 at 12:56 AM, Basile Starynkevitch wrote: > On Sun, 18 Mar 2012 20:49:24 + > Jonathan Wakely wrote: > >> On 18 March 2012 16:56, Basile Starynkevitch wrote: >> > >> > * a garbage collector. Even a modular GCC need some memory management >> > policy (and >> > ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a >> > compiler >> > because a compiler has much more complex and circular data structures, and >> > much less >> > hierarchically organized, that a graphical tookit has). >> >> As has been pointed out to you before, shared_ptr is designed to be >> useful even with circular structures. Please read about weak_ptr. > > > Then why has it not being used before? by whom? where? -- Gaby
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
>
> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>
> A second release candidate for GCC 4.7.0 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
>
> and shortly its mirrors. It has been generated from SVN revision 185376.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux. Please test it and report any issues to bugzilla.
i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
#include
#include
#include
typedef boost::shared_ptr HString;
typedef std::map StrAttribsT;
StrAttribsT m_str_attribs;
void foo(const char* attribName, const char* value)
{
m_str_attribs.insert(std::make_pair(attribName, new
std::string(value)));
}
it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
is it an effect of 'name lookup changes'?
(http://gcc.gnu.org/gcc-4.7/porting_to.html)
BR,
Paweł.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
2012/3/19 Paweł Sikora:
> On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
>>
>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>
>> A second release candidate for GCC 4.7.0 is available from
>>
>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
>>
>> and shortly its mirrors. It has been generated from SVN revision 185376.
>>
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux. Please test it and report any issues to bugzilla.
>
> i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
>
> #include
> #include
> #include
>
> typedef boost::shared_ptr HString;
> typedef std::map StrAttribsT;
> StrAttribsT m_str_attribs;
>
> void foo(const char* attribName, const char* value)
> {
> m_str_attribs.insert(std::make_pair(attribName, new
> std::string(value)));
> }
>
> it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
> is it an effect of 'name lookup changes'?
> (http://gcc.gnu.org/gcc-4.7/porting_to.html)
No, the change is in how std::pair is constructed, the code can be reduced to:
#include
#include
typedef boost::shared_ptr HString;
void foo(const char* attribName)
{
const std::pair a
= std::make_pair(attribName, new std::string);
}
Probably caused by http://gcc.gnu.org/viewcvs?view=revision&revision=174464
I haven't looked in enough detail to see if the change in behaviour is
correct or a regression.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
2012/3/19 Jonathan Wakely :
> 2012/3/19 Paweł Sikora:
>> On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
>>>
>>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>>
>>> A second release candidate for GCC 4.7.0 is available from
>>>
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
>>>
>>> and shortly its mirrors. It has been generated from SVN revision 185376.
>>>
>>> I have so far bootstrapped and tested the release candidate on
>>> x86_64-linux. Please test it and report any issues to bugzilla.
>>
>> i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
>>
>> #include
>> #include
>> #include
>>
>> typedef boost::shared_ptr HString;
>> typedef std::map StrAttribsT;
>> StrAttribsT m_str_attribs;
>>
>> void foo(const char* attribName, const char* value)
>> {
>> m_str_attribs.insert(std::make_pair(attribName, new
>> std::string(value)));
>> }
>>
>> it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
>> is it an effect of 'name lookup changes'?
>> (http://gcc.gnu.org/gcc-4.7/porting_to.html)
>
> No, the change is in how std::pair is constructed, the code can be reduced to:
>
> #include
> #include
>
> typedef boost::shared_ptr HString;
>
> void foo(const char* attribName)
> {
> const std::pair a
> = std::make_pair(attribName, new std::string);
> }
>
> Probably caused by http://gcc.gnu.org/viewcvs?view=revision&revision=174464
>
> I haven't looked in enough detail to see if the change in behaviour is
> correct or a regression.
My guess is that the new behaviour is correct, because the relevant
constructor of boost::shared_ptr is 'explicit' but you're relying on
an implicit conversion from pair to
pair> which implicitly converts a raw
pointer to a shared_ptr.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
Hi,
On 03/19/2012 01:38 PM, Jonathan Wakely wrote:
2012/3/19 Jonathan Wakely:
2012/3/19 Paweł Sikora:
On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
and shortly its mirrors. It has been generated from SVN revision 185376.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
#include
#include
#include
typedef boost::shared_ptr HString;
typedef std::map StrAttribsT;
StrAttribsT m_str_attribs;
void foo(const char* attribName, const char* value)
{
m_str_attribs.insert(std::make_pair(attribName, new
std::string(value)));
}
it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
is it an effect of 'name lookup changes'?
(http://gcc.gnu.org/gcc-4.7/porting_to.html)
No, the change is in how std::pair is constructed, the code can be reduced to:
#include
#include
typedef boost::shared_ptr HString;
void foo(const char* attribName)
{
const std::pair a
= std::make_pair(attribName, new std::string);
}
Probably caused by http://gcc.gnu.org/viewcvs?view=revision&revision=174464
I haven't looked in enough detail to see if the change in behaviour is
correct or a regression.
My guess is that the new behaviour is correct, because the relevant
constructor of boost::shared_ptr is 'explicit' but you're relying on
an implicit conversion from pair to
pair> which implicitly converts a raw
pointer to a shared_ptr.
Probably, yes. We should double check your analysis (thanks!)
In 4.7 we indeed have much more constraining in std::pair, but first
blush it's correct, per C++11 I mean (there is also the DR about using
is_constructible instead of is_convertible in std::map, still
unimplemented, but I don't think it's related and goes beyond C++11 anyway)
Paolo.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
2012/3/19 Jonathan Wakely :
> 2012/3/19 Jonathan Wakely :
>> 2012/3/19 Paweł Sikora:
>>> On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
and shortly its mirrors. It has been generated from SVN revision 185376.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
>>>
>>> i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> typedef boost::shared_ptr HString;
>>> typedef std::map StrAttribsT;
>>> StrAttribsT m_str_attribs;
>>>
>>> void foo(const char* attribName, const char* value)
>>> {
>>> m_str_attribs.insert(std::make_pair(attribName, new
>>> std::string(value)));
>>> }
>>>
>>> it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
>>> is it an effect of 'name lookup changes'?
>>> (http://gcc.gnu.org/gcc-4.7/porting_to.html)
>>
>> No, the change is in how std::pair is constructed, the code can be reduced
>> to:
>>
>> #include
>> #include
>>
>> typedef boost::shared_ptr HString;
>>
>> void foo(const char* attribName)
>> {
>> const std::pair a
>> = std::make_pair(attribName, new std::string);
>> }
>>
>> Probably caused by http://gcc.gnu.org/viewcvs?view=revision&revision=174464
>>
>> I haven't looked in enough detail to see if the change in behaviour is
>> correct or a regression.
>
> My guess is that the new behaviour is correct, because the relevant
> constructor of boost::shared_ptr is 'explicit' but you're relying on
> an implicit conversion from pair to
> pair> which implicitly converts a raw
> pointer to a shared_ptr.
Indeed, in [pairs.pair] the standard says:
template pair(const pair& p);
-11- This constructor shall not participate in overload resolution
unless const U& is implicitly convertible to first_type and const V&
is implicitly convertible to second_type.
So the new behaviour is required, your code is invalid.
Re: GSoC ideas: sc frontend, multi output compilation, constant path swap runtime optimization
On 03/18/2012 11:53 PM, Tomasz Borowik wrote: > The perfect solution would be to shun away the standard model and > actually support a kind of on-demand recompilation where the editor > tells the compiler (running in background) what has changed and the > compiler (having a function inlining map) recompiles only the > necessary pieces and replaces them in the elf files. Though that's > probably too far-fetched (there's also the question of how much of > gimple/generic could be kept between recompilations). > Simplifying we skip the "working in background" and the last step, > and just generate separate .s files, I've almost hacked this but I > had a lot of trouble with missing or duplicate variables/labels etc. http://www.gccsummit.org/2003/view_abstract.php?talk=28 Andrew.
cprop making assertions on available addressing modes?
I am having problems with the avr target that has address space support for
memories that only support post-increment addressing.
However, the code runs on a bad assertion because cprop.c generates silly insn
notes:
cprop.c:try_replace_reg()
if (!rtx_equal_p (src, SET_SRC (set))
&& validate_change (insn, &SET_SRC (set), src, 0))
success = 1;
/* If we've failed perform the replacement, have a single SET to
a REG destination and don't yet have a note, add a REG_EQUAL note
to not lose information. */
if (!success && note == 0 && set != 0 && REG_P (SET_DEST (set)))
note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src));
}
In the case in question validate_change returns false (which is correct) but
then there is a really strange note created:
src=
(mem/v/c:HI (post_inc:HI (const:HI (plus:HI (symbol_ref:HI ("V") [flags 0x402]
)
(const_int 1 [0x1] [3 V.i2+0 S2 A8 AS2])
insn =
(insn 10 9 11 2 (set (reg:HI 42 [ D.1334 ])
(mem/v/c:HI (post_inc:HI (reg:HI 30 r30)) [3 V.i2+0 S2 A8 AS2]))
as1.c:25 22 {*movhi}
(expr_list:REG_UNUSED (reg:HI 30 r30)
(nil)))
This leads to a call of emit_rtl.c:set_unique_reg_note() with datum=src
-> df_notes_rescan
-> df_uses_record
-> df_uses_record
-> df_ref_record
static void
df_ref_record (...)
{
unsigned int regno;
gcc_checking_assert (REG_P (reg) || GET_CODE (reg) == SUBREG);
reg=
(const:HI (plus:HI (symbol_ref:HI ("V") [flags 0x402] )
(const_int 1 [0x1])))
and this runs into ICE, of course.
Any ideas?
Johann
gcc-4.6.3 ICE
thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html === gcc tests === Running target unix FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler error) I'd like to extend my stack size a bit and re-run the gcc tests only. At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c run again. In detail. What would the procedure for that be ? -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
On 19 March 2012 14:56, Dennis Clarke wrote: > > thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html > > === gcc tests === > > > Running target unix > FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler error) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler error) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess errors) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer > (internal compiler error) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer > (test for excess errors) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler > error) > FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess > errors) > FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler error) > > > I'd like to extend my stack size a bit and re-run the gcc tests only. > At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c run > again. In detail. The full output of those tests should still be in a .log file somewhere under the build dir. > What would the procedure for that be ? See http://gcc.gnu.org/install/test.html and http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run specific tests. I think you should be able to do something like: make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c
Re: gcc-4.6.3 ICE
> On 19 March 2012 14:56, Dennis Clarke wrote: >> >> thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html >> >> === gcc tests === >> >> >> Running target unix >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (internal compiler error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (test for excess errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler >> error) >> >> >> I'd like to extend my stack size a bit and re-run the gcc tests only. >> At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c >> run >> again. In detail. > > The full output of those tests should still be in a .log file > somewhere under the build dir. > >> What would the procedure for that be ? > > See http://gcc.gnu.org/install/test.html and > http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run > specific tests. > > I think you should be able to do something like: > > make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c > Thank you for the quick reply. Hr, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 which is where I see the familiar old friend : titan-i386-SunOS5.8 $ cat ../gcc-4.6.3/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c #define LBR1 ( ( ( ( ( ( ( ( ( ( #define LBR2 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 #define LBR3 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 #define LBR4 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 #define LBR5 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 #define LBR6 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 #define RBR1 ) ) ) ) ) ) ) ) ) ) #define RBR2 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 #define RBR3 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 #define RBR4 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 #define RBR5 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 #define RBR6 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 int q5_var = LBR4 0 RBR4; This really comes down to the users stack size and a ulimit -s X for X=16384 or even 32768 solves it if I recall. I think I may just run the whole testsuite again, there are other pieces of ICE that I'd like to see melt away. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)
Hi, Richard Guenther skribis: > But no, I'm not volunteering (I'm volunteering to do the review work). > The above has the same issue as the "we-want-to-be-more-like-LLVM" > stuff - it lacks the people to actually implement it, and GCC at its > present state still has to evolve, we can't and do not want to just spend > a complete release or two with just turning GCC upside-down. What David proposes looks great, but also fairly intrusive and development-intensive. Perhaps a more incremental approach could be taken. For instance, I would argue that changes to the tree and GIMPLE APIs could be made conservatively, on the grounds that they are most likely used by plug-ins out there. IOW, rather than a commitment to a stable API, which would hinder the work of GCC developers, this would be an informal agreement to not make the plug-in developers life too hard. In the example of name mangling, I’d just have wrapped in ‘extern "C"’ all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in. The rationale is that it simplifies plug-in maintenance, while not impeding development work in 4.7. In the longer term, providing a GCC plug-in alongside one’s library or program should become as natural as providing a syntax highlighting mode. Thanks, Ludo’.
Re: gcc-4.6.3 ICE
On 19 March 2012 15:30, Dennis Clarke wrote: > >> >> I think you should be able to do something like: >> >> make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c >> > > Thank you for the quick reply. > > Hr, tried that and didn't get very far probably because the > srcdir is at ../gcc-4.6.3 I don't think that's the problem. Maybe you need make check RUNTESTFLAGS=compile.exp=limits-exprparen.c or make check RUNTESTFLAGS=compile.exp=*/limits-exprparen.c or some other variation on that theme.
Re: GCC 4.7.0RC: Mangled names in cc1
Hello,
For the interested reader, I eventually solved the nested function issue
by using either nested functions or C++11 lambdas, depending on whether
g++ is being used [0].
This is abstracted away by these (surprisingly not-too-ugly) macros to
define a local function, and declare a function parameter:
#ifdef __cplusplus
/* G++ doesn't implement nested functions, so use C++11 lambdas instead. */
# include
# define local_define(ret, name, parms) auto name = [=]parms
# define function_parm(ret, name, parms)std::function name
#else /* !__cplusplus */
/* GNU C nested functions. */
# define local_define(ret, name, parms) ret name parms
# define function_parm(ret, name, parms)ret (*name) parms
#endif /* !__cplusplus */
They are used like this:
static tree
map (function_parm (tree, func, (const_tree)), tree t)
{
[...]
}
static tree
foo (tree lst, tree y)
{
local_define (tree, frob, (const_tree x))
{
return do_something (x, y);
};
return map (frob, lst);
}
Then there were other subtleties to work around, such as the lack of
support for designated initializers in g++.
Thanks,
Ludo’.
[0]
https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?root=starpu&r1=6225&r2=6226
Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)
2012/3/19 Ludovic Courtès : > Hi, > > Richard Guenther skribis: > >> But no, I'm not volunteering (I'm volunteering to do the review work). >> The above has the same issue as the "we-want-to-be-more-like-LLVM" >> stuff - it lacks the people to actually implement it, and GCC at its >> present state still has to evolve, we can't and do not want to just spend >> a complete release or two with just turning GCC upside-down. > > What David proposes looks great, but also fairly intrusive and > development-intensive. > > Perhaps a more incremental approach could be taken. For instance, I > would argue that changes to the tree and GIMPLE APIs could be made > conservatively, on the grounds that they are most likely used by > plug-ins out there. IOW, rather than a commitment to a stable API, > which would hinder the work of GCC developers, this would be an informal > agreement to not make the plug-in developers life too hard. > > In the example of name mangling, I’d just have wrapped in ‘extern "C"’ > all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in. The > rationale is that it simplifies plug-in maintenance, while not impeding > development work in 4.7. Well, that's _all_ headers. Basically. And exactly the problem. There will be never even API compatibility between major releases of GCC with the current plugin "API". Richard.
Re: gcc-4.6.3 ICE
>> Hr, tried that and didn't get very far probably because the >> srcdir is at ../gcc-4.6.3 > > I don't think that's the problem. > > Maybe you need > make check RUNTESTFLAGS=compile.exp=limits-exprparen.c > or > make check RUNTESTFLAGS=compile.exp=*/limits-exprparen.c > or some other variation on that theme. > Well, too late now, I already incanted make -j 2 -k check and can expect results in a few hours. Thank you for helping. dc
Re: PRE_GCC3_DWARF_FRAME_REGISTERS
On Wed, Mar 14, 2012 at 10:08 AM, Steven Bosscher wrote: > Hello, > > The rs6000 and cr16 backends and unwinding code have a define for the > DWARF frame register for pre-GCC3 compatibility > (PRE_GCC3_DWARF_FRAME_REGISTERS): > > gcc/doc/tm.texi.in:@defmac PRE_GCC3_DWARF_FRAME_REGISTERS > gcc/doc/tm.texi:@defmac PRE_GCC3_DWARF_FRAME_REGISTERS > gcc/config/rs6000/rs6000.h:#define PRE_GCC3_DWARF_FRAME_REGISTERS 77 > Is this compatibility still needed for rs6000, or can all the > PRE_GCC3_DWARF_FRAME_REGISTERS stuff be cleaned up? I do not see any reason that compatibility with pre-GCC3 still should be necessary. The code was added by RTH and Aldy in 2001, so I want to make sure they are not aware of any remaining dependency. Thanks, David
fold_builtin changes tree
Hi, I have builtin __function_size(foobar) that is applied to functions. This should be folded to a symbol foobar@size. The problem comes when I mark in the fold_builtin function in my backend that DECL_PRESERVE(foobar) = 1; The reason I need to do this is so that foobar is not removed if we happen to use __function_size(foobar) since I will need foobar during linking phase to do some calculations with regards to its size. As a consequence of DECL_PRESERVE(foobar) I cannot build GCC with -- enable-checking because it fails the check in: fold-const.c and shows the message: internal compiler error: fold check: original tree changed by fold This is really annoying since I like to run my tests with --enable- checking=full to get the most of the checks in GCC but I can't with this issue lying around. I am open to suggestions on how to mark the function as preserve is the function name is referred to by a function builtin. Cheers, -- PMatos
Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)
On Mon, Mar 19, 2012 at 10:36 AM, Ludovic Courtès wrote: > Perhaps a more incremental approach could be taken. For instance, I > would argue that changes to the tree and GIMPLE APIs could be made > conservatively, on the grounds that they are most likely used by > plug-ins out there. Hmm, this is exactly the argument that people objected to back in the days when there were talks of plug-ins. The existence of plugins should not be a hindrance on evolving GCC internals. > IOW, rather than a commitment to a stable API, > which would hinder the work of GCC developers, this would be an informal > agreement to not make the plug-in developers life too hard. -- Gaby
GSoC project idea(Before formal Submission)
Dear All,
I want to design a new IPC(Inter Process Communication) for
Linux(Which can be extended for windows and mac also) as a project in
Google Summer of Code. It may change the traditional views of the IPCs
with its added features, security and extremely easy to use. All the
traditional IPCs need lots of functions to perform a simple operation
on it . But my IPC is smarter. Only one line declaration is enough to
access the IPC. Later the IPC would work just like an ordinary
datatypes. We can perform any kinds of arithmetic or logical
operations on this IPC which is possible for other datatypes.
The possible sample syntax would be:
"
smart_IPC a("name");// the "name" is the key to access the IPC, only
one line declaration is enough!!! Then the IPC 'a' works as an integer
variable to the
// programmer. Similarly it is
scalable to all other types of variable.
a = 10;
int b;
a = b+100;
cin >> a;
cout << a;
"
It can perform every kind of operations that the traditional IPCs can
perform. It is more secure and extremely easy to use(You can
experience it from the above example). I need your feedback before
final submission of this proposal.
Though according to the note at your idea page "But note that we are
probably not too interested in projects to add new extensions to the C
or C++ languages. We've found over time that these tend to introduce
more problems than they solve." I am not sure whether it would be
acceptable to you or not. No double it would led to an extension of
the standard C++ libraries but it would make it smarter not
overloaded. I have already started it and developed its basic
prototype and it is working properly.
I,therefore, request you to kindly give me your valuable feedback so
that I can submit my final proposal as early as possible.
--
Thanking You,
Regards
Subrata Biswas
MTech (pursuing)
Computer Science and Engineering
Indian Institute of Technology, Roorkee
Mob: +91 7417474559
Re: GSoC ideas: sc frontend, multi output compilation, constant path swap runtime optimization
On Mon, 19 Mar 2012 13:26:00 + Andrew Haley wrote: > On 03/18/2012 11:53 PM, Tomasz Borowik wrote: > > > The perfect solution would be to shun away the standard model and > > actually support a kind of on-demand recompilation where the editor > > tells the compiler (running in background) what has changed and the > > compiler (having a function inlining map) recompiles only the > > necessary pieces and replaces them in the elf files. Though that's > > probably too far-fetched (there's also the question of how much of > > gimple/generic could be kept between recompilations). > > > Simplifying we skip the "working in background" and the last step, > > and just generate separate .s files, I've almost hacked this but I > > had a lot of trouble with missing or duplicate variables/labels etc. > > http://www.gccsummit.org/2003/view_abstract.php?talk=28 > > Andrew. Thanks, I got "Could not connect to database server." but found it at: http://per.bothner.com/papers/GccSummit03-slides/index.html and I also found a more recent attempt: http://gcc.gnu.org/wiki/IncrementalCompiler That gave me an idea on how to improve my current hack without too much effort, which should save me quite a bit of time on recompiling until I write something better;) Now if I were to tackle this I'm affraid I probably wouldn't be touching the C or any other front-end (appart from my own). That just seems like way too much work, and the issues that might come up with preprocessing, lexing, parsing and build systems are quite scary. The case with my language is quite different as I'm usually working with one or a few very large files (and lots of system headers), so I'm mostly interested in recompiling a given file at the smallest granularity that makes sense (right now it's about 20 functions) rather than deduplicating work between files. The editor can supply any information I wish, so there is no need to figure out what changed within the driver and/or compiler. Unfortunately that seems to slightly diminish the benefit of any such work for other of languages and the world. On the other hand this would have a fairly deep connection with all the "modularity" efforts. I dislike the vagueness of the term quite a bit (and the flame war that seems to be brewing on it). So my work might include any or all of (unfortunately almost as vague) tasks: - documenting the method of building GENERIC and passing it to the middle-back-end along with some options, the output file, getting back the inlining info - making sure the middle-back-end can be reinitialized for processing potentially completely different code with different options, output file, and documenting how to do it - documenting the requirements put on GENERIC by the middle-back-end and whether/how it modifies it, and possibly eliminate those, - making the middle-back-end thread safe (global variables are not necessarily wrong if they are in tls and there are functions that handle launching the threads). >From what little experience I've had the interface between the front-end and >the rest seems very unclear, and kind of reversed where toplev.c is the driver >and the frontend just provides some hooks, wheras it seems to me it should be >the frontend in control and using some libraries/modules/whatever to handle >common tasks like option parsing, initializing/launching middle-back-end work, >and any other stuff. At least that would make creating the kind of compiler I'm aiming for much easier. Tomasz "timon" Borowik
Re: cprop making assertions on available addressing modes?
Steven Bosscher schrieb:
Hi Johann,
You say you have:
src=
(mem/v/c:HI (post_inc:HI (const:HI (plus:HI (symbol_ref:HI ("V") [flags 0x402]
)
(const_int 1 [0x1] [3 V.i2+0 S2 A8 AS2])
while in cprop.c. That is your bug.
Where does the post_inc come from? They're not supposed to exist at
The POST_INC are generated at expand time. It's for an address space
where the only reasonable addressing mode is POST_INC.
Indirect addressing turned out to cause extreme code bloat,
see PR rtl-optimization/52543 and
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
this point in the compilation pipeline. Most passes (cprop, gcse
hoist/pre, cse, fwprop, ...) don't handle auto-increment and
auto-decrement operations like this, because they're only supposed to
exist after pass_inc_dec (with the exception of push to / pop from the
stack).
Ciao!
Steven
Thanks for your information.
To overcome these shortcomings/implications I moved completely away
from MEM to represent loads from the address spaces in question.
This is possible because read is from rodata like memory that won't
change, i.e. reading from the same address will yield the same result.
Moreover, pre-/post-modify addressing optimization is very poor:
Even for code like
var = *p++;
var = *p++;
var = *p++;
...
I see that GCC loads the address to some oather register instead of
using post-increment. This means there is absolutely no advantage
with using the reload machinery.
Moreover, while working with the address spaces to represent segmented
memory, I observed that GCC is not yet ready for these kind of thing,
in particular register allocator cannot handle/reload the addresses.
This means that GCC is not suitable to be used for architectures with
segmented memory layouts like Microchip's PIC or Infineon's C16x
even though there is named address space support now.
Johann
pr52543
I have figured out what the root cause of pr52543, but i need some advise as to how to fix it. The bug only happens if the source or destination of the move is a hard register. lower-subreg never breaks up pseudo to pseudo moves that are larger than word mode. According to richard sandiford, this bug also appears on the neon, but i do not know if there is a bugzilla for it. It also appears on my private port, which is why i am interested in it. in the particular case of pr52543 and my port, this happens because the input arguments are hard regs. The offending code is in can_decompose_p. The problem is that if the reg is a hard reg, it completely blows off all of the information that it accumulated during the first pass and unconditionally splits the register (assuming it is legal to do so). My question for the list, what is the predicate that we want to replace the code that always decomposes hardregs (assuming it is legal).In the case of the neon and my port, decomposing costs 4x more than using a wide move. I assume the avr is similar. Kenny
Cloning functions
Hello, In my transformation of an input program, I need to clone functions and the callee functions in each clone. To clone a function, or create a duplicate, I use "cgraph_function_versioning()" This works perfectly well for the parent function. I then go through the statements in the parent and look for any function calls (callees). If I find a function call, I clone that function and update the call site using "gimple_call_set_fn()" Now, when I dump the gimple via "debug_function()" I see everything as I expect (parent-clone calls all the callee-clones). The parent and all of its callees are the clones I want. However, when GCC finishes compiling things, the callee clones are no where to be found. And the original (non-clone) calleess are being used. The parent-clone is there but all of the callsites are using the original callees and not the clones. I know there must be some update routine, (rebuild_cgraph_edges() did not help) to glue the callee clones in place so that they do not revert back to the original callee. I hope I haven't been too confusing, I do appreciate any help if possible. -Matt
A problem related to const rvalue
Hi,
I used gcc 4.8.0 to compile the piece of code:
#include
#include
void f( const int & i )
{
fprintf( stdout, "1 -> f( const int & i )-> %d\n", i );
}
void f( const int && i )
{
fprintf( stdout, "2 -> f( const int && i )-> %d\n", i );
}
void f( int & i )
{
fprintf( stdout, "3 -> f( int & i )-> %d\n", i );
}
void f( int && i )
{
fprintf( stdout, "4 -> f( int && i )-> %d\n", i );
}
int f1() { return 0; }
int const f2() { return 0; }
int & f3( int & i ) { return i; }
int const & f4( const int & i ) { return i; }
int && f5( int && i ) { return std::move( i ); }
int const && f6( int const && i ) { return std::move( i ); }
int main()
{
int i1 = 0;
const int i2 = 0;
int & i3 = i1;
const int & i4 = i2;
int && i5 = std::move( i1 );
const int && i6 = std::move( i2 );
f( i1 );
f( i2 );
f( i3 );
f( i4 );
f( i5 );
f( i6 );
f( f1() );
f( f2() );
f( f3( i3 ) );
f( f4( i4 ) );
f( f5( std::move( i1 ) ) );
f( f6( std::move( i2 ) ) );
return 0;
}
And the output of the program is:
3 -> f( int & i )-> 0
1 -> f( const int & i )-> 0
3 -> f( int & i )-> 0
1 -> f( const int & i )-> 0
3 -> f( int & i )-> 0
1 -> f( const int & i )-> 0
4 -> f( int && i )-> 0
4 -> f( int && i )-> 0
3 -> f( int & i )-> 0
1 -> f( const int & i )-> 0
4 -> f( int && i )-> 0
2 -> f( const int && i )-> 0
There are two lines of the strings: "4 -> f( int && i )-> 0". The first one is
reasonable, but the second one makes me surprised. I guess that it should have
been "2 -> f( const int && i )-> 0".
Is it a bug or by design? Who can answer the question for me?
Thanks very much!
cyril.
Re: pr52543
Kenneth Zadeck writes:
> I have figured out what the root cause of pr52543, but i need some
> advise as to how to fix it.
> The bug only happens if the source or destination of the move is a
> hard register. lower-subreg never breaks up pseudo to pseudo moves
> that are larger than word mode. According to richard sandiford, this
> bug also appears on the neon, but i do not know if there is a bugzilla
> for it. It also appears on my private port, which is why i am
> interested in it.
>
> in the particular case of pr52543 and my port, this happens because
> the input arguments are hard regs.
>
> The offending code is in can_decompose_p. The problem is that if the
> reg is a hard reg, it completely blows off all of the information that
> it accumulated during the first pass and unconditionally splits the
> register (assuming it is legal to do so).
>
> My question for the list, what is the predicate that we want to
> replace the code that always decomposes hardregs (assuming it is
> legal).In the case of the neon and my port, decomposing costs 4x
> more than using a wide move. I assume the avr is similar.
I don't think can_decompose_p would be the right thing to change. If
that function returns false, resolve_simple_move is still going to split
up the move. You need to change resolve_simple_move. In fact, looking
at resolve_simple_move, I don't think it will break up the register
unless it has already decided to do so:
/* If we didn't have any big SUBREGS of decomposed registers, and
neither side of the move is a register we are decomposing, then
we don't have to do anything here. */
if (src == SET_SRC (set)
&& dest == SET_DEST (set)
&& !resolve_reg_p (src)
&& !resolve_subreg_p (src)
&& !resolve_reg_p (dest)
&& !resolve_subreg_p (dest))
{
end_sequence ();
return insn;
}
So I think you need to analyze this a bit more. I don't think that is
the offending code.
Ian
Re: fold_builtin changes tree
"Paulo J. Matos" writes: > I have builtin __function_size(foobar) that is applied to functions. > This should be folded to a symbol foobar@size. > > The problem comes when I mark in the fold_builtin function in my backend > that DECL_PRESERVE(foobar) = 1; > > The reason I need to do this is so that foobar is not removed if we > happen to use __function_size(foobar) since I will need foobar during > linking phase to do some calculations with regards to its size. > > As a consequence of DECL_PRESERVE(foobar) I cannot build GCC with -- > enable-checking because it fails the check in: fold-const.c and shows the > message: > internal compiler error: fold check: original tree changed by fold > > This is really annoying since I like to run my tests with --enable- > checking=full to get the most of the checks in GCC but I can't with this > issue lying around. I am open to suggestions on how to mark the function > as preserve is the function name is referred to by a function builtin. I'm not sure what you are folding the builtin to, but perhaps you could retain a reference to the function. Or, you could write a tiny pass which set DECL_PRESERVED_P for each function passed to __function_size. Or, perhaps you could handle it in expand_builtin rather than fold_builtin. Ian
Re: GSoC project idea(Before formal Submission)
Subrata Biswas writes: > I want to design a new IPC(Inter Process Communication) for > Linux(Which can be extended for windows and mac also) as a project in > Google Summer of Code. This seems like an interesting project but it doesn't seem to be a compiler project. It seems like a library. I don't know where the right place for a library proposal would be, but I don't think it would be for the GCC project. You do mention some new syntax at least for C, but I'm not sure why that is essential for this proposal. And, as the notes say, we are generally not interested in language extensions. Thanks for your interest in GCC. Ian
Re: GSoC ideas: sc frontend, multi output compilation, constant path swap runtime optimization
Tomasz Borowik writes: > The most beneficial task (for me) would be to just bring the front-end > I've already written up to mainline quality (though not necessarily > inclusion), and in the process update some of the documentation or > maybe even cleanup some gcc code. I have nothing against new languages, but adding a new frontend doesn't help GCC very much, at least not directly. We are always interested in cleaning up code if you want to propose a project in that area. > A more middle-back-end task is that I see a need for a certain fairly simple > kind of self-modifying code. > Basically a lot of applications have lots of configuration of their behavior > that doesn't get changed through most of run-time, yet there are lots of > branches, variable references and pointer dereferences associated with it. > It should be possible to create something like a global variable that can be > read like one (from the programmers perspective) but it gets inlined > everywhere like a constant, and a function for changing it's value is > generated that changes that value at every point in the output binary. > Now unfortunately that would still leave a lot of branches in the code so > something a bit more complex would be nice, like leaving enough space for > either the then or else block, but putting only one in and padding with nops > or a jump. > This isn't really smc very much imo, something more like templating binary > code... or template based jit compilation, or let's call it something like > "constant path swapping";p > Either way the benefit is getting a lot of branches, de/references, etc. out > of the hot-path, at the cost of significantly slowing down the cold path > (assuming people use it for what it's meant for). > If a given backend does not support the feature it just outputs normal code. > There is probably a few more aspects/possibilities to this I'm just loosely > throwing it up for comment atm. > I probably haven't given enough thought to this since I don't have a good > idea of the issues associated. Definitely lto would break this but if you ask > me lto is a bit misguided as the previously mentioned idea coupled with the > way sc and its editor is designed makes it obsolete (unless I'm > misunderstanding something). That is a little vague but it seems that something promising might come out of it. Ian
