Re: libgcc/config.host pattern question
Hi Joel,
> I tracked down a bug in building v850-rtems to a place in libgcc/config.host
> where the code setting tmake_file did not append, it overwrote the previous
> value. This caused v850-rtems to throw away the previous setting which
> adding the newlib/sys/rtems/* directories to the include path.
>
> diff --git a/libgcc/config.host b/libgcc/config.host
> index bdc725f..f8f74cc 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -1195,7 +1195,7 @@ tilepro*-*-linux*)
> md_unwind_header=tilepro/linux-unwind.h
> ;;
> v850*-*-*)
> - tmake_file="v850/t-v850 t-fdpbit"
> + tmake_file="${tmake_file} v850/t-v850 t-fdpbit"
> ;;
> vax-*-linux*)
> tmake_file="$tmake_file vax/t-linux"
I suppose this happened in the course of my libgcc move patches for gcc
4.7. Unfortunately, almost no one responded to my call for testers in
that timeframe, so it must have gone unnoticed since.
> I see other places in this case statement where tmake_file is reset. Is
> this OK?
> Should be be added to all the time when the pattern is CPU*-*-*? all the
> time?
It's almost impossible to tell in general without a detailed analysis of
each individual case. Unless a specific problem is noticed, I'd leave
it alone for now, especially given how late in the 4.9 cycle we are.
> On a style inconsistency note, I see that some stanzas use $tmake_file
> while
> most use ${tmake_file}. Is there a rule? Personally I like having {} and
> most
> appear to have it.
True, there are many inconsistencies like this, and many more. I still
have this stuff on my agenda for when I hope to resume and finish my
libgcc move work. For the moment, I'd go with what is used in the
vicinity of a change you're going to make.
Hope this helps.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgcc/config.host pattern question
Hi Joel,
>> I suppose this happened in the course of my libgcc move patches for
> gcc
>> 4.7. Unfortunately, almost no one responded to my call for testers
> in
>> that timeframe, so it must have gone unnoticed since.
>
> We noticed but could never track it down. It initially manifested as
> _host_t not being defined. We were reworking the standard types
> infrastructure for rtems+Newlib around that time to be more BSD
> compatible and assumed we broke it. And we focused on debugging
> that.
>
> I recently added cpuset.h for pthread affinity and now the errors
> also showed that file missing from the include path. Much better
> clue.
>
> So we knew it broke but never considered it was a GCC and not Newlib
> bug. :(
I see, several changes going on at the same time ;-)
>> It's almost impossible to tell in general without a detailed
> analysis of
>> each individual case. Unless a specific problem is noticed, I'd
> leave
>> it alone for now, especially given how late in the 4.9 cycle we
> are.
>
> Unfortunately I have to agree on 4.9. No proof of an issue. It occurs
> because the OS specific but target cpu independent settings are
> overridden.
>
> What about for the head?
As I said, I hope to revisit and finish my libgcc work during the next
cycle, and it's probably easiest to include it then when I'm doing
large scale testing anyway.
>> > On a style inconsistency note, I see that some stanzas use
> $tmake_file
>> > while
>> > most use ${tmake_file}. Is there a rule? Personally I like having
> {} and
>> > most
>> > appear to have it.
>>
>> True, there are many inconsistencies like this, and many more. I
> still
>> have this stuff on my agenda for when I hope to resume and finish
> my
>> libgcc move work. For the moment, I'd go with what is used in the
>> vicinity of a change you're going to make.
>
> I will submit a small patch but would you like one to add {} broader
> as a follow up?
Same here: I'd like to avoid too much churn at different times since it
makes back porting more difficult. As I said, it's on my list already.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GSoC Concepts - separate checking
On 03/18/2014 10:54 PM, Maxim Kuvyrkov wrote: On Mar 12, 2014, at 12:19 PM, Braden Obrzut wrote: My name is Braden Obrzut and I am a student from the University of Akron interested in contributing to GCC for GSoC. I am interested in working on a project related to the c++-concepts branch. In particular, I am interested in implementing mechanisms for checking the safety of constrained templates (separate checking). I have discussed the project with Andrew Sutton (who maintains the c++-concepts branch and happens to be a professor at Akron) and believe that some aspects of the work would be feasible within the three month time span. I also hope to continue working on the project as my honors thesis project. As a hobby I usually design and implement declarative languages for content definition in old video games. While I currently may have limited experience with GCC internals, I think this would be a great opportunity for me to learn how real compilers works and help with the development of the C++ programming language. Braden, Do you have a proposal for a GSoC GCC project? If you do want to apply, please make sure you are registered at the GSoC website and have a application filed by end of Thursday (only 2 days left!). Thank you, -- Maxim Kuvyrkov www.linaro.org I have just now submitted the proposal to the GSoC website. - Braden Obrzut
Re: [gsoc 2014] moving fold-const patterns to gimple
On Wed, Mar 19, 2014 at 3:13 PM, Richard Biener
wrote:
> On Tue, Mar 18, 2014 at 9:04 AM, Prathamesh Kulkarni
> wrote:
>> On Mon, Mar 17, 2014 at 2:22 PM, Richard Biener
>> wrote:
>>> On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni
>>> wrote:
In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand
constructor instead of OP_EXPR ?
>>>
>>> Indeed - I have committed the fix.
>>>
>> Hi, I have attached an initial draft of my proposal.
>> I would be grateful to receive your feedback.
>
> Ok, I had a look at the proposal and it is mostly fine. I'd be more specific
> on the deliverables, specifically
>
> 1) genmatch - program to read meta description and generate code to
> simplify GENERIC and GIMPLE according to the pattern descriptions
> using an algorithm not linear in the number of patterns
>
> 2) add patterns matched by tree-ssa-forwprop.c (and thus patterns
> in fold-const.c it depends on) to the meta-description and perform
> the simplifications of tree-ssa-forwprop.c in terms of the simplification API
>
> You will figure out that there are possibly a lot of patterns in fold-const.c
> that forwprop depends on (I know mainly of all the comparison
> simplifications).
>
> For the Timeline I'd move e) as a sub-task of f) to June 28 - July 16,
> eventually just dividing the weeks of July 17 - August 11 to that and
> the following task.
>
> That is, the overall deliverable should be a tree-ssa-forwprop.c that is
> (mostly) implemented in terms of patterns, ready for commit to trunk
> during stage1.
>
> As for targeting GENERIC, useful testing coverage of that path will
> come from for example re-writing fold-const.c:fold_comparison using
> the GENERIC API of the pattern simplifier.
>
> The devil will be in the details (as always) ;)
>
> As Maxim said - make sure to register your proposal in-time, you
> can always improve on it later.
>
Thanks for the feedback. I have uploaded it:
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/prathamesh3492/5629499534213120
Would you like to suggest any further changes ?
There are a few formatting glitches, I am fixing those.
Could you help me point out how to write test-cases for transforms ?
For example:
/* Fold ~A + 1 -> -A */
(match_and_simplify
(PLUS_EXPR (BIT_NOT_EXPR @0) @1)
if (@1 == integer_one_node)
(NEGATE_EXPR @0))
Is the following test-case correctly written ?
/* { dg-do compile } */
/* { dg-options "-O -fdump-tree-forwprop" } */
int foo (int x)
{
int temp1 = ~x;
int temp2 = temp1 + 1;
return temp2;
}
/* { dg-final { scan-tree-dump "temp* = -x*(D)" "forwprop1" } } */
Shall that be (somewhat) correct ?
(Unfortunately, I cannot check if I have written the test-case correctly,
because I am in the middle of a bootstrap build.
Is there a way to run test-cases on only stage-1 compiler ?
I tried make check-cc1 RUNTESTFLAGS=dg.exp=tree-ssa/match-2.c but that
did not work).
forwprop output is:
;; Function foo (foo, funcdef_no=0, decl_uid=1743, symbol_order=0)
gimple_match_and_simplified to temp2_3 = -x_1(D);
foo (int x)
{
int temp2;
int temp1;
:
temp1_2 = ~x_1(D);
temp2_3 = -x_1(D);
temp2_4 = temp2_3;
return temp2_4;
}
Thanks and Regards,
Prathamesh
> Thanks,
> Richard.
>
>> Thanks and Regards,
>> Prathamesh
>>> Thanks,
>>> Richard.
>>>
This caused segfault for patterns when "simplification" operand was
only c_expr (patch attached).
* genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in
call to operand constructor.
gcc-4.8-20140320 is now available
Snapshot gcc-4.8-20140320 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140320/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 208738 You'll find: gcc-4.8-20140320.tar.bz2 Complete GCC MD5=54eafff77cfc1fe0dde10a1c0361b1c8 SHA1=d8dc44504d56c8572e4ca84fd3e92c85b67bd0e6 Diffs from 4.8-20140313 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > > "Thomas Preud'homme" writes: > > -mno-float causes gcc to define the macro __mips_no_float, which the > implementation can use when deciding whether to bother handling %f, etc. > I'm afraid there's nothing more sophisticated to it than that. > So the libc needs to be compiled with -mno-float as well so that printf and scanf drop the float handling? > > In ARM case the calling convention also determine how to pass > > structures of 4 or less floats/double so there would also be an > > arch-dependent part. I am not sure about whether to add a new hook or > > provide helper function in the middle end for the backend to use. > > I assume for most cases the restriction is of the form "calling this > function must not use registers in class X". I think we can detect > that using the existing hooks. I wish that information would be enough. Unfortunately, it's not. Suppose your code is compiler with a soft float ABI. Then, your float do not use any special register and yet, they make your code dependent on the float ABI. Therefore, the real question you are asking the backend is: "is the register allocation for this parameter dependent on the float ABI?". I do not think any current hook gives you this information. Ideally that would be a new version of the function_arg and function_value hook that takes a pointer to a boolean variable for the backend to give this information. Alternatively, it could be a new variable hook that the middle end [0] and back end would modify. [0] The middle end needs to be able to reset the variable to detect all the function that break the compatibility instead of just the first one, unless the variable is an integer that gets incremented. > > A more general restriction would be "must pass arguments in the same > way for both option set A and option set B". That too could be done > using existing hooks and SWITCHABLE_TARGET, although it might not be > hyper-efficient. I don't know how exactly that would work. You would switch twice for each function and ask the register used for each function call? Best regards, Thomas Preud'homme
