On Tue, Jul 2, 2013 at 3:25 PM, Joseph S. Myers wrote:
> On Mon, 1 Jul 2013, Aaron Gray wrote:
>
>> I started to do this starting with the C++ parser class'izing it but
>> no one was interested.
>
> The C++ parser types such as cp_parser and cp_lexer already do a good job
> of avoiding global stat
On Mon, 1 Jul 2013, Aaron Gray wrote:
> I started to do this starting with the C++ parser class'izing it but
> no one was interested.
The C++ parser types such as cp_parser and cp_lexer already do a good job
of avoiding global state.
I am not an expert on good C++ coding practices and don't kno
Aaron: have you done the patch submission paperwork with the FSF? (as
per http://gcc.gnu.org/contribute.html#legal )
If so, is your work available somewhere?
Thanks
Dave
On Mon, 2013-07-01 at 23:56 +0100, Aaron Gray wrote:
> I started to do this starting with the C++ parser class'izing it but
>
On Mon, 2013-07-01 at 19:43 +, Joseph S. Myers wrote:
> On Mon, 1 Jul 2013, David Malcolm wrote:
[...]
> > Would you be in favor killing off these macros:
> > #define input_line LOCATION_LINE (input_location)
> > #define input_filename LOCATION_FILE (input_location)
> > #define in_system_
I started to do this starting with the C++ parser class'izing it but
no one was interested.
On 1 July 2013 20:43, Joseph S. Myers wrote:
> On Mon, 1 Jul 2013, David Malcolm wrote:
>
>> > As for accessing globals directly versus via APIs: yes, I suppose you do
>> > still have an access to a global
On Mon, 1 Jul 2013, David Malcolm wrote:
> > As for accessing globals directly versus via APIs: yes, I suppose you do
> > still have an access to a global class instance in each place you formerly
> > had a global variable (that's now a member of that class), so by itself
> > such a conversion
On Thu, 2013-06-27 at 20:23 +, Joseph S. Myers wrote:
> On Thu, 27 Jun 2013, David Malcolm wrote:
>
> > I want to focus on "removal of global state", and I want that to be
> > separate from "cleanups of internal APIs".
There are several interpretations of the word "global" in this
conversatio
On Thu, 27 Jun 2013, David Malcolm wrote:
> I want to focus on "removal of global state", and I want that to be
> separate from "cleanups of internal APIs".
Whereas I'm thinking of global state as being a symptom of a problem -
messy interfaces that have accreted over time - rather than the prob
On Thu, 2013-06-27 at 14:50 +, Joseph S. Myers wrote:
> On Wed, 26 Jun 2013, David Malcolm wrote:
>
> > FWIW I wonder to what extent the discussions that follow all exhibit a
> > tradeoff between the desire to provide a clean API vs the desire to
> > minimize the size of the patch (to reduce b
On Wed, 26 Jun 2013, David Malcolm wrote:
> FWIW I wonder to what extent the discussions that follow all exhibit a
> tradeoff between the desire to provide a clean API vs the desire to
> minimize the size of the patch (to reduce backporting pain).
I don't think reducing backporting pain is partic
On Wed, 2013-06-26 at 20:21 +, Joseph S. Myers wrote:
> For a shared library you need a well-defined namespace for GCC functions /
> variables so it doesn't interfere with users. Are you going to put
> everything inside a "gcc" namespace or similar?
FWIW I deliberately avoided talking abo
For a shared library you need a well-defined namespace for GCC functions /
variables so it doesn't interfere with users. Are you going to put
everything inside a "gcc" namespace or similar? (You also need to avoid
host libraries such as libiberty - which have C interfaces - interfering
with u
Yes, generation of both binary code and LLVM IR in a single GCC
invocation. So, first toplev_main goes as usual, and another one - with
DragonEgg plugin enabled. LLVM IR ends up as GPU kernels code a bit later.
Yes, that is the right patch.
Of course, not thread-safe, not generally portable and v
On Wed, 2013-06-26 at 15:19 -0400, Dmitry Mikushin wrote:
> FWIW, we also needed to perform multiple invocations of toplev_main from
> a single execution of GCC frontend, which seems to be quite similar.
Interesting. Yes, this sounds very similar to the kinds of use-cases
I'm considering. Am I
GCC is hosted on platforms other than SVR4 ABI and ELF file format.
- David
On Wed, Jun 26, 2013 at 3:19 PM, Dmitry Mikushin wrote:
> FWIW, we also needed to perform multiple invocations of toplev_main from
> a single execution of GCC frontend, which seems to be quite similar. The
> dirty dirty
FWIW, we also needed to perform multiple invocations of toplev_main from
a single execution of GCC frontend, which seems to be quite similar. The
dirty dirty hack is to save the backup the content of .data and .bss
symbols with ELF API before the first call to toplev_main and reset them
to backup v
I've been looking at removing global state from GCC with a view to
making it be usable as a shared library.
I've been posting various patches relating to this, but I thought it was
time to post a comprehensive plan so you can see how I think it all
ought to fit together.
You can see an HTML versi
17 matches
Mail list logo
