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_header
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, 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 know
On Tue, Jul 2, 2013 at 3:25 PM, Joseph S. Myers jos...@codesourcery.com 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
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
conversation, and I
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 to a
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 jos...@codesourcery.com 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
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
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
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 problem
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
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
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 dmi...@kernelgen.org 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.
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
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
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
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 about
17 matches
Mail list logo
