On Fri, May 18, 2012 at 4:56 AM, Chung-Lin Tang wrote:
> On 2012/5/18 03:26 PM, Gabriel Dos Reis wrote:
>> On Fri, May 18, 2012 at 12:48 AM, Chung-Lin Tang
>> wrote:
>>
>>> The point here is that, a group of changes that broke C bootstrap went
>>> in undetected for several days, because of the pa
On 2012/5/18 03:26 PM, Gabriel Dos Reis wrote:
> On Fri, May 18, 2012 at 12:48 AM, Chung-Lin Tang
> wrote:
>
>> The point here is that, a group of changes that broke C bootstrap went
>> in undetected for several days, because of the partially C++ default. To
>> prevent that in the future, we shou
On Fri, May 18, 2012 at 12:48 AM, Chung-Lin Tang
wrote:
> The point here is that, a group of changes that broke C bootstrap went
> in undetected for several days, because of the partially C++ default. To
> prevent that in the future, we should enforce similar checking in both C
> and C++.
As opp
On 2012/5/18 03:20 AM, Joseph S. Myers wrote:
> On Fri, 18 May 2012, Chung-Lin Tang wrote:
>
>> Joseph, how does this look? It makes the default post-stage1 C++
>> bootstrap fail similarly without the other options.c Makefile change, so
>> I guess it works as intended.
>
> For build system patche
On 2012/5/18 01:51 AM, Gabriel Dos Reis wrote:
> On Thu, May 17, 2012 at 12:41 PM, Gabriel Dos Reis
> wrote:
>> On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
>> wrote:
>>> On 17 May 2012 19:25, Gabriel Dos Reis
>>> wrote:
On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
wrote
On Fri, 18 May 2012, Chung-Lin Tang wrote:
> Joseph, how does this look? It makes the default post-stage1 C++
> bootstrap fail similarly without the other options.c Makefile change, so
> I guess it works as intended.
For build system patches you ought to be asking the build system
maintainers fo
On Thu, May 17, 2012 at 12:41 PM, Gabriel Dos Reis
wrote:
> On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
> wrote:
>> On 17 May 2012 19:25, Gabriel Dos Reis wrote:
>>> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
>>> wrote:
On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
On Thu, May 17, 2012 at 12:28 PM, Manuel López-Ibáñez
wrote:
> On 17 May 2012 19:25, Gabriel Dos Reis wrote:
>> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
>> wrote:
>>> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
> I'm guessing these changes are the cause of a full C bootstrap
>>
On 17 May 2012 19:25, Gabriel Dos Reis wrote:
> On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
> wrote:
>> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
I'm guessing these changes are the cause of a full C bootstrap
> (--disable-build-poststage1-with-cxx) failure I'm seeing on tru
On Thu, May 17, 2012 at 12:19 PM, Chung-Lin Tang
wrote:
> On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>>> I'm guessing these changes are the cause of a full C bootstrap
>>> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
>>> > *_handle_option_auto function prototypes
On 2012/5/17 01:55 AM, Manuel López-Ibáñez wrote:
>> I'm guessing these changes are the cause of a full C bootstrap
>> > (--disable-build-poststage1-with-cxx) failure I'm seeing on trunk. The
>> > *_handle_option_auto function prototypes are not seen in options.c, and
>> > -Werror -Wmissing-prototy
On Thu, 17 May 2012, Chung-Lin Tang wrote:
> 2012-05-17 Chung-Lin Tang
>
> * Makefile.in (options.c): Add options.h to included header
> files, before tm.h.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 16 May 2012 19:47, Chung-Lin Tang wrote:
> On 2012/5/10 04:53 AM, Manuel López-Ibáñez wrote:
>> 2012-05-09 Manuel López-Ibáñez
>>
>> PR 53063
>> gcc/
>> * doc/options.texi (EnabledBy): Document
>> * opts.c: Include opts.h and options.h before tm.h.
>> (finish_options)
On 2012/5/10 04:53 AM, Manuel López-Ibáñez wrote:
> 2012-05-09 Manuel López-Ibáñez
>
> PR 53063
> gcc/
> * doc/options.texi (EnabledBy): Document
> * opts.c: Include opts.h and options.h before tm.h.
> (finish_options): Do not handle some sub-options here...
> (com
On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
> Well, I was trying to avoid "merging" flags. Are there any examples of
> other such flags that are merged? The thing is that the "merge" done
> right now is really just concatenating existing flags. It doesn't work
> to set Init(1) and Init(0) in t
On 12 May 2012 18:12, Joseph S. Myers wrote:
> On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
>
>> Let's assume C-specific option -Wx enables common option -Wy. How can
>> I record this information in c.opt? Using Wx LangEnables(C, Wy) does
>
> Wy
> LangEnabledBy(C C++, Wx)
>
> There is no rest
On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
> Let's assume C-specific option -Wx enables common option -Wy. How can
> I record this information in c.opt? Using Wx LangEnables(C, Wy) does
Wy
LangEnabledBy(C C++, Wx)
There is no restriction on c.opt to contain only options marked as
specifi
On 12 May 2012 17:18, Gabriel Dos Reis wrote:
> On Sat, May 12, 2012 at 10:12 AM, Joseph S. Myers
> wrote:
>> I don't think common.opt should have LangEnabledBy listing different
>> languages, though; that information should be in the front ends' .opt
>> files.
>
> Agreed.
Ideally, yes. But how?
On Sat, May 12, 2012 at 10:12 AM, Joseph S. Myers
wrote:
> I don't think common.opt should have LangEnabledBy listing different
> languages, though; that information should be in the front ends' .opt
> files.
Agreed.
> And, before we add such language-specific enabling of a
> language-independen
On Sat, 12 May 2012, Manuel L?pez-Ib??ez wrote:
> On 11 May 2012 21:23, Joseph S. Myers wrote:
> >
> > There's nothing wrong with having separate autogenerated functions for
> > each language if you want to split things out that way, but it would seem
> > simpler just to have one function called
On 11 May 2012 21:23, Joseph S. Myers wrote:
>
> There's nothing wrong with having separate autogenerated functions for
> each language if you want to split things out that way, but it would seem
> simpler just to have one function called somewhere central, whatever
> option it is (common or not)
On Fri, 11 May 2012, Manuel López-Ibáñez wrote:
> >> What cases do we have where a language-independent option enables another
> >> language-independent option only for some front ends? That's the only
> >> case that should need a language-dependent generated function here.
> >
> > Wall enables W
On 11 May 2012 19:09, Manuel López-Ibáñez wrote:
> On 11 May 2012 19:04, Joseph S. Myers wrote:
>> On Fri, 11 May 2012, Manuel López-Ibáñez wrote:
>>
>>> Great! Now we have EnabledBy for common options. Now, what should we
>>> do with language specific settings? One idea could be to have
>>> some
On 11 May 2012 19:04, Joseph S. Myers wrote:
> On Fri, 11 May 2012, Manuel López-Ibáñez wrote:
>
>> Great! Now we have EnabledBy for common options. Now, what should we
>> do with language specific settings? One idea could be to have
>> something like:
>>
>> LangEnabledBy(Fortran Ada, Wall)
>>
>>
On Fri, 11 May 2012, Manuel López-Ibáñez wrote:
> Great! Now we have EnabledBy for common options. Now, what should we
> do with language specific settings? One idea could be to have
> something like:
>
> LangEnabledBy(Fortran Ada, Wall)
>
> and then auto-generate something like:
>
> ada_handle
On 10 May 2012 16:05, Joseph S. Myers wrote:
> On Wed, 9 May 2012, Manuel López-Ibáñez wrote:
>
>> 2012-05-09 Manuel López-Ibáñez
>>
>> PR 53063
>> gcc/
>> * doc/options.texi (EnabledBy): Document
>> * opts.c: Include opts.h and options.h before tm.h.
>> (finish_options)
On Wed, 9 May 2012, Manuel L?pez-Ib??ez wrote:
> 2012-05-09 Manuel L?pez-Ib??ez
>
> PR 53063
> gcc/
> * doc/options.texi (EnabledBy): Document
> * opts.c: Include opts.h and options.h before tm.h.
> (finish_options): Do not handle some sub-options here...
> (commo
On 9 May 2012 00:38, Joseph S. Myers wrote:
> On Wed, 9 May 2012, Manuel López-Ibáñez wrote:
>
>> which looks correct to me. However, the build fails because now
>> options.h requires input.h which requires line-map.h, which is not
>> included when building for example libgcc. options.h is include
On Wed, 9 May 2012, Manuel L?pez-Ib??ez wrote:
> which looks correct to me. However, the build fails because now
> options.h requires input.h which requires line-map.h, which is not
> included when building for example libgcc. options.h is included by
> tm.h, so it basically appears everywhere.
>
On 6 May 2012 20:45, Joseph S. Myers wrote:
>>
>> One idea could be to have an additional auto_handle_option() that is
>> generated from the awk scripts and called after all other
>> handle_option functions. This function will populate a switch with
>> group options and the respective calls to han
On Sun, 6 May 2012, Manuel López-Ibáñez wrote:
> Wuninitialized is enabled by both Wall and Wextra. Wextra enables it
> in the common part, however, Wall does it in the FE specific part
> (c-family, fortran, ada). When enabled via Wall, opts_set does not get
> updated. What is the best way to enab
On 6 May 2012 13:56, Joseph S. Myers wrote:
> On Sat, 5 May 2012, Manuel López-Ibáñez wrote:
>
>> Thanks for the hints. This is what I am currently
>> bootstrapping+regtesting. It builds and works on a few manual tests.
>>
>> OK if it passes?
>>
>> 2012-05-05 Manuel López-Ibáñez
>>
>> PR
On Sat, 5 May 2012, Manuel L?pez-Ib??ez wrote:
> Thanks for the hints. This is what I am currently
> bootstrapping+regtesting. It builds and works on a few manual tests.
>
> OK if it passes?
>
> 2012-05-05 Manuel L?pez-Ib??ez
>
> PR c/53063
> gcc/
> * doc/options.texi (EnabledBy)
Thanks for the hints. This is what I am currently
bootstrapping+regtesting. It builds and works on a few manual tests.
OK if it passes?
2012-05-05 Manuel López-Ibáñez
PR c/53063
gcc/
* doc/options.texi (EnabledBy): Document.
* opts.c (finish_options): Call finish_optio
On Sat, 5 May 2012, Manuel L?pez-Ib??ez wrote:
> Comments? My knowledge of awk is basically zero, so suggestions on
> how to improve the code are very welcome.
>
> Should I cleanup the patch and submit it with a Changelog?
Yes please. Some observations:
* finish_options_generated should take
Hi,
This patch is a first step towards encoding the fact that some flags
enable other flags in the .opt files. As a proof-of-concept, I have
only implemented the check for a group option not overriding the value
of the suboption if the suboption was set. In the future, we should
handle more stuff
36 matches
Mail list logo
