This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [BUILDROBOT] nios2: build breakage
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: Jan-Benedict Glaw <jbglaw at lug-owl dot de>, Jan Hubicka <hubicka at ucw dot cz>, Chung-Lin Tang <cltang at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Nov 2014 05:34:31 +0100
- Subject: Re: [BUILDROBOT] nios2: build breakage
- Authentication-results: sourceware.org; auth=none
- References: <20141115165720 dot GG31795 at kam dot mff dot cuni dot cz> <20141115204519 dot GM8445 at lug-owl dot de> <20141115215643 dot GA629 at kam dot mff dot cuni dot cz> <20141115233626 dot GA13765 at kam dot mff dot cuni dot cz> <20141115234903 dot GN8445 at lug-owl dot de> <546801DD dot 2070007 at codesourcery dot com> <546D21A4 dot 3070106 at codesourcery dot com>
Sandra,
> >
> >I can explain why this is needed, at least.
> >
> >The Nios II architecture optionally allows "custom instructions" that
> >are typically used to implement floating-point operations. The nios2
> >GCC backend knows to generate these instructions if the user tells it
> >what opcodes implement these instructions. This is typically done by
> >command-line options, but can also be done on a per-function basis by
> >means of target attributes or pragmas -- see
> >gcc/testsuite/gcc.target/nios2/custom-fp-* for examples. The
> >command-line options, attribute, and pragma support was a requirement
> >from Altera, so yes, this is really needed.
>
> Ping. Do we have any strategy or timeline for fixing this yet? At
> the very least, if it is determined to impose a new restriction
> against using arrays in the saved option state, there must be a
> patch to clearly document what is permissible. Otherwise I think
> the generic code must be fixed to support what the nios2 back end is
> already doing and which previously worked per the existing
> documentation.
I see three possible fixes:
1) extend the AWk script to recognize arrays and stream them specially
(it already recognizes string so it is not hard to do, just bit wasteful)
2) add attribute to .opt file allowing user to specify his own
compare/hash/stream-in/stream-out functions
3) avoid using arrays in the backend. I think it is doable - the target
structure contains string representation of the arrays
(nios2_custom_fpu_cfg_string) and therefore saved_custom_code_status/
saved_custom_code_index does not really need to hit the LTO stream
at all. Question is where to place them and I think target specific
part of cfun is probably resonable choice.
As for AWk-fu, 2 is probably easier than 1, but both are not hard - one just
need to follow what is already done for strings and introduce third type of
variable.
Unless someone beats me, I will probably go for 1 since I am not very familiar
with the backend and array support may come handy in future.
As for timeline, I have a workshop next week and need to prepare draft for it.
So ideally I would like to work on this only after the workshop (ending
November 28). I would be also happy to help anyone interested to help (I am
just bit slow on portable AWK hacking).
Honza
>
> -Sandra