Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

Hi! Shea Levy skribis: > Your patches look good! My biggest concern is how the ld wrapper behaves > in the presence of response files. Have you tested that? It surely doesn’t (yet?). However, GCC does not pass “@file” arguments when it invokes ‘ld’, and the bug report you mentioned¹ talks abou

Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

Hi Shea, Shea Levy skribis: > Unlike the traditional approach of installing system libraries into one > central location like /usr/{lib,include}, the nix package manager [1] > installs each package into it's own prefix > (e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,

Re: [PATCH MIPS] Work around Bash 4.2 bug

"Maciej W. Rozycki" skribis: > On Fri, 30 Sep 2016, Hans-Peter Nilsson wrote: > >> > The patch below works around the Bash 4.2 bug described at >> > . >> >> >* emulparams/elf32bmipn32-defs.sh: Shift quote of >> >"x$EMULATION_NAME"

Re: GNU Tools Cauldron 2014 - Slides for presentations

"Joseph S. Myers" skribis: > In accordance with GNU principles we should be making the videos available > without depending on non-free JavaScript as well (I don't know if Google+ > makes videos readily available without JS or with only free JS). Agreed. I would recommend making them availabl

Re: [GSoC] decision tree first steps

Richard Biener skribis: > (match-and-simplify > (bit_and @0 integer_zerop@1) > @1) > (match-and-simplify > (bit_and @0 integer_all_onesp@1) > @0) > > is IMHO easier to parse while your version more like matches > what the code generator creates. Ah yes, the ability to specify predicates

Re: [GSoC] decision tree first steps

Hi, Prathamesh Kulkarni skribis: > Example: > /* x & 0 -> 0 */ > (match_and_simplify > (bit_and @0 @1) > if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && (@1 == integer_zero_node)) > { integer_zero_node; }) > > /* x & -1 -> x */ > (match_and_simplify > (bit_and @0 @1) > if (INTEGRAL_TYPE_P (TRE

Re: clang vs free software

Chris Lattner skribis: > On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote: >> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a >> better-supported point of view.) > > Unrelated to this thread, it would be great for this web page to get updated. > You may find it to be "

Re: CPATH, LIBRARY_PATH, and cross-compilers

Ralf Corsepius skribis: > On 02/13/2013 03:49 PM, Ludovic Courtès wrote: [...] >> At any rate, there’s a need for similar env. vars for cross-compilers. WDYT? > I am having difficulties to imagine such a need. Well, for the same reason that CPATH & co. are sometimes nee

Re: CPATH, LIBRARY_PATH, and cross-compilers

Richard Biener skribis: > On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener > wrote: >> On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote: >>> Joel Sherrill skribis: >>> >>>> But it still doesn't address the situation where you have mul

Re: CPATH, LIBRARY_PATH, and cross-compilers

Joel Sherrill skribis: > But it still doesn't address the situation where you have multiple > cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. Lud

CPATH, LIBRARY_PATH, and cross-compilers

Hi, GCC honors CPATH, LIBRARY_PATH, & co. regardless of whether it’s built as a cross-compiler. Consequently, when cross-compiling a package that contains both support tools to be compiled natively and the main code to be cross-compiled, these variables are useless because they don’t allow host a

Re: TODO_rebuild_alias and -O0

Richard Guenther skribis: > On Mon, Oct 8, 2012 at 6:04 PM, Ludovic Courtès > wrote: [...] >> So it looks like there’s additional state corresponding to these >> variables that needs updating? > > Ah, no, but I suppose TODO_update_address_taken doesn't really wor

Re: TODO_rebuild_alias and -O0

Richard Guenther skribis: > On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès wrote: >> Richard Guenther skribis: >> >>> On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote: >>>> Richard Guenther skribis: >>>> >>>>> On Mon,

Re: TODO_rebuild_alias and -O0

Richard Guenther skribis: > On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote: >> Richard Guenther skribis: >> >>> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: >>>> Richard Guenther skribis: >>>> >>>>> At -O0 no v

Re: TODO_rebuild_alias and -O0

Richard Guenther skribis: > On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: >> Richard Guenther skribis: >> >>> At -O0 no virtual operands are produced. TODO_rebuild_alias only computes >>> points-to sets which are in itself not useful. >>

Re: TODO_rebuild_alias and -O0

Richard Guenther skribis: > At -O0 no virtual operands are produced. TODO_rebuild_alias only computes > points-to sets which are in itself not useful. > > What do you want to achieve with TODO_rebuild_alias? I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. Thanks, Ludo

TODO_rebuild_alias and -O0

Hello, Consider the attached plug-in, which adds a new dummy pass after the “ssa” pass, with ‘TODO_rebuild_alias’ as its start flags: #include #include #include #include int plugin_is_GPL_compatible; static unsigned int my_pass (void) { return 0; } static struct opt_pass pass_dummy =

Re: Auto-stuff in GCC

Hi Dimitrios, Dimitrios Apostolou skribis: > This process proved way more tedious than it ought to be, and even > after completing it there were some licensing issues because of GPL > incompatibilities since I borrowed code from gnulib. In general, Gnulib’s policy is to adjust module licenses t

Re: gcc plugin problem

Hi, mahdi hamzeh skribis: > Thanks. The problem was naming indeed. I managed to recompile gcc with > c compiler only and the problem is gone. The long-term solution for you would be to build your plug-in with g++. See the thread at . Thanks, Lud

Re: gcc plugin problem

Hi, mahdi hamzeh skribis: > I compiled and built gcc 4.7.0 myself. I am not sure if I build gcc on > my machine, it would be compiled as c++. How would I check that? You could run: nm /path/to/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1 | \ grep loop_optimizer_init and check whether

Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]

Hello, Richard Guenther skribis: > And since yesterday GCC shows > > t.C:2:10: error: expected ';' after class definition > class a {} > ^ > t.C:6:1: error: expected ';' after struct definition > } > ^ > > as we now enabled -fdiagnostics-show-caret by default. How important is it t

