On Mon, Jan 19, 2015 at 6:03 PM, Jeff Law wrote:
> On 01/17/15 07:34, Gary Funck wrote:
>>
>> On 01/14/15 23:15:59, Jeff Law wrote:
>>>
>>> Sounds good. I think just starting with the list & creating the buckets
>>> with the list. Then post here and we'll iterate and try to nail that
>>> down
>>
On 01/17/15 07:34, Gary Funck wrote:
On 01/14/15 23:15:59, Jeff Law wrote:
Sounds good. I think just starting with the list & creating the buckets
with the list. Then post here and we'll iterate and try to nail that down
before you start moving everything in the .texi file.
Something to cons
On 01/14/2015 11:15 PM, Jeff Law wrote:
> On 01/14/15 23:12, Sandra Loosemore wrote:
>> I'll see if I can put together a
>> plan for splitting things up if there are too many leftovers maybe
>> others can help by suggesting different/additional categories.
> Sounds good. I think just starting
On 1/17/2015 12:13 PM, Sandra Loosemore wrote:
BTW, as a GCC user I'm also very frustrated by the (lack of)
organization in the extensions chapter; the information about
attributes and built-in functions is all mixed up with sections on
random syntactic extensions like "Dollar Signs in Identif
On 01/17/2015 11:30 AM, Joel Sherrill wrote:
On January 17, 2015 8:34:04 AM CST, Gary Funck wrote:
On 01/14/15 23:15:59, Jeff Law wrote:
Sounds good. I think just starting with the list & creating the
buckets
with the list. Then post here and we'll iterate and try to nail that
down
bef
On January 17, 2015 8:34:04 AM CST, Gary Funck wrote:
>On 01/14/15 23:15:59, Jeff Law wrote:
>> Sounds good. I think just starting with the list & creating the
>buckets
>> with the list. Then post here and we'll iterate and try to nail that
>down
>> before you start moving everything in the .t
On 01/14/15 23:15:59, Jeff Law wrote:
> Sounds good. I think just starting with the list & creating the buckets
> with the list. Then post here and we'll iterate and try to nail that down
> before you start moving everything in the .texi file.
Something to consider, if the optimization options a
On Wed, 14 Jan 2015, Sandra Loosemore wrote:
> What would you think about reorganizing this section to add some subsections
> grouping options by purpose, instead? E.g., loop optimizations,
> floating-point optimizations, inlining, LTO, profiling options, etc? The
> section is almost 60 pages lo
On 1/15/2015 12:15 AM, Jeff Law wrote:
> On 01/14/15 23:12, Sandra Loosemore wrote:
>> On 01/14/2015 08:41 PM, Jeff Law wrote:
>>> With the section being ~60 pages, my first thought is we have way too
>>> many options!
>> Heh, at least we have documentation for all those options. :-)
>>
>>> But t
On Thu, Jan 15, 2015 at 12:48 AM, Sandra Loosemore
wrote:
> The "Options That Control Optimization" section of the manual is
> currently divided into three parts (not subsections, just separate option
> lists):
>
> (1) General options like -O[n]
>
> (2) Options that individually control options en
On 01/14/15 23:12, Sandra Loosemore wrote:
On 01/14/2015 08:41 PM, Jeff Law wrote:
With the section being ~60 pages, my first thought is we have way too
many options!
Heh, at least we have documentation for all those options. :-)
But that's not likely to change. Though perhaps the
process
On 01/14/2015 08:41 PM, Jeff Law wrote:
With the section being ~60 pages, my first thought is we have way too
many options!
Heh, at least we have documentation for all those options. :-)
But that's not likely to change. Though perhaps the
process will encourage some culling of options that
On 01/14/15 16:48, Sandra Loosemore wrote:
The "Options That Control Optimization" section of the manual is
currently divided into three parts (not subsections, just separate
option lists):
(1) General options like -O[n]
(2) Options that individually control options enabled by default at some
-
13 matches
Mail list logo
