Re: [PATCH v3] Re: avoid useless if-before-free tests
On Fri, Apr 15, 2011 at 10:54, Jim Meyering wrote: > Janne Blomqvist wrote: > >> On Thu, Mar 24, 2011 at 18:51, Jim Meyering wrote: >>> Janne Blomqvist wrote: On Tue, Mar 8, 2011 at 19:53, Jim Meyering wrote: > Relative to v2, I've added libgo/ to the list of exempt directories and > added > this recently discussed gfc_free patch, at the request of Tobias Burnus. > Also, I corrected an error in fortran's ChangeLog and removed all > whitespace changes from all ChangeLog files. The libgfortran changes are Ok for 4.7. For the gfortran frontend (gcc/fortran/*) I'd prefer if you'd - Replace all calls to "gfc_free (x)" with "free (x)". - Remove the gfc_free() function and prototype. - Remove the free() macro which currently prevents calling free() directly. >>> >>> Following up, I've refreshed the series but hit a minor snag >>> while converting new uses of gfc_free, removing new tests-before-free >>> and merging/reordering changes. >>> >>> Applying this fix first makes my problem go away: >> >> [snip] >> >> So, what's the plan here? Do you plan to get a GCC account, do you >> already have one, or what? Now that 4.7 is open for development, it's >> perhaps the right time to poke the maintainers to get this patch in. >> >> If you don't have a GCC account, as one of the Fortran maintainers I >> can commit the Fortran and libgfortran parts, but someone else will >> have to do the rest (were they ever approved, BTW?) as I have only >> write after approval privileges for the rest of GCC. > > Can someone add me to the gcc group? That would help. > I already have ssh access to sourceware.org. According to http://gcc.gnu.org/svnwrite.html , you should send an email to overseers(at)gcc.gnu.org . It says that you need a sponsor and "The steering committee or a well-established GCC maintainer (including reviewers) can approve for write access any person with GNU copyright assignment papers in place and known to submit good patches.". I'm not sure if I'm considered to be well-established enough, so could someone help Jim out here, please? Or, if nobody pipes up within a few days, just mention my name as your sponsor and we'll see if the overseers consider me well-established or not.. ;) -- Janne Blomqvist
Re: [PATCH v3] Re: avoid useless if-before-free tests
Janne Blomqvist wrote: > On Fri, Apr 15, 2011 at 10:54, Jim Meyering wrote: >> Janne Blomqvist wrote: >> >>> On Thu, Mar 24, 2011 at 18:51, Jim Meyering wrote: Janne Blomqvist wrote: > On Tue, Mar 8, 2011 at 19:53, Jim Meyering wrote: >> Relative to v2, I've added libgo/ to the list of exempt >> directories and added >> this recently discussed gfc_free patch, at the request of Tobias Burnus. >> Also, I corrected an error in fortran's ChangeLog and removed all >> whitespace changes from all ChangeLog files. > > The libgfortran changes are Ok for 4.7. > > For the gfortran frontend (gcc/fortran/*) I'd prefer if you'd > > - Replace all calls to "gfc_free (x)" with "free (x)". > - Remove the gfc_free() function and prototype. > - Remove the free() macro which currently prevents calling free() > directly. Following up, I've refreshed the series but hit a minor snag while converting new uses of gfc_free, removing new tests-before-free and merging/reordering changes. Applying this fix first makes my problem go away: >>> >>> [snip] >>> >>> So, what's the plan here? Do you plan to get a GCC account, do you >>> already have one, or what? Now that 4.7 is open for development, it's >>> perhaps the right time to poke the maintainers to get this patch in. >>> >>> If you don't have a GCC account, as one of the Fortran maintainers I >>> can commit the Fortran and libgfortran parts, but someone else will >>> have to do the rest (were they ever approved, BTW?) as I have only >>> write after approval privileges for the rest of GCC. >> >> Can someone add me to the gcc group? That would help. >> I already have ssh access to sourceware.org. > > According to http://gcc.gnu.org/svnwrite.html , you should send an > email to overseers(at)gcc.gnu.org . It says that you need a sponsor > and "The steering committee or a well-established GCC maintainer > (including reviewers) can approve for write access any person with GNU > copyright assignment papers in place and known to submit good > patches.". I'm not sure if I'm considered to be well-established > enough, so could someone help Jim out here, please? > > Or, if nobody pipes up within a few days, just mention my name as your > sponsor and we'll see if the overseers consider me well-established or > not.. ;) Thanks. FYI, I have an "ANY" assignment on file, so no need to wait for paperwork.
RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
Dear all, I have question how one can and should tell the middle end about asynchonous/single-sided memory access; the goal is to produce fast but race-free code. All the following is about Fortran 2003 (asynchronous) and Fortran 2008 (coarrays), but the problem itself should occur with all(?) supported languages. It definitely occurs when using C with MPI or using C with the asynchronous I/O functions, though I do not know in how far one currently relys on luck. There are two issues, which need to be solved by informing the middle end - either by variable attributes or by inserted function calls: - Prohibiting some code movements - Making assumptions about the memory content a) ASYNCHRONOUS attribute and asynchronous I/O Fortran allows asynchronous I/O, which means for the programmer that between initiating the asynchronous reading/writing and the finishing read/write, the variable may not be accessed (for READ) or not be changed (for WRITE). The compiler needs to make sure that it does not move code such that this constraint is violated. All variables involved in asynchronous operations are marked as ASYNCHRONOUS. Thus, for asynchronous operations, code movements involving opaque function calls should not happen - but contrary to VOLATILE, there is no need to take the value all time from the memory if it is still in the register. Example: integer, ASYNCHRONOUS :: async_int WRITE (unit, ASYNCHRONOUS='yes') async_int ! ... WAIT (unit) a = async_int do i = 1, 10 b(i) = async_int + 1 end do Here, "a = async_int" may not be moved before the WAIT line. However, contrary to VOLATILE, one can move the "async_int + 1" before the loop and use the value from the registry in the loop. Note additionally that the initiation of an asynchronous operation (WRITE statement above) is known at compile time; however, it is not known when it ends - the WAIT can be in a different translation unit. See also PR 25829. The Fortran 2008 standard is not very explicit about the ASYNCHRONOUS attribute itself; it simply states that it is for asynchronous I/O. (However, it describes then how async I/O works, including WAIT, INQUIRE, and what a programmer may do until the async I/O is finished.) The closed to an ASYNCHRONOUS definition is the non-normative note 5.4 of Fortran 2008: "The ASYNCHRONOUS attribute specifies the variables that might be associated with a pending input/output storage sequence (the actual memory locations on which asynchronous input/output is being performed) while the scoping unit is in execution. This information could be used by the compiler to disable certain code motion optimizations." Seemingly intended, but not that clear in the F2003/F2008 standard, is to allow for asynchronous user operations; this will presumbly refined in TR 29113 which is currently being drafted - and/or in an interpretation request. The main requestee for this feature is the MPI Forum, which works on MPI3. In any case the following should work analogously and "buf" should not be moved before the "MPI_Wait" line: CALL MPI_Irecv(buf, rq) CALL MPI_Wait(rq) xnew=buf Hereby, "buf" and (maybe?) the first dummy argument of MPI_Irecv have the ASYNCHRONOUS attribute. My question is now: How to properly tell this the middle end? VOLATILE seems to be wrong as it prevents way too many optimizations and I think it does not completely prevent code moving. Using a call to some built-in function does not work as in principle the end of an asynchronous operation is not known. It could end with a WAIT - possibly also wrapped in a function, which is in a different translation unit - or also with an INQUIRE(..., PENDING=aio_pending) if "aio_pending" gets assigned a .false. (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I think might be implemented by preventing all code movements which involve swapping an ASYNCHRONOUS variable with a function call, which is not pure. Otherwise, in terms of the variable value, it acts like a normal variable, i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via function calls), it remains 7. The changing of the variable is explicit - even if it only becomes effective with some delay.) B) COARRAYS The memory model of coarrays is that all memory is private to the image - except for coarrays. Coarrays exists on all images. For "integer :: coarray(:)[*]", local accesses are "coarray = ..." or "coarray(4) = ..." while remote accesses are "coarray(:)[7] = ..." or "a = coarray(3)[2]", where the data is set on image 7 or pulled from image 2. Let's start directly with an example: module m integer, save :: caf_int[*] ! Global variable end module m subroutine foo() use m caf_int = 7 ! Set local variable to 7 (effectively: on image 1 only) SYNC ALL ! Memory barrier/fence SYNC ALL ! caf_int should now be 8, cf. below; thus the f
Re: Problem with induction variables optimization pass
On Fri, Apr 15, 2011 at 12:33 AM, Camo Johnson wrote:
>
> Hello,
>
> I'm currently writing a gcc 4.4.5 backend for an 18 bit architecture.
> I have a c-project with some thousand lines of code. Without optimizations it
> compiles. But with -O1 and -O2 I encounter a problem in the induction
> variables
> optimization pass.
> The main issue is, that a temporary variable is created which works as a
> memory
> reference but is a 36 bit value (SImode). This results in an error at explow.c
> line 326, because pointers have to be 18 bit wide (HImode).
> The code at this position is:
>
> rtx
> convert_memory_address (enum machine_mode to_mode ATTRIBUTE_UNUSED, rtx x)
> {
> #ifndef POINTERS_EXTEND_UNSIGNED
> gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode);
>
> This asserts because x has mode SI and to_mode is Pmode/HImode.
>
> I used the -fdump-tree-all option and in the source.c.126t.final_cleanup file
> I
> found the following:
>
> isr00 ()
> {
> unsigned int ivtmp.112;
> unsigned int D.3690;
> long unsigned int D.3683;
> unsigned int ivtmp.105;
> unsigned int ivtmp.104;
> unsigned int prephitmp.91;
> unsigned int length;
> unsigned int D.1415;
> struct usb * usb0.0;
>
> …
>
> :
> D.3683 = (long unsigned int) ivtmp.105 + (long unsigned int) ((unsigned int *)
> (long unsigned int) usb0.0 + 320);
> spi_temporary_data[ivtmp.112] = [bit_and_expr] (unsigned char) (MEM[base:
> D.3683] >> 8) & 255;
> spi_temporary_data[ivtmp.112 + 1] = [bit_and_expr] (unsigned char) MEM[base:
> D.3683] & 255
>
> The problem is the D.3683 variable. The casts in the assignment for this
> variable are kind of senseless, because ivtmp.105 is unsigned int (18 bit),
> usb0.0 is a pointer which is also only 18 bit.
>
> I checked the source files and I think the main problem is the use of sizetype
> in several locations working with addresses. sizetype is defined as long
> unsigned int and results in SImode when used. I found 3 code positions with an
> input tree mode of HImode where the use of sizetype or size_type_node results
> in
> a tree node with SImode:
>
> tree-ssa-address.c line 414
> here parts->index becomes a SImode tree node
>
> static void
> add_to_parts (struct mem_address *parts, tree elt)
> {
> tree type;
>
> if (!parts->index)
> {
> parts->index = fold_convert (sizetype, elt);
> return;
> }
>
> tree-ssa-address.c line 547
> here part becomes a SImode tree node
>
> static void
> addr_to_parts (aff_tree *addr, struct mem_address *parts, bool speed)
> {
> ...
> /* Then try to process the remaining elements. */
> for (i = 0; i < addr->n; i++)
> {
> part = fold_convert (sizetype, addr->elts[i].val);
> ...
> }
>
> tree.cline 8332
> here t becomes a SImode tree node
>
> signed_or_unsigned_type_for (int unsignedp, tree type)
> {
> tree t = type;
> if (POINTER_TYPE_P (type))
> t = size_type_node;
>
> if (!INTEGRAL_TYPE_P (t) || TYPE_UNSIGNED (t) == unsignedp)
> return t;
>
> return lang_hooks.types.type_for_size (TYPE_PRECISION (t), unsignedp);
> }
>
>
>
> As a solution, I tried to replace those 3 sizetype uses with
> global_trees[TI_UINTHI_TYPE]. So the relevant lines look like this:
>
> parts->index = fold_convert (global_trees[TI_UINTHI_TYPE] /*sizetype*/, elt);
> part = fold_convert (global_trees[TI_UINTHI_TYPE] /*sizetype*/,
> addr->elts[i].val);
> t = global_trees[TI_UINTHI_TYPE] /*size_type_node*/;
>
> With those changes, the compilation comes farther but crashes on the following
> gcc_assert:
> tree.cline 3312function build2_stat
>
> if (code == POINTER_PLUS_EXPR && arg0 && arg1 && tt)
> gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
> && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
> && useless_type_conversion_p (sizetype, TREE_TYPE (arg1)));
>
> If I comment out the "&& useless_type_conversion_p (sizetype, TREE_TYPE
> (arg1))"
> part the compilation works. I know its bad, but I don't know how to replace
> the
> sizetype in this case so that the assert doesn't happen.
>
>
> I'm aware of the fact that those fixes would result in errors with other
> architectures. But just for my "strange 18 bit" architecture, is this ok?
> Might
> there be problems in some cases? Why is sizetype used in this positions
> anyways?
> Wouldn't it be better to somehow use the input tree type instead of sizetype?
It was a design decision to use sizetype for offsets in pointer arithmetic
as this is also how offsets and sizes in types are computed. It is also
a known fact that there are various issues with architectures that have
a sizetype that is wider or narrower than a pointer.
Why can't you make sizetype HImode?
> I hope the description of the problem is understandable.
>
> Regards,
> Eric Neumann
>
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Fri, Apr 15, 2011 at 12:02, Tobias Burnus wrote:
> Dear all,
>
> I have question how one can and should tell the middle end about
> asynchonous/single-sided memory access; the goal is to produce fast but
> race-free code. All the following is about Fortran 2003 (asynchronous) and
> Fortran 2008 (coarrays), but the problem itself should occur with all(?)
> supported languages. It definitely occurs when using C with MPI or using C
> with the asynchronous I/O functions, though I do not know in how far one
> currently relys on luck.
>
> There are two issues, which need to be solved by informing the middle end -
> either by variable attributes or by inserted function calls:
> - Prohibiting some code movements
> - Making assumptions about the memory content
>
> a) ASYNCHRONOUS attribute and asynchronous I/O
>
> Fortran allows asynchronous I/O, which means for the programmer that between
> initiating the asynchronous reading/writing and the finishing read/write,
> the variable may not be accessed (for READ) or not be changed (for WRITE).
> The compiler needs to make sure that it does not move code such that this
> constraint is violated. All variables involved in asynchronous operations
> are marked as ASYNCHRONOUS.
>
> Thus, for asynchronous operations, code movements involving opaque function
> calls should not happen - but contrary to VOLATILE, there is no need to take
> the value all time from the memory if it is still in the register.
>
> Example:
>
> integer, ASYNCHRONOUS :: async_int
>
> WRITE (unit, ASYNCHRONOUS='yes') async_int
> ! ...
> WAIT (unit)
> a = async_int
> do i = 1, 10
> b(i) = async_int + 1
> end do
>
> Here, "a = async_int" may not be moved before the WAIT line. However,
> contrary to VOLATILE, one can move the "async_int + 1" before the loop and
> use the value from the registry in the loop. Note additionally that the
> initiation of an asynchronous operation (WRITE statement above) is known at
> compile time; however, it is not known when it ends - the
> WAIT can be in a different translation unit. See also PR 25829.
>
> The Fortran 2008 standard is not very explicit about the ASYNCHRONOUS
> attribute itself; it simply states that it is for asynchronous I/O.
> (However, it describes then how async I/O works,
> including WAIT, INQUIRE, and what a programmer may do until the async I/O is
> finished.) The closed to an ASYNCHRONOUS definition is the non-normative
> note 5.4 of Fortran 2008:
>
> "The ASYNCHRONOUS attribute specifies the variables that might be associated
> with a pending input/output storage sequence (the actual memory locations on
> which asynchronous input/output is being performed) while the scoping unit
> is in execution. This information could be used by the compiler to disable
> certain code motion optimizations."
>
> Seemingly intended, but not that clear in the F2003/F2008 standard, is to
> allow for asynchronous user operations; this will presumbly refined in TR
> 29113 which is currently being drafted - and/or in an interpretation
> request. The main requestee for this feature is the MPI Forum, which works
> on MPI3. In any case the following should work analogously and "buf" should
> not be moved before the "MPI_Wait" line:
>
> CALL MPI_Irecv(buf, rq)
> CALL MPI_Wait(rq)
> xnew=buf
>
> Hereby, "buf" and (maybe?) the first dummy argument of MPI_Irecv have the
> ASYNCHRONOUS attribute.
>
> My question is now: How to properly tell this the middle end?
>
> VOLATILE seems to be wrong as it prevents way too many optimizations and I
> think it does not completely prevent code moving. Using a call to some
> built-in function does not work as in principle the end of an asynchronous
> operation is not known. It could end with a WAIT - possibly also wrapped in
> a function, which is in a different translation unit - or also with an
> INQUIRE(..., PENDING=aio_pending) if "aio_pending" gets assigned a .false.
>
> (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I
> think might be implemented by preventing all code movements which involve
> swapping an ASYNCHRONOUS variable with a function call, which is not pure.
> Otherwise, in terms of the variable value, it acts like a normal variable,
> i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via
> function calls), it remains 7. The changing of the variable is explicit -
> even if it only becomes effective with some delay.)
A compiler memory barrier in GCC is
asm volatile("" ::: "memory");
That being said, does the middle end really move loads and stores past
function calls? If not, a call is effectively also a compiler memory
barrier, no?
> B) COARRAYS
>
> The memory model of coarrays is that all memory is private to the image -
> except for coarrays. Coarrays exists on all images. For "integer ::
> coarray(:)[*]", local accesses are "coarray = ..." or "coarray(4) = ..."
> while remote accesses are "coarray(:)[7] = ..." or "a = coarray(3)[2]",
> where the d
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Fri, Apr 15, 2011 at 11:52 AM, Janne Blomqvist
wrote:
> On Fri, Apr 15, 2011 at 12:02, Tobias Burnus wrote:
>> Dear all,
>>
>> I have question how one can and should tell the middle end about
>> asynchonous/single-sided memory access; the goal is to produce fast but
>> race-free code. All the following is about Fortran 2003 (asynchronous) and
>> Fortran 2008 (coarrays), but the problem itself should occur with all(?)
>> supported languages. It definitely occurs when using C with MPI or using C
>> with the asynchronous I/O functions, though I do not know in how far one
>> currently relys on luck.
>>
>> There are two issues, which need to be solved by informing the middle end -
>> either by variable attributes or by inserted function calls:
>> - Prohibiting some code movements
>> - Making assumptions about the memory content
>>
>> a) ASYNCHRONOUS attribute and asynchronous I/O
>>
>> Fortran allows asynchronous I/O, which means for the programmer that between
>> initiating the asynchronous reading/writing and the finishing read/write,
>> the variable may not be accessed (for READ) or not be changed (for WRITE).
>> The compiler needs to make sure that it does not move code such that this
>> constraint is violated. All variables involved in asynchronous operations
>> are marked as ASYNCHRONOUS.
>>
>> Thus, for asynchronous operations, code movements involving opaque function
>> calls should not happen - but contrary to VOLATILE, there is no need to take
>> the value all time from the memory if it is still in the register.
>>
>> Example:
>>
>> integer, ASYNCHRONOUS :: async_int
>>
>> WRITE (unit, ASYNCHRONOUS='yes') async_int
>> ! ...
>> WAIT (unit)
>> a = async_int
>> do i = 1, 10
>> b(i) = async_int + 1
>> end do
>>
>> Here, "a = async_int" may not be moved before the WAIT line. However,
>> contrary to VOLATILE, one can move the "async_int + 1" before the loop and
>> use the value from the registry in the loop. Note additionally that the
>> initiation of an asynchronous operation (WRITE statement above) is known at
>> compile time; however, it is not known when it ends - the
>> WAIT can be in a different translation unit. See also PR 25829.
>>
>> The Fortran 2008 standard is not very explicit about the ASYNCHRONOUS
>> attribute itself; it simply states that it is for asynchronous I/O.
>> (However, it describes then how async I/O works,
>> including WAIT, INQUIRE, and what a programmer may do until the async I/O is
>> finished.) The closed to an ASYNCHRONOUS definition is the non-normative
>> note 5.4 of Fortran 2008:
>>
>> "The ASYNCHRONOUS attribute specifies the variables that might be associated
>> with a pending input/output storage sequence (the actual memory locations on
>> which asynchronous input/output is being performed) while the scoping unit
>> is in execution. This information could be used by the compiler to disable
>> certain code motion optimizations."
>>
>> Seemingly intended, but not that clear in the F2003/F2008 standard, is to
>> allow for asynchronous user operations; this will presumbly refined in TR
>> 29113 which is currently being drafted - and/or in an interpretation
>> request. The main requestee for this feature is the MPI Forum, which works
>> on MPI3. In any case the following should work analogously and "buf" should
>> not be moved before the "MPI_Wait" line:
>>
>> CALL MPI_Irecv(buf, rq)
>> CALL MPI_Wait(rq)
>> xnew=buf
>>
>> Hereby, "buf" and (maybe?) the first dummy argument of MPI_Irecv have the
>> ASYNCHRONOUS attribute.
>>
>> My question is now: How to properly tell this the middle end?
>>
>> VOLATILE seems to be wrong as it prevents way too many optimizations and I
>> think it does not completely prevent code moving. Using a call to some
>> built-in function does not work as in principle the end of an asynchronous
>> operation is not known. It could end with a WAIT - possibly also wrapped in
>> a function, which is in a different translation unit - or also with an
>> INQUIRE(..., PENDING=aio_pending) if "aio_pending" gets assigned a .false.
>>
>> (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I
>> think might be implemented by preventing all code movements which involve
>> swapping an ASYNCHRONOUS variable with a function call, which is not pure.
>> Otherwise, in terms of the variable value, it acts like a normal variable,
>> i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via
>> function calls), it remains 7. The changing of the variable is explicit -
>> even if it only becomes effective with some delay.)
>
> A compiler memory barrier in GCC is
>
> asm volatile("" ::: "memory");
>
> That being said, does the middle end really move loads and stores past
> function calls? If not, a call is effectively also a compiler memory
> barrier, no?
Yes, a function call is also a compiler memory barrier for all memory
that the function can possibly access. There is currently no easy way
to restrict the barr
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Tobias Burnus wrote: (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I think might be implemented by preventing all code movements which involve swapping an ASYNCHRONOUS variable with a function call, which is not pure. Otherwise, in terms of the variable value, it acts like a normal variable, i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via function calls), it remains 7. The changing of the variable is explicit - even if it only becomes effective with some delay.) I am, but I am not sure how to describe them. The relevant constraints on the program are in Fortran 2008 9.6.4.1 paras 5 and 6 (page 220), and here is roughly what it means for the compiler. The ASYNCHRONOUS attribute says that a variable may be used for such purposes, and therefore can be changed unpredictably (if writable) or referenced unpredictably, at any point while it is 'active' for asynchronous I/O (i.e. it is a pending input-output sequence affector, a term that I find bizarre). It is a bit like the intent of VOLATILE, in that respect only. But it also says: 1) The program may not change it if it is liable to be referenced, or reference it if it is liable to be changed. But this applies ONLY during those windows of vulnerability. 2) A window of vulnerability can be changed only by explicit action, either an asynchronous I/O statement or calling a procedure that has access to that variable. Note that closing the window doesn't need explicit access, as it operates on just a 'transfer token', but that is as if the action that opened the window squirreled away a pointer to the array when it started the asynchronous I/O. This means that, if a compiler can determine that code is NOT in a window of vulnerability, all normal optimisations can be applied. And, if the window is for reference only, reference to the variable and taking a copy is allowed. For example, if there is an assignment statement to it or it is passed as an argument to a procedure without ASYNCHRONOUS or INTENT(IN), the compiler can tell that there is no I/O in progress at that point. Similarly, if it is referenced or passed to a procedure without ASYNCHRONOUS but with INTENT(IN), it may be being referenced but won't be being changed (asynchronously). Of course, that may not be the case. But, if it isn't, the program is broken, and the behaviour is undefined - so what the hell? And I apologise about my English :-) I don't have time just now to rephrase it in less arcane usage, and am aware that it is tricky. Regards, Nick Maclaren.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On 04/15/2011 11:52 AM, Janne Blomqvist wrote: Q1: Is __sync_synchronize() sufficient? I don't think this is correct. __sync_synchronize() just issues a hardware memory fence instruction.That is, it prevents loads and stores from moving past the fence *on the processor that executes the fence instruction*. There is no synchronization with other processors. Well, I was thinking of (a) assumptions regarding the value for the compiler when doing optimizations. And (b) making sure that the variables are really loaded from memory and not remain in the register. -- How the data ends up in memory is a different question; for the current library version, SYNC ALL would be a __sync_synchronize() followed by a (wrapped) call to MPI_Barrier - and possibly some additional actions. Q2: Can this be optimized in some way? Probably not. For general issues with the shared-memory model, perhaps shared memory Co-arrays can piggyback on the work being done for the C++0x memory model, see I think you try to solve a different problem than I want. I am not talking about implementing a full SYNC ALL, but I want to implement for SYNC ALL that no code moving happens and that the memory is moved out of the register into the memory - and related, fetched from the memory afterwards. On 04/15/2011 12:02 PM, Richard Guenther wrote: Q2: Can this be optimized in some way? For simple types you could use atomic instructions for the modification itself instead of two SYNC ALL calls. Well, even with atomic you need to have a barrier; besides the example was only for illustration. I think if one uses the variable in "foo" before the first sync all, one even would need two barriers - atomic read/write or not. (For the current example, setting the value in "foo" is pointless. And the obfuscated way the variable is set, makes the program fragile: someone modifying might not see the dependency and break it.) To conclude: * For ASYNCHRONOUS, one mostly does not need to do anything. Except that for the asynchronous version of the transfer function belonging to READ and WRITE, the data argument needs to be marked as escaping in the "fn spec" attribute. Similarly, for ASYNCHRONOUS dummy arguments, the "fn spec" must be such that the compiler knows the the address could be escaping. (I don't think there is currently a way to mark via "fn spec" a variable as escaping but only be used for reading the value - or to restrict the scope of the escaping.) * For coarrays, I still claim that __sync_synchronize() is enough for SYNC* in terms of restricting code moving and ensuring the registers are put into the memory - and for succeeding accesses to the variable, the data comes from the memory. (The actual implementation of a barrier is a separate task - be it a library call or some shared-memory atomic counter. Only for SYNC MEMORY it should be fully sufficient.) Comments? Tobias PS: The coarray example will fail if there more than two images as one can wait for ever for the SYNC with image 3, with image 4, ...
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Fri, Apr 15, 2011 at 2:04 PM, Tobias Burnus wrote: > On 04/15/2011 11:52 AM, Janne Blomqvist wrote: >> >> Q1: Is __sync_synchronize() sufficient? >> I don't think this is correct. __sync_synchronize() just issues a >> hardware memory fence instruction.That is, it prevents loads and >> stores from moving past the fence *on the processor that executes the >> fence instruction*. There is no synchronization with other >> processors. > > Well, I was thinking of (a) assumptions regarding the value for the compiler > when doing optimizations. And (b) making sure that the variables are really > loaded from memory and not remain in the register. -- How the data ends up > in memory is a different question; for the current library version, SYNC ALL > would be a __sync_synchronize() followed by a (wrapped) call to MPI_Barrier > - and possibly some additional actions. > >>> Q2: Can this be optimized in some way? >> >> Probably not. For general issues with the shared-memory model, perhaps >> shared memory Co-arrays can piggyback on the work being done for the >> C++0x memory model, see > > I think you try to solve a different problem than I want. I am not talking > about implementing a full SYNC ALL, but I want to implement for SYNC ALL > that no code moving happens and that the memory is moved out of the register > into the memory - and related, fetched from the memory afterwards. > > > On 04/15/2011 12:02 PM, Richard Guenther wrote: Q2: Can this be optimized in some way? >> >> For simple types you could use atomic instructions for the modification >> itself instead of two SYNC ALL calls. > > Well, even with atomic you need to have a barrier; besides the example was > only for illustration. I think if one uses the variable in "foo" before the > first sync all, one even would need two barriers - atomic read/write or not. > (For the current example, setting the value in "foo" is pointless. And the > obfuscated way the variable is set, makes the program fragile: someone > modifying might not see the dependency and break it.) As long as all variables that need protection are global a random function call before and after is enough to avoid optimization. > To conclude: > > * For ASYNCHRONOUS, one mostly does not need to do anything. Except that for > the asynchronous version of the transfer function belonging to READ and > WRITE, the data argument needs to be marked as escaping in the "fn spec" > attribute. Similarly, for ASYNCHRONOUS dummy arguments, the "fn spec" must > be such that the compiler knows the the address could be escaping. (I don't > think there is currently a way to mark via "fn spec" a variable as escaping > but only be used for reading the value - or to restrict the scope of the > escaping.) That's correct. Richard. > * For coarrays, I still claim that __sync_synchronize() is enough for SYNC* > in terms of restricting code moving and ensuring the registers are put into > the memory - and for succeeding accesses to the variable, the data comes > from the memory. (The actual implementation of a barrier is a separate task > - be it a library call or some shared-memory atomic counter. Only for SYNC > MEMORY it should be fully sufficient.) > > Comments? > > Tobias > > PS: The coarray example will fail if there more than two images as one can > wait for ever for the SYNC with image 3, with image 4, ... >
Re: [PATCH v3] Re: avoid useless if-before-free tests
> "Janne" == Janne Blomqvist writes: Jim> Can someone add me to the gcc group? That would help. Jim> I already have ssh access to sourceware.org. Janne> I'm not sure if I'm considered to be well-established Janne> enough, so could someone help Jim out here, please? I added Jim to the gcc group. Tom
Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011
Please contact us before 22/Apr to confirm your assistance. We need to have an idea of how many people to expect for planning. Thanks. Diego. -- Forwarded message -- From: Diego Novillo Date: Fri, Apr 8, 2011 at 16:15 Subject: GCC Gathering in London 17/Jun to 19/Jun 2011 To: g...@gnu.org, Ian Taylor We are organizing a gathering of GCC developers and interested parties at the Google office in London, UK for the weekend of 17-Jun-2011. The gathering will be Friday evening, all day Saturday, and Sunday until some time in the afternoon. The idea is to simply get together and discuss current/future work, coordinate efforts, and perhaps do some collective GCC hacking. The format is going to be an informal unconference: - No papers. - No prepared presentations (unless it's really interesting). - No attendance fees. Google will provide meeting facilities and food. We have space for about 100 people. Attendees are responsible for travel and accommodations. We will meet Friday evening and coordinate a list of topics for discussion. We could also work something out in advance. At the moment, we need to know how many developers would attend. Please RSVP before 22-Apr-2011. Let us know if you might come; it's not a commitment. The Google London office is near Victoria Station at Belgrave House 76 Buckingham Palace Road London SW1W 9TQ United Kingdom http://maps.google.com/?q=Google%20London@51.495238,-0.146663&hl=en Diego and Ian.
Announce: MELT plugin (0.7) release candidate 3 for GCC 4.6
Hello All,
I am announcing the release candidate #3 of the MELT plugin (v0.7) replacing
the rc2 of http://gcc.gnu.org/ml/gcc/2011-04/msg00220.html
You can download a gzipped tar source ball of MELT 0.7 as plugin for GCC 4.6
from http://gcc-melt.org/melt-0.7rc3-plugin-for-gcc-4.6.tgz
a gzip-ed tar archive of 3347804 bytes of md5sum
da117c8df77efd7b6d98d51250ddf698 (april 15th 2011). It is extracted from
MELT branch svn revision 172493.
You need a gcc-4.6 with plugins (and cloog and graphite) enabled.
Improvements from previous rc2 include bug fixes and some documentation.
Comment are welcome. If you have been able to build the MELT plugin so
released, please tell me by private email. Bugs reports (including build
failure of the MELT plugin) are also welcome.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Richard Guenther wrote: On Fri, Apr 15, 2011 at 2:04 PM, Tobias Burnus wrote: Q2: Can this be optimized in some way? For simple types you could use atomic instructions for the modification itself instead of two SYNC ALL calls. Well, even with atomic you need to have a barrier; besides the example was only for illustration. I think if one uses the variable in "foo" before the first sync all, one even would need two barriers - atomic read/write or not. (For the current example, setting the value in "foo" is pointless. And the obfuscated way the variable is set, makes the program fragile: someone modifying might not see the dependency and break it.) As long as all variables that need protection are global a random function call before and after is enough to avoid optimization. Today in gcc, perhaps. But it's NOT a good idea to rely on it, as it is broken by many of the optimisations that Fortran traditionally uses I don't think that gfortran uses them, but could be wrong, and it might well change. It also doesn't extend to threading, whether the extra threads are explicit or 'helper' threads. Extra incantations are needed. Regards, Nick Maclaren.
Volatile memory move
Hi,
I am running into trouble with a volatile memory move on my port of
GCC4.4.4. The code is:
int main(void)
{
register volatile float sc = 1E35;
if(sc < 1.5e35)
return 1;
return 0;
}
The very first part of this code is being expanded as:
;; sc ={v} 1.000409184787596297531937521664e+35;
(insn 5 4 6 vol.c:3 (set (reg/f:QI 20)
(symbol_ref/u:QI ("*?LC0") [flags 0x2])) -1 (nil))
(insn 6 5 7 vol.c:3 (set (reg:QI 1 AL)
(mem/u/c/i:QI (plus:QI (reg/f:QI 20)
(const_int 1 [0x1])) [2 S1 A16])) -1 (nil))
(insn 7 6 8 vol.c:3 (set (reg:QI 0 AH)
(mem/u/c/i:QI (reg/f:QI 20) [2 S1 A16])) -1 (nil))
(insn 8 7 9 vol.c:3 (set (mem/v/c/i:QI (plus:QI (reg/f:QI 14
virtual-stack-vars)
(const_int 1 [0x1])) [2 sc+1 S1 A16])
(reg:QI 1 AL)) -1 (nil))
(insn 9 8 0 vol.c:3 (set (subreg:QI (mem/v/c/i:HI (reg/f:QI 14
virtual-stack-vars) [2 sc+0 S2 A16]) 0)
(reg:QI 0 AH)) -1 (nil))
Now, the problem with this comes with insn 9 that has a subreg:QI of a
mem:HI it seems. The raw move we are trying to do is:
(set (mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2 A16])
(mem/u/c/i:HI (reg/f:QI 20) [2 S2 A16]))
To do this we need to go through two QImode registers AL and AH and I
have as part of my port:
emit_move_insn(gen_rtx_REG(QImode, RAL), gen_lowpart(QImode,
operands[1]));
emit_move_insn(gen_rtx_REG(QImode, RAH), gen_highpart(QImode,
operands[1]));
emit_move_insn(gen_lowpart(QImode, operands[0]),
gen_rtx_REG(QImode, RAL));
emit_move_insn(gen_highpart(QImode, operands[0]),
gen_rtx_REG(QImode, RAH));
The problem here comes with gen_lowpart and gen_highpart applied to:
(mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2 A16])
gen_lowpart generates: (mem/v/c/i:QI (plus:QI (reg/f:QI 14
virtual-stack-vars)(const_int 1 [0x1]))
but gen_highpart generates:
(subreg:QI (mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2
A16]) 0)
Why is that? Any suggestion on solving this situation?
Cheers,
Paulo Matos
Re: [PATCH v3] Re: avoid useless if-before-free tests
> I added Jim to the gcc group. Thanks, Tom.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Fri, Apr 15, 2011 at 15:04, Tobias Burnus wrote: > On 04/15/2011 11:52 AM, Janne Blomqvist wrote: >> >> Q1: Is __sync_synchronize() sufficient? >> I don't think this is correct. __sync_synchronize() just issues a >> hardware memory fence instruction.That is, it prevents loads and >> stores from moving past the fence *on the processor that executes the >> fence instruction*. There is no synchronization with other >> processors. > > Well, I was thinking of (a) assumptions regarding the value for the compiler > when doing optimizations. And (b) making sure that the variables are really > loaded from memory and not remain in the register. -- How the data ends up > in memory is a different question; for the current library version, SYNC ALL > would be a __sync_synchronize() followed by a (wrapped) call to MPI_Barrier > - and possibly some additional actions. > >>> Q2: Can this be optimized in some way? >> >> Probably not. For general issues with the shared-memory model, perhaps >> shared memory Co-arrays can piggyback on the work being done for the >> C++0x memory model, see > > I think you try to solve a different problem than I want. Indeed, I assumed you were discussing how to implement CAF via shared memory. If we use MPI, surely the implementation of MPI_Barrier should itself issue any necessary memory fences (if it uses shared memory), so I don't think __sync_synchronize() would be necessary? And, as Richi already mentioned, the function call itself is an implicit compiler memory barrier for all variables which might be accessed by the callee. Which implies that any such variables must be flushed to memory before the call and reloaded if read after the call returns. So, in this case I don't think there is anything to worry about. FWIW, the optimization implications of the C++0x (and C1X) memory model I referred to earlier refers mostly to avoiding compiler introduced data races for potentially shared variables. That is, if the compiler cannot prove that a variable is accessible only from the current thread (e.g. non-escaped stack variables), some optimizations are forbidden. But, to the extent that all cross-co-image access happens via calling MPI procedures, I don't think this will affect the CAF implementation. However, if we ever make a shared memory CAF backend, then it might matter (and, one hopes, by that time the GCC C++ memory model work is further along). > * For ASYNCHRONOUS, one mostly does not need to do anything. Except that for > the asynchronous version of the transfer function belonging to READ and > WRITE, the data argument needs to be marked as escaping in the "fn spec" > attribute. Similarly, for ASYNCHRONOUS dummy arguments, the "fn spec" must > be such that the compiler knows the the address could be escaping. (I don't > think there is currently a way to mark via "fn spec" a variable as escaping > but only be used for reading the value - or to restrict the scope of the > escaping.) Wrt AIO, as you know I have now and then worked on an implementation. Though by now it's again probably more than half a year since I looked into it. But, to be honest, the more I think about it the less convinced I am about the usefulness of it. As none of the alternatives is really satisfactory (including at least some semblance of portability), the implementation is sort of a lowest common denominator, based on the thread pool and work queue pattern. Which means there is overhead to to the threads (e.g. context switching, locking etc.). OTOH, plain blocking IO is in some sense "asynchronous" as well: A write() is essentially a memcpy() from user space to the kernel page cache, and the kernel takes care of writing out the data to permanent storage after write() returns. For read()'s the situation is somewhat similar, except there is the possibility that the data is not found in the page cache and must be read from disk. However in this case if the read()'s are sequential the kernel will figure it out and prefetch data into the page cache. So that leaves basically uncached random reads as the use case for AIO. So how common is that kind of performance bottleneck in Fortran applications? Might be different if Fortran were widely used for implementing event-based network servers, but it isn't. This doesn't mean that the frontend support for ASYNCHRONOUS is useless; MPI_ISend/Recv are certainly a common existing usecase. -- Janne Blomqvist
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Janne Blomqvist wrote: Indeed, I assumed you were discussing how to implement CAF via shared memory. If we use MPI, surely the implementation of MPI_Barrier should itself issue any necessary memory fences (if it uses shared memory), so I don't think __sync_synchronize() would be necessary? It doesn't have any such semantics. Any fences are issued by MPI_Wait, but see below. And, as Richi already mentioned, the function call itself is an implicit compiler memory barrier for all variables which might be accessed by the callee. Which implies that any such variables must be flushed to memory before the call and reloaded if read after the call returns. So, in this case I don't think there is anything to worry about. Not in a threaded context, or with shared memory segments! Mere function calls have no effect whatsoever on memory consistency between threads, and you really, but REALLY, want to avoid doing full memory barriers more than you can help. For complicated reasons, they can be more expensive than MPI_Barrier, though they are at least sane and reliable (unlike 'fences'). If the majority of the code is going to be common between an MPI and a shared memory implementation, explicit synchronisation is needed, though it might well be a dummy call under MPI. Regards, Nick Maclaren.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Fri, Apr 15, 2011 at 22:19, N.M. Maclaren wrote: > On Apr 15 2011, Janne Blomqvist wrote: >> >> Indeed, I assumed you were discussing how to implement CAF via shared >> memory. If we use MPI, surely the implementation of MPI_Barrier should >> itself issue any necessary memory fences (if it uses shared memory), >> so I don't think __sync_synchronize() would be necessary? > > It doesn't have any such semantics. I don't understand what you mean by that. My point is that if a shared memory implementation of MPI_Barrier requires issuing memory fence instructions as part of the barrier algorithm, then it's up to the MPI implementation to issue them and thus we don't need to worry about it. Or are you saying that the semantics of CAF SYNC ALL is MPI_Barrier + a full memory fence on all images, and as we cannot guarantee that MPI_Barrier will actually issue fences we must potentially issue another one? >> And, as >> Richi already mentioned, the function call itself is an implicit >> compiler memory barrier for all variables which might be accessed by >> the callee. Which implies that any such variables must be flushed to >> memory before the call and reloaded if read after the call returns. >> So, in this case I don't think there is anything to worry about. > > Not in a threaded context, or with shared memory segments! My point was that even if we have shared memory, we don't need to handle function calls any differently. > Mere function calls have no effect whatsoever on memory consistency > between threads, and you really, but REALLY, want to avoid doing full > memory barriers more than you can help. Indeed, which is why shared variable programming models tend to have explicit synchronization constructs instead of having implicit barriers at function call boundaries. > For complicated reasons, they > can be more expensive than MPI_Barrier, though they are at least sane > and reliable (unlike 'fences'). Really? Why? -- Janne Blomqvist
Problem with gcc linker
I am using gcc with the following version info on 64-bit Ubunut 10.10. = g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. --- GNU ld (GNU Binutils for Ubuntu) 2.20.51-system.20100908 Copyright 2010 Free Software Foundation, Inc. My project consists of several shared libraries (.so file) and one executable. The program 'myprog' is linked with, say, libA.so, libB.so, libC.so, libD.so, and these libraries are put in /usr/local/lib. This path is used to build the libraries and the program, i.e. the -L flag of the linker. At first everything seems to work fine for a while, but all of a sudden the generated program 'myprog' would not run any more because the loader says the program cannot find certain libraries. I use Eclipse C++ plug-in and Code::Blocks for IDE and both experience the same problem. I run 'ldd myprog' and it shows something like: linux-vdso.so.1 => (0x7fff45539000) libA.so => not found libB.so => not found libC.so => /usr/local/lib/libC.so (0x7fa6dd84a000) libD.so => /usr/local/lib/libD.so (0x7fa6dda4a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fa6ddc4a000) libm.so.6 => /lib/libm.so.6 (0x7fa6dd9c7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fa6dd7b1000) libc.so.6 => /lib/libc.so.6 (0x7fa6dd42d000) libpthread.so.0 => /lib/libpthread.so.0 (0x7fa6dd21) librt.so.1 => /lib/librt.so.1 (0x7fa6dca07000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x7fa6dc7fd000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x7fa6dc5ba000) /lib64/ld-linux-x86-64.so.2 (0x7fa6e03b8000) The srtange thing is that those missing libraries are in /usr/local/lib and only some libraries are flagged as 'not found' while some libraries are fine. Out of desperation, I made libA.so and libB.so static libraries libA.a and libB.a, and have libC.so link with them. But the linker now says libC.so has unresolved symbols like: /usr/local/lib/libC.so: undefined reference to `O::O()' /usr/local/lib/libC.so: undefined reference to `O::Dump(char const*, char const*)' /usr/local/lib/libC.so: undefined reference to `Address::Address(string const&)' /usr/local/lib/libC.so: undefined reference to `B::B(char const*, char const*)' /usr/local/lib/libC.so: undefined reference to `B::Init(string const&)' when it tries to link 'myprog'. (Not when it is building libC.so) When I use 'nm -C libA.a', and 'nm -C libB.a' the symbol are all there: libA.a 3514 T O::O() 2f8c T O::Dump(char const*, char const*) 2c36 T Address::Address(string const&) libB.a 4538 T B::B(char const*, char const*) cf2c T B::Init(string const&) But when I use 'nm -C -D libC.so' these symbol are flags as 'U'. U O::O() U O::Dump(char const*, char const*) U Address::Address(string const&) U B::B(char const*, char const*) U B::Init(string const&) Strange thing is that only certain symbols from are unresolved. Other symbols from the same libraries are there. Can anyone shed some light on how the linker generate the shared/static libraries and why some libraries are not linked while some are, even when they are all available from the same location. Alex
gcc-4.6-20110415 is now available
Snapshot gcc-4.6-20110415 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110415/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 172524 You'll find: gcc-4.6-20110415.tar.bz2 Complete GCC (includes all of below) MD5=f243064c4a3f0a6694bb8c77e78604a3 SHA1=1165cd972cfc7918ad19c4f1ce7af0a8edb31b15 gcc-core-4.6-20110415.tar.bz2C front end and core compiler MD5=aed037654091d1f478dfcb6e13444325 SHA1=30bb0b34f067c2377fa8b622fd688e55709c08d1 gcc-ada-4.6-20110415.tar.bz2 Ada front end and runtime MD5=0c2d89f9e2e614ad84c6e2aa239c5c1c SHA1=73bf37e2b6a320250c4ee18318db5c3a194a gcc-fortran-4.6-20110415.tar.bz2 Fortran front end and runtime MD5=c346e76014569b25e2869ff986d2ac2d SHA1=c66d4647ad39cf67c141cfe9cb4d6c0837ef7b28 gcc-g++-4.6-20110415.tar.bz2 C++ front end and runtime MD5=8d4b78c03c1d477c6cb562d42f461958 SHA1=fc3bf0885e1513908f136e5c07c60652a0f43d43 gcc-go-4.6-20110415.tar.bz2 Go front end and runtime MD5=50bab6a0c9e5403ea77f57361dec5436 SHA1=e9d911a9ebd025e51ace9e3f0192e739a7530b15 gcc-java-4.6-20110415.tar.bz2Java front end and runtime MD5=71be1bb44398937a2942ed2f8a523c48 SHA1=b4453d973b09035a015255ca5a9a407d6b1e3a3c gcc-objc-4.6-20110415.tar.bz2Objective-C front end and runtime MD5=8376485de1c7aa90bb32f52f2372d451 SHA1=0c73506ba817d3230399138519e4553666883b9b gcc-testsuite-4.6-20110415.tar.bz2 The GCC testsuite MD5=6e0032461f87ce60db6302ca652ae9d8 SHA1=37c327c88d870f895b2b1fa3a123c9bea6e5c948 Diffs from 4.6-20110408 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Problem with gcc linker
Alex Chen writes: > The srtange thing is that those missing libraries are in > /usr/local/lib and only some libraries are flagged as 'not found' > while some libraries are fine. This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for gcc developers. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. If you are running on a GNU/Linux system, check "man ldconfig" and see if that is the problem. Ian