Re: Switching to C++ by default in 4.8

Hi, Basile Starynkevitch skribis: > My feeling is that the plugin ability of GCC should help academia to work > more on (that > is, "inside") GCC, to only to use GCC. Yes, except that, on one hand, they have a library stack with stable APIs, and on the other, an otherwise quite stable API that

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

Hi, (Sorry for the delay.) I suppose the proposed API doesn’t cover all the needs of your Python bindings and their applications, does it? How do you plan to export the GIMPLE and tree.h APIs? Regarding iterators, there are things like: GCC_IMPLEMENT_PUBLIC_API(bool) gcc_cfg_for_each_block

[PATCH] Add StarPU on extensions.html

Hello, As suggested by Gerald Pfeifer. Thanks, Ludo’. --- extensions.html.~1.51.~ 2011-09-28 01:45:17.0 +0200 +++ extensions.html 2012-04-12 12:11:09.0 +0200 @@ -26,6 +26,19 @@ maintainers, not our mailing lists. to ease development of GCC plugin-like extensions. +http://r

Re: GRAPHITE-OpenCL?

Hi, Alexander Monakov skribis: > The code has been merged into graphite branch; it can be obtained via: > > svn co svn://gcc.gnu.org/svn/gcc/branches/graphite Excellent, thanks! Ludo’.

GRAPHITE-OpenCL?

Hello, The GRAPHITE-OpenCL work published a couple of years ago looks interesting [0]. What’s the status of the code? Is it accessible on-line? Thanks in advance, Ludo’. [0] http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=belevantsev.pdf

Re: Proposed plugin API for GCC

Ian Lance Taylor skribis: > We do not want plugins to constrain internal development. So if we > adopted your approach, the only honest option would be to mark > everything as internal. And that would leave us where we are today. My (limited) experience suggests that things aren’t that bad bet

Re: Proposed plugin API for GCC

Gabriel Dos Reis skribis: > On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès > wrote: > >> I find it important to help such unanticipated uses of GCC spread. > > It is hard to design for things you do not know. Indeed, that’s the whole point. Offer a ten-function stable A

Re: Proposed plugin API for GCC

Hi Richard, Richard Guenther skribis: > On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès [...] >> The needs of plug-ins cannot be anticipated; artificially restricting >> what plug-ins can do is likely to hinder wider extension of GCC. > > Extension of GCC should

Re: Proposed plugin API for GCC

Hi, David Malcolm skribis: > How do other plugin authors feel about the API? I think this approach would lead to a duplication of each GCC API. The needs of plug-ins cannot be anticipated; artificially restricting what plug-ins can do is likely to hinder wider extension of GCC. As an example,

Re: gcc extensibility

