Re: Why are GCC Internals not Specification Driven ?
On Sun, Dec 18, 2016 at 11:49 PM, NightStrike wrote: > On Sun, Dec 18, 2016 at 11:37 AM, Andrew Haley wrote: >> On 18/12/16 02:33, Seima Rao wrote: >>> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly), >>> GCC extensions internals, ... and gnu's own debugging tied to gcc >>> (if such exist nowadays), ... are not documented in a specification >>> driven way. >> >> That's interesting. Can you explain what you mean by a specification- >> driven way? > > I believe he's referring to top down system design, where you start > from requirements (a la IEEE 830 or IEEE 29148), make design documents > that meet those requirements, model them with something like IEEE 1016 > (which is basically UML), and only at the end provide implementation. > On GCC, the implementation tends to come earlier in the process. At > least, there's probably no UML representation of GCC's design. I was referring to one of three approaches: i) Write a Specification document and a matching testsuite ii) Document _all_ data and code together with file formats (e.g. dumps). iii) Both (i) & (ii) (i) is easy (ii) is difficult (iii) doesnt sell the product well Sincerely, Seima Rao.
Re: Why are GCC Internals not Specification Driven ?
On 19 December 2016 at 10:17, Seima Rao wrote: > I was referring to one of three approaches: > > i) Write a Specification document and a matching testsuite > > ii) Document _all_ data and code together with file formats >(e.g. dumps). > > iii) Both (i) & (ii) > > (i) is easy I disagree. A functional specification would either be constantly out-of-date or would be a lot of effort to maintain (think how many different architectures GCC generates code for, and how often the instruction sets for the major architectures change). There would be some advantages to having the document in place, but only if it was maintained very thoroughly, which is unlikely to happen IMHO. We have testsuites. The output formats are defined by other documents we don't control (ABI specifications, processor instruction set references). The "UI" is defined by the manual. Duplicating this information in other documents would be a lot of effort and is not very compatible with the way GCC is developed. There is no top-down design committee that oversees GCC development and would act as gatekeepers to specification changes. The source code, the testsuite and the manual are the specification for GCC. > (ii) is difficult > (iii) doesnt sell the product well What product is being sold here?
Re: Why are GCC Internals not Specification Driven ?
On Mon, Dec 19, 2016 at 4:15 PM, Jonathan Wakely wrote:
> On 19 December 2016 at 10:17, Seima Rao wrote:
>> I was referring to one of three approaches:
>>
>> i) Write a Specification document and a matching testsuite
>>
>> ii) Document _all_ data and code together with file formats
>>(e.g. dumps).
>>
>> iii) Both (i) & (ii)
>>
>> (i) is easy
>
> I disagree.
>
> A functional specification would either be constantly out-of-date or
> would be a lot of effort to maintain (think how many different
> architectures GCC generates code for, and how often the instruction
> sets for the major architectures change). There would be some
> advantages to having the document in place, but only if it was
> maintained very thoroughly, which is unlikely to happen IMHO.
>
> We have testsuites. The output formats are defined by other documents
> we don't control (ABI specifications, processor instruction set
> references). The "UI" is defined by the manual.
>
> Duplicating this information in other documents would be a lot of
> effort and is not very compatible with the way GCC is developed. There
> is no top-down design committee that oversees GCC development and
> would act as gatekeepers to specification changes.
>
> The source code, the testsuite and the manual are the specification for GCC.
>
>> (ii) is difficult
>> (iii) doesnt sell the product well
>
> What product is being sold here?
GIMPLE/GENERIC, RTL & .md are languages, arent they?
So, basically there is a need for grammars and semantics.
However, leaving it at just that doesnt sound that good.
Where is the code, the most important part?
That code can be in a new testsuite that tests out the
specification of these four languages but the primary driver
remains GCC. That is, inorder to test out .md file,
we certainly should need GCC. Those instantly
seeking info about the file format can download
the source and study all of them.(this doesnt
take away the credit from the maintainer of
that component).
One advantage is that it gives a good overview on
where all the strengths and the weaknesses
of the choices made in the four(I state this because GCC
keeps on moving forward from one internal,
to abandoning it and adopting a new one, ...).
It can also help enforce some stability of the internals.
Inline assembly != gas, so this can also be specified
in a target independent way.
C++ already does this:
The shortest possible grammar for asm by any
vendor could be:
extern "asm" {
// the grammar here specifies a large 'C' string but nothing else
}
This passes through the string to the Assembler and does nothing else.
GCC extensions *should* have grammar and semantics and how they
fit to the Language they are extending. A bit like Boost.org
Target HW architecture separation can be achieved by
stating that post asm, all bets are passed on to 'gas'
and binutils 'gas' documentation becomes a new
forked off project separate from GCC.
Sincerely,
Seima Rao.
Question about ASMCONS
Hi guys,
I have the following rtl before asmcons pass:
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))
]
[
(asm_input:SI ("0") ../t02.c:9)
]
[] ../t02.c:9)) ../t02.c:9 -1
(nil))
Asmcons pass leads to this:
(insn 13 3 8 2 (set (reg:SI 157 [ list ])
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))) ../t02.c:9 -1
(nil))
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))
]
[
(asm_input:SI ("0") ../t02.c:9)
]
[] ../t02.c:9)) ../t02.c:9 -1
(nil))
Is the above output correct? My understanding is that the insn 8 needs be
changed to have as input the reg:SI 157.
Thanks,
Claudiu
Re: Do we really need a CPP manual?
On 12/16/2016 07:06 PM, Jeff Law wrote: That's likely the manual RMS kept asking folks (semi-privately) to review. My response was consistently that such review should happen publicly, which RMS opposed for reasons I don't recall. I don't see that manual as part of the GCC project and I certainly would understand a disinterest in reviewing/rewriting C language manuals and tutorials :-) More language and related standards under free licenses could be a worthwhile goal, though. I have no idea how tiresome this would be, and home much ideological objections to free licenses remain. (I once tried to learn C from GCC Texinfo printouts, and it took me a while to figure out that GCC did not come with documentation for the languages it implemented.) Thanks, Florian
Re: GCC libatomic ABI specification draft
On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote: > On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote: > > Hi Szabolcs, > > > > > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote: > > > > > > On 17/11/16 20:12, Bin Fan wrote: > > >> > > >> Although this ABI specification specifies that 16-byte properly aligned > > >> atomics are inlineable on platforms > > >> supporting cmpxchg16b, we document the caveats here for further > > >> discussion. If we decide to change the > > >> inlineable attribute for those atomics, then this ABI, the compiler and > > >> the runtime implementation should be > > >> updated together at the same time. > > >> > > >> > > >> The compiler and runtime need to check the availability of cmpxchg16b to > > >> implement this ABI specification. > > >> Here is how it would work: The compiler can get the information either > > >> from the compiler flags or by > > >> inquiring the hardware capabilities. When the information is not > > >> available, the compiler should assume that > > >> cmpxchg16b instruction is not supported. The runtime library > > >> implementation can also query the hardware > > >> compatibility and choose the implementation at runtime. Assuming the > > >> user provides correct compiler options > > > > > > with this abi the runtime implementation *must* query the hardware > > > (because there might be inlined cmpxchg16b in use in another module > > > on a hardware that supports it and the runtime must be able to sync > > > with it). > > > > Thanks for the comment. Yes, the ABI requires libatomic must query the > > hardware. This is > > necessary if we want the compiler to generate inlined code for 16-byte > > atomics. Note that > > this particular issue only affects x86. > > Why? Power (at least recent ones) has 128 bit atomic instructions > (lqarx/stqcx.) and Z has 128 bit compare and swap. That's not the only factor affecting whether cmpxchg16b or such is used for atomics. If the HW just offers a wide CAS but no wide atomic load, then even an atomic load is not truly just a load, which breaks (1) atomic loads on read-only mapped memory and (2) volatile atomic loads (unless we claim that an idempotent store is like a load, which is quite a stretch for volatile I think).
Re: Question about ASMCONS
Hi Claudiu,
On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote:
> I have the following rtl before asmcons pass:
>
> (insn 8 13 9 2 (set (reg:SI 157 [ list ])
> (asm_operands:SI ("") ("=g") 0 [
> (const:SI (unspec:SI [
> (symbol_ref:SI ("c_const") [flags 0x2] 0x7f6735ad25a0 c_const>)
> ] ARC_UNSPEC_GOTOFFPC))
> ]
> [
> (asm_input:SI ("0") ../t02.c:9)
> ]
> [] ../t02.c:9)) ../t02.c:9 -1
> (nil))
[ snip ]
asmcons eventual does reg_overlap_mentioned_p on the input of the move
it created with an input of the asm. The very first thing
reg_overlap_mentioned_p tests for is if the thing is constant. And it
is here, and that makes no sense at all (since it is an output, too!)
So how did that happen?
Segher
Re: Do we really need a CPP manual?
On Mon, 19 Dec 2016, Florian Weimer wrote: > On 12/16/2016 07:06 PM, Jeff Law wrote: > > > That's likely the manual RMS kept asking folks (semi-privately) to > > review. My response was consistently that such review should happen > > publicly, which RMS opposed for reasons I don't recall. > > > > I don't see that manual as part of the GCC project and I certainly would > > understand a disinterest in reviewing/rewriting C language manuals and > > tutorials :-) > > More language and related standards under free licenses could be a worthwhile > goal, though. I have no idea how tiresome this would be, and home much > ideological objections to free licenses remain. Maybe we should try to get SC22 to push for free licensing of language standards. (For the past few years SC22 has been pushing back on complicated rules in the JTC1 Directives about use of the very clunky ISO Livelink system and about what sorts of documents are supposed to be made available to whom. I'm not sure if the pushback has effectively reached SWG-Directives, however - or whether free licensing would need to be established at the SWG-Directives level, higher in ISO, or somewhere lower.) When BSI consulted on the ISO strategic plan consultation for 2016-2020 my response said that all standards should be freely licensed (I said 'I would like to see these points reflected in BSI's response to ISO. ... Thus: the goal for ISO should be to "promote, disseminate, preserve and protect its intellectual property in 2020" by making it all freely available under Creative Commons or similar licenses, online in locations that get readily indexed by search engines'), but I doubt that this actually ended up in BSI's response to ISO. (Programming languages are generally quite different from other ISO standards work, it seems; we've had to push back on other problematic rules like the one saying you can't issue a TC more than three years after the standard but have to produce a whole new edition in that case.) -- Joseph S. Myers jos...@codesourcery.com
Re: Question about ASMCONS
On 19/12/2016 18:06, Segher Boessenkool wrote:
Hi Claudiu,
On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote:
I have the following rtl before asmcons pass:
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))
]
[
(asm_input:SI ("0") ../t02.c:9)
]
[] ../t02.c:9)) ../t02.c:9 -1
(nil))
[ snip ]
asmcons eventual does reg_overlap_mentioned_p on the input of the move
it created with an input of the asm. The very first thing
reg_overlap_mentioned_p tests for is if the thing is constant. And it
is here, and that makes no sense at all (since it is an output, too!)
So how did that happen?
Right, the reg_overlap_mentioned_p returns zero letting the insn 8
unchanged.
The problem is observed in crtstuff.c when compiling __do_globa_dtor_aux
(line 398). Here it is a short test code:
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) };
void foo (int a)
{
func_ptr *dtor_list;
__asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__));
dtor_list[a]();
}
compiled with -O1 -fpic -mcpu=archs for ARC ;) it will crash somewhere
in verify_rtx_sharing due to the duplicated const(unspec) thingy.
I was thinking to force the replacement of the input, in function.c:6781
by adding to the condition an i == j check.
Due to this issue, the mainline cannot build ARC uClibc toolchain. I
suspect that this issue may affect also mips or nios2, but not 100% sure.
Thanks,
Claudiu
Re: Do we really need a CPP manual?
On 12/19/2016 07:17 PM, Joseph Myers wrote: When BSI consulted on the ISO strategic plan consultation for 2016-2020 my response said that all standards should be freely licensed (I said 'I would like to see these points reflected in BSI's response to ISO. ... Thus: the goal for ISO should be to "promote, disseminate, preserve and protect its intellectual property in 2020" by making it all freely available under Creative Commons or similar licenses, online in locations that get readily indexed by search engines'), Creative Commons NC licenses would be quite bad, in my opinion, particularly if ISO intends to extend these licenses to the programming interfaces expressed in the document. Unfortunately, Creative Commons as an umbrella term is next to useless because the licenses are so disparate. (I have no idea what the prevailing legal opinion on reading CC-NC documents as part of your paid work is. The NC licenses have many conflicting interpretations/expectations around them.) Thanks, Florian
Re: Why are GCC Internals not Specification Driven ?
Seima Rao writes: > Has gcc become proprietory/commercial ? By definition: no, yes. It's been this way since the beginning, and hasn't changed in decades. > Or has it become illegal to publish specification models > of gcc internals ? Does this make the product sell less ? This sounds like you're trying to start an argument, instead of asking a simple question. It is certainly not illegal to publish our specifications, and we certainly *do* publish many of our specifications (have you read the internals manual? You don't say whether or not you did, but that would be a key bit of information to have disclosed). Whether the product "sells" or not is rarely a driving factor for our project. Most of us work on it because we need it to work better for our own purposes. If you have specific questions about our documentation or development process, please ask them. Please do not ask vague, leading, and emotionally loaded questions. RTL and Gimple are documented. Are they documemented well? That depends on your needs. Are they documented as well as they could be? Probably not, but good enough for us so far. And as always, if you want to improve the situation, by all means feel free to volunteer to do so ;-)
If you are having trouble with traffic on your site please read!
Dear Valued Member With the Holidays almost here and 2017 just around the corner, it is very important to get your online business in a position of being found on major search engines. Now a days, it's not only about keywords anymore, it's about branding your company through a very complex method of marketing while utilizing Google Console's webmaster tools. Please give me a call to set up your appointment and discuss what your options are. Happy Holidays and to a prosperous New Year! Lilli S. Alpha Technologies Group (425)207-7681 www.alphatechnologiesgroup.com This message was sent to gcc@gcc.gnu.org from: Lilli Serrano | li...@alphatechnologiesgroup.com | ATG | 707 S GRADY WAY STE 600 | RENTON, WA 98057 Unsubscribe: http://app.icontact.com/icp/mmail-mprofile.pl?r=23344524&l=14050&s=I6R4&m=27571&c=1671839