Hi, Gabriel Dos Reis skribis: > I do not think people working on plugins have come up with a > specification and an API they agree on. I think it’s wrong to consider plug-ins as second-class citizens. The plug-in mechanism is just a technical means to allow people to extend the compiler withou

[ANN] StarPU 1.0.0, hybrid CPU/GPU task programming

We are pleased to announce StarPU 1.0.0, a GCC extension and run-time support library for hybrid CPU/GPU task programming, available from the following sites: https://gforge.inria.fr/frs/?group_id=1570 http://runtime.bordeaux.inria.fr/StarPU/files/ Home page: http://runtime.bordeaux.inria.

Re: status of GCC & C++

Hi Basile, Basile Starynkevitch skribis: > Do we have (e.g. for plugin makers) a nice way to know if a given GCC > distribution was > compiled in C or in C++ mode? I’ve written an Autoconf macro that does that: http://gcc.gnu.org/ml/gcc/2012-03/msg00240.html Thanks, Ludo’.

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

Hi Richard, Richard Guenther skribis: > 2012/3/19 Ludovic Courtès : [...] >> In the example of name mangling, I’d just have wrapped in ‘extern "C"’ >> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The >> rationale is that it simplifies plug-in

Re: GCC 4.7.0RC: Mangled names in cc1

Hello, For the interested reader, I eventually solved the nested function issue by using either nested functions or C++11 lambdas, depending on whether g++ is being used [0]. This is abstracted away by these (surprisingly not-too-ugly) macros to define a local function, and declare a function par

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

Hi, Richard Guenther skribis: > But no, I'm not volunteering (I'm volunteering to do the review work). > The above has the same issue as the "we-want-to-be-more-like-LLVM" > stuff - it lacks the people to actually implement it, and GCC at its > present state still has to evolve, we can't and do

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Gabriel Dos Reis skribis: > On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès > wrote: [...] >> What about writing it in C++?  Function objects could be passed around >> to achieve a similar result, at the expense of conciseness and >> interoperability with C. &

Re: GCC 4.7.0RC: Mangled names in cc1

Hello, Richard Guenther skribis: > 2012/3/16 Ludovic Courtès : [...] > Well, if you invent new paradigms Hmm, I didn’t invent anything here. > in your plugin that are not used by GCC itself but use GCC internals > (which all plugins have to do ...) then I know where the problem

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Richard Guenther skribis: > 2012/3/16 Ludovic Courtès : >> Hi, >> >> After writing an Autoconf macro that determines whether to build >> plug-ins with gcc or g++ [0], I realized that nested functions, which my >> plug-in uses extensively, are not supported

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, After writing an Autoconf macro that determines whether to build plug-ins with gcc or g++ [0], I realized that nested functions, which my plug-in uses extensively, are not supported in C++. Any suggestions on how to address this? Thanks, Ludo’. [0] https://gforge.inria.fr/scm/viewvc.php/tr

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> >>>> Ian Lance Taylor skribis: >>>> >>>>&

Re: GCC 4.7.0RC: Mangled names in cc1

Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> >>>> However, this means that plug-ins must now be built with g++, except &

Re: GCC 4.7.0RC: Mangled names in cc1

Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, this means that plug-ins must now be built with g++, except >> when GCC was configured with --disable-build-poststage1-with-cxx. This >> seems difficult to deal with, for plug-in

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, ludovic.cour...@inria.fr (Ludovic Courtès) skribis: > Andrew Pinski skribis: > >> 2012/3/9 Ludovic Courtès : >> >>> I believe this is not intentional, right? >> >> No, this is intentional. We bootstrap the compiler using the C++ >> front-end

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Andrew Pinski skribis: > 2012/3/9 Ludovic Courtès : > >> I believe this is not intentional, right? > > No, this is intentional. We bootstrap the compiler using the C++ > front-end now. We build stage1 with the C compiler and then build > stages 2 and 3 with the C++

GCC 4.7.0RC: Mangled names in cc1

Hi, In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0], I’m seeing C++-mangled name for common functions, like: $ objdump -T cc1 | grep build1_stat_loc 00640a00 gDF .text 007a Base _Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_ Indeed,

GCC meets Guile at its birthday party

Hello, Today is the first anniversary of GNU Guile 2.0 [0]. To celebrate it, several Guile users took on the challenge to come up in one week with a neat hack to showcase Guile integration [1]. So I’m happy to announce that this silly challenge gave birth (among other things) to Guile-GCC, Guile

Re: Dealing with compilers that pretend to be GCC

Hi, Chris Lattner skribis: > On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: > >>> >>> Interestingly enough: >>> $ cat q.c >>> __has_builtin >>> $ clang -E q.c >>> >> >> Yes, that’s what I was asking. >> >

Re: Dealing with compilers that pretend to be GCC

Hi, Marc Glisse skribis: > On Tue, 31 Jan 2012, Ludovic Courtès wrote: > >> Hi, >> >> Chris Lattner skribis: >> >>> On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: >>> >>>> Hello, >>>> >>>> C

Re: Dealing with compilers that pretend to be GCC

Hi, Chris Lattner skribis: > On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: > >> Hello, >> >> Chris Lattner skribis: >> >>> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: >>> >>>> On 21 January 2012 00:32, Vincent Lefevr

Re: Dealing with compilers that pretend to be GCC

Hello, Chris Lattner skribis: > On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: > >> On 21 January 2012 00:32, Vincent Lefevre wrote: >>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pret

Re: Dealing with compilers that pretend to be GCC

Hi, Cary Coutant skribis: >> Yeah, but it’s a shame that those compilers define __GNUC__ without >> supporting 100% of the GNU C extensions.  With this approach, you would >> also need to add !defined for Clang, PGI, and probably others. > > Having worked on the other side for a while -- for a v

Re: Dealing with compilers that pretend to be GCC

Hi, James Dennett skribis: > If there were a defined way to test for extensions from within C (or > C++), then this problem would be much reduced. Clang has something of > a framework to query support for different features, and I drafted a > proposal for something similar that would work across

Re: Dealing with compilers that pretend to be GCC

Hi Vincent, Vincent Lefevre skribis: > For ICC, one can test __ICC. For instance, here's what we have in mpfr.h > (for the use of __builtin_constant_p and __extension__ ({ ... })): > > #if defined (__GNUC__) && !defined(__ICC) && !defined(__cplusplus) Yeah, but it’s a shame that those compilers

Re: Dealing with compilers that pretend to be GCC

Duncan Sands skribis: > Why do you want to know whether the compiler > is GCC or not? Because I’m writing a plug-in for GCC. Ludo’.

Re: Dealing with compilers that pretend to be GCC

Hi Paul, Paul Eggert skribis: > A 'configure' script is supposed to check for behavior, not identity. > If the compiler supports the features needed, then generally speaking > a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests th

Re: Dealing with compilers that pretend to be GCC

Hi Ducan, Duncan Sands skribis: >> A number of compilers claim to be GCC, without actually being GCC. This >> has come to a point where they can hardly be distinguished–until one >> actually tries to use them. > > this suggests that you shouldn't be testing for GCC, and instead should be > test

Dealing with compilers that pretend to be GCC

Hello, A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/

Re: Dimensions of array parameters

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >>> Perhaps something like >>> >>> extern void foo (int a, int x[__attribute__ ((dim (a)))]) >>> >>> could be implemented. >> >> Why use special

Re: Dimensions of array parameters

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> I understand. However, I’m concerned about keeping the information at >> compile-time. For example: >> >> extern void foo (int a, int x[a]); >> static void bar (v

Re: Dimensions of array parameters

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> "Joseph S. Myers" skribis: >> >>> On Fri, 2 Dec 2011, Ludovic Courtès wrote: >>> >>>> Is there a way array dimension info could be preserved? &g

Re: Dimensions of array parameters

Hi, "Joseph S. Myers" skribis: > On Fri, 2 Dec 2011, Ludovic Courtès wrote: > >> Is there a way array dimension info could be preserved? > > Perhaps you could explain the actual problem you are trying to solve? I’m just thinking that, if that information were pr

Dimensions of array parameters

Hello, Parameters that have an array type (fixed-length or variable-length) are internally converted to have a pointer type instead (this is with 4.6.) For example: static int bar (int foo[12]) { return foo[2]; } is turned into: bar (unsigned int x, int * foo) ... Is there a wa

Re: Parameter not passed in call expr

Hi Dodji, Dodji Seketeli writes: > ludovic.cour...@inria.fr (Ludovic Courtès) a écrit: [...] >> parm = build_decl (loc, PARM_DECL, >> create_tmp_var_name ("parm"), >> void_ptr); > > > It looks like a: > >

Re: Parameter not passed in call expr

Hi, Ian Lance Taylor writes: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> DECL_INITIAL (decl) = >> build_block (NULL_TREE, NULL_TREE, decl, NULL_TREE); >> DECL_SAVED_TREE (decl) = >> build_call_expr (built_in_decls[BUILT_IN_PUTS], 1, parm

Parameter not passed in call expr

Hello, The attached plug-in builds a function like this: my_function (void * parm.0) { __builtin_puts (parm.0); } However, the generated assembly clears the first-argument register (%edi) before calling ‘puts’, instead of actually passing the parameter: my_function: .LFB0:

Re: ‘xref_tag’ lacks a public declaration

Hi, Ian Lance Taylor writes: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> ‘c-common.h’ lacks this declaration: >> >> extern tree xref_tag (enum tree_code code, tree name); >> >> AFAICS it makes it impossible for plug-ins to lookup a struct/un

Re: ‘xref_tag’ lacks a public declaration

Ian Lance Taylor writes: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >>>> extern tree xref_tag (enum tree_code code, tree name); >>>> >>>> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum >>>> tag. &g

Re: ‘xref_tag’ lacks a public declaration

Hi, Ian Lance Taylor writes: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> ‘c-common.h’ lacks this declaration: >> >> extern tree xref_tag (enum tree_code code, tree name); >> >> AFAICS it makes it impossible for plug-ins to lookup a struct/un

‘xref_tag’ lacks a public declaration

Hello, ‘c-common.h’ lacks this declaration: extern tree xref_tag (enum tree_code code, tree name); AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum tag. Unfortunately, declares a different ‘xref_tag’ function, so it seems that the above declaration cannot just be adde

Re: GUPC: A GCC frontend for UPC

Hi, Giuseppe Scrivano writes: > l...@gnu.org (Ludovic Courtès) writes: > >>> The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html. >> >> This URL is 404. > > Hey Ludovic, it works well here. Works for me now, don’t know what happened. Thanks, Ludo’.

Re: GUPC: A GCC frontend for UPC

Hello Gary, Gary Funck writes: > A GCC front-end (and runtime) for UPC (Unified Parallel C) is available > via the following GCC branch: svn://svn/gcc/branches/gupc. Good to hear! ;-) > The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html. This URL is 404. Thanks, Ludo’

Re: student internship & GCC

Hi Basile, Basile Starynkevitch writes: > My intern will hopefully be "stagiaire" at my organisation CEA - > according to my understandding, this is called "internship" in the > USA. In France, it means that he is very little paid (much less than > the minimal work wage) and that for many but n

Re: Parser extension points for plug-ins

l...@gnu.org (Ludovic Courtès) writes: > I think it may be useful to allow plug-ins to process, e.g., #pragmas. Of course soon after posting I noticed ‘PLUGIN_PRAGMAS’... Sorry for the noise, Ludo’.

Parser extension points for plug-ins

Hello, The current set of plug-in events does not appear to include extension points at the parser level. I think it may be useful to allow plug-ins to process, e.g., #pragmas. That would allow directives à la OpenMP to be added/extended, which is an increasingly popular way to augment C and othe

[ANN] ForestGOMP 0.1, a libgomp-compatible OpenMP run-time

Hello, We are pleased to announce the release of ForestGOMP 0.1, a libgomp-compatible OpenMP 2.5 run-time support library targeting high-performance computing. http://gforge.inria.fr/frs/download.php/22409/forestgomp-0.1.tar.gz SHA1: 18cb967cc21ee9effc3e4b3b2ee59ef838247a6a More information

Re: Official GCC git repository

Hi, Samuel Tardieu <[EMAIL PROTECTED]> writes: > how did you setup the git repository? The branch heads are supposed to > be located under "/refs/heads/" on gcc.gnu.org, not under > "/refs/remotes/", where you generally find the remote references: > those branches aren't supposed to be remote on

Re: Official GCC git repository

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > >> I put my version of the gcc conversion (which has all branches but no >> tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update >> it a

Re: Official GCC git repository

Hi, "Daniel Berlin" <[EMAIL PROTECTED]> writes: > I put my version of the gcc conversion (which has all branches but no > tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update > it appropriately. > > Note that i will not announce this anywhere until someone steps > forward to actua

Choosing the right TLS access model

Hi, (This message is a duplicate of a message to `gcc-help' where I did not get a definitive answer[*].) I read parts of Drepper's [0] and Oliva's [1] work on TLS access. From my understanding, the `initial-exec' model can be used safely when compiling an executable. However, it's still unclear