Re: GCC changes for Fedora + riscv64
On Apr 10 2018, Kito Cheng wrote: > You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME > environment variable to change the uname for qemu. But be aware that the emulated environment still assumes that all system calls implemented by 4.15 are available, and qemu linux-user generally just passes them through to the host kernel. If the host kernel is too old to provide a particular system call the emulation may malfunction. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: GCC changes for Fedora + riscv64
>> You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME >> environment variable to change the uname for qemu. > > But be aware that the emulated environment still assumes that all system > calls implemented by 4.15 are available, and qemu linux-user generally > just passes them through to the host kernel. If the host kernel is too > old to provide a particular system call the emulation may malfunction. Yeah, but it's enough for running gcc testsuite.
libmvec in gcc to have vector math in fortran
i had a query earlier about libmvec vector functions in fortran:
https://gcc.gnu.org/ml/gcc/2017-11/msg7.html
but there were no simple solutions to make math functions vectorizable
in fortran, because it's hard to make libc headers with simd attributes
visible to the fortran front end.
i think a possible workaround is to have a dummy libmvec implementation
in libgcc.a (or more likely as a separate libgccmvec.a) that just calls
scalar functions from libm like
vdouble _ZGVbN2v_sin(vdouble x)
{
return (vdouble){sin(x[0]), sin(x[1])};
}
and similarly for all relevant single and double precision functions
for all vector lengths and other supported variants.
then gcc knows that there is an implementation for these functions
available and with the right link order a better implementation from
libmvec can override these dummy implementations. (the cost model
cannot assume a faster vector algorithm than the scalar one though)
- this allows vectorizing loops with math functions even in fortran,
- and on targets without a libmvec implementation (but with a vector abi),
- and allows users to provide their own vector math implementation
more easily without hacking around glibc math.h (which may not support
vector math or only enable it for a small subset of math functions).
gcc needs a new cflag and ldflag to enable this.
(maybe -mveclibabi= already present in x86 and ppc can be used for this)
Re: libmvec in gcc to have vector math in fortran
On Tue, Apr 10, 2018 at 12:45 PM, Szabolcs Nagy
wrote:
> i had a query earlier about libmvec vector functions in fortran:
> https://gcc.gnu.org/ml/gcc/2017-11/msg7.html
>
> but there were no simple solutions to make math functions vectorizable
> in fortran, because it's hard to make libc headers with simd attributes
> visible to the fortran front end.
>
> i think a possible workaround is to have a dummy libmvec implementation
> in libgcc.a (or more likely as a separate libgccmvec.a) that just calls
> scalar functions from libm like
>
> vdouble _ZGVbN2v_sin(vdouble x)
> {
> return (vdouble){sin(x[0]), sin(x[1])};
> }
>
> and similarly for all relevant single and double precision functions
> for all vector lengths and other supported variants.
>
> then gcc knows that there is an implementation for these functions
> available and with the right link order a better implementation from
> libmvec can override these dummy implementations. (the cost model
> cannot assume a faster vector algorithm than the scalar one though)
>
> - this allows vectorizing loops with math functions even in fortran,
> - and on targets without a libmvec implementation (but with a vector abi),
> - and allows users to provide their own vector math implementation
> more easily without hacking around glibc math.h (which may not support
> vector math or only enable it for a small subset of math functions).
>
> gcc needs a new cflag and ldflag to enable this.
> (maybe -mveclibabi= already present in x86 and ppc can be used for this)
>
>
As I mentioned previously in that thread you linked to, the fortran
frontend never generates a direct call to libm sin(), or for that matter
ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And
similarly for other libm functions that have gcc builtins. The middle-end
optimizers are then free to do whatever optimizations they like on that
__builtin_sin call, such as constant folding, and at least as far as the
fortran frontend is concerned, vectorizing if -mveclibabi= or such is in
effect.
--
Janne Blomqvist
Re: libmvec in gcc to have vector math in fortran
On 10/04/18 11:14, Janne Blomqvist wrote: As I mentioned previously in that thread you linked to, the fortran frontend never generates a direct call to libm sin(), or for that matter ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And similarly for other libm functions that have gcc builtins. The middle-end optimizers are then free to do whatever optimizations they like on that __builtin_sin call, such as constant folding, and at least as far as the fortran frontend is concerned, vectorizing if -mveclibabi= or such is in effect. the generated builtin call is not the issue (same happens in c), the knowledge about libc declarations is. the middle-end has no idea what functions can be vectorized, only the libc knows it and declares this in c headers. this is the problem i'm trying to solve.
Re: libmvec in gcc to have vector math in fortran
On Tue, Apr 10, 2018 at 11:22:03AM +0100, Szabolcs Nagy wrote:
> On 10/04/18 11:14, Janne Blomqvist wrote:
> > As I mentioned previously in that thread you linked to, the fortran
> > frontend never generates a direct call to libm sin(), or for that matter
> > ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And
> > similarly for other libm functions that have gcc builtins. The
> > middle-end optimizers are then free to do whatever optimizations they
> > like on that __builtin_sin call, such as constant folding, and at least
> > as far as the fortran frontend is concerned, vectorizing if -mveclibabi=
> > or such is in effect.
>
> the generated builtin call is not the issue (same happens in c),
> the knowledge about libc declarations is.
>
> the middle-end has no idea what functions can be vectorized,
> only the libc knows it and declares this in c headers.
>
> this is the problem i'm trying to solve.
And the easiest solution is in the Fortran FE based on some flag
(e.g. -mveclibabi=glibc) through a target hook add
__attribute__((__simd__ ("notinbranch")))
to the builtins like __builtin_sin etc. that have them in the
glibc header (x86_64 -m64 and -ffast-math only):
# undef __DECL_SIMD_cos
# define __DECL_SIMD_cos __DECL_SIMD_x86_64
# undef __DECL_SIMD_cosf
# define __DECL_SIMD_cosf __DECL_SIMD_x86_64
# undef __DECL_SIMD_sin
# define __DECL_SIMD_sin __DECL_SIMD_x86_64
# undef __DECL_SIMD_sinf
# define __DECL_SIMD_sinf __DECL_SIMD_x86_64
# undef __DECL_SIMD_sincos
# define __DECL_SIMD_sincos __DECL_SIMD_x86_64
# undef __DECL_SIMD_sincosf
# define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
# undef __DECL_SIMD_log
# define __DECL_SIMD_log __DECL_SIMD_x86_64
# undef __DECL_SIMD_logf
# define __DECL_SIMD_logf __DECL_SIMD_x86_64
# undef __DECL_SIMD_exp
# define __DECL_SIMD_exp __DECL_SIMD_x86_64
# undef __DECL_SIMD_expf
# define __DECL_SIMD_expf __DECL_SIMD_x86_64
# undef __DECL_SIMD_pow
# define __DECL_SIMD_pow __DECL_SIMD_x86_64
# undef __DECL_SIMD_powf
# define __DECL_SIMD_powf __DECL_SIMD_x86_64
The sincos/sincosf stuff is questionable, because some glibc versions
implement it incorrectly and the simd ("notinbranch") attribute isn't that
useful for it anyway, we'd want to use extra clauses so that it doesn't need
to do scatter stores.
Jakub
Re: libmvec in gcc to have vector math in fortran
On Tue, Apr 10, 2018 at 12:29 PM, Jakub Jelinek wrote:
> On Tue, Apr 10, 2018 at 11:22:03AM +0100, Szabolcs Nagy wrote:
>> On 10/04/18 11:14, Janne Blomqvist wrote:
>> > As I mentioned previously in that thread you linked to, the fortran
>> > frontend never generates a direct call to libm sin(), or for that matter
>> > ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And
>> > similarly for other libm functions that have gcc builtins. The
>> > middle-end optimizers are then free to do whatever optimizations they
>> > like on that __builtin_sin call, such as constant folding, and at least
>> > as far as the fortran frontend is concerned, vectorizing if -mveclibabi=
>> > or such is in effect.
>>
>> the generated builtin call is not the issue (same happens in c),
>> the knowledge about libc declarations is.
>>
>> the middle-end has no idea what functions can be vectorized,
>> only the libc knows it and declares this in c headers.
>>
>> this is the problem i'm trying to solve.
>
> And the easiest solution is in the Fortran FE based on some flag
> (e.g. -mveclibabi=glibc) through a target hook add
> __attribute__((__simd__ ("notinbranch")))
> to the builtins like __builtin_sin etc. that have them in the
> glibc header (x86_64 -m64 and -ffast-math only):
>
> # undef __DECL_SIMD_cos
> # define __DECL_SIMD_cos __DECL_SIMD_x86_64
> # undef __DECL_SIMD_cosf
> # define __DECL_SIMD_cosf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sin
> # define __DECL_SIMD_sin __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sinf
> # define __DECL_SIMD_sinf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sincos
> # define __DECL_SIMD_sincos __DECL_SIMD_x86_64
> # undef __DECL_SIMD_sincosf
> # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_log
> # define __DECL_SIMD_log __DECL_SIMD_x86_64
> # undef __DECL_SIMD_logf
> # define __DECL_SIMD_logf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_exp
> # define __DECL_SIMD_exp __DECL_SIMD_x86_64
> # undef __DECL_SIMD_expf
> # define __DECL_SIMD_expf __DECL_SIMD_x86_64
> # undef __DECL_SIMD_pow
> # define __DECL_SIMD_pow __DECL_SIMD_x86_64
> # undef __DECL_SIMD_powf
> # define __DECL_SIMD_powf __DECL_SIMD_x86_64
>
> The sincos/sincosf stuff is questionable, because some glibc versions
> implement it incorrectly and the simd ("notinbranch") attribute isn't that
> useful for it anyway, we'd want to use extra clauses so that it doesn't need
> to do scatter stores.
I wonder if it is possible for glibc to ship a "module" for fortran instead
containing the appropriate declarations and gfortran auto-include that
(if present).
Hard-coding stuff like suggested above is of course possible but not
very forward compatible with changes in glibc.
Richard.
> Jakub
Re: libmvec in gcc to have vector math in fortran
On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > And the easiest solution is in the Fortran FE based on some flag
>> > (e.g. -mveclibabi=glibc) through a target hook add
>> > __attribute__((__simd__ ("notinbranch")))
>> > to the builtins like __builtin_sin etc. that have them in the
>> > glibc header (x86_64 -m64 and -ffast-math only):
>> >
>> > # undef __DECL_SIMD_cos
>> > # define __DECL_SIMD_cos __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_cosf
>> > # define __DECL_SIMD_cosf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sin
>> > # define __DECL_SIMD_sin __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sinf
>> > # define __DECL_SIMD_sinf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sincos
>> > # define __DECL_SIMD_sincos __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sincosf
>> > # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_log
>> > # define __DECL_SIMD_log __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_logf
>> > # define __DECL_SIMD_logf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_exp
>> > # define __DECL_SIMD_exp __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_expf
>> > # define __DECL_SIMD_expf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_pow
>> > # define __DECL_SIMD_pow __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_powf
>> > # define __DECL_SIMD_powf __DECL_SIMD_x86_64
>> >
>> > The sincos/sincosf stuff is questionable, because some glibc
>versions
>> > implement it incorrectly and the simd ("notinbranch") attribute
>isn't that
>> > useful for it anyway, we'd want to use extra clauses so that it
>doesn't need
>> > to do scatter stores.
>>
>> I wonder if it is possible for glibc to ship a "module" for fortran
>instead
>> containing the appropriate declarations and gfortran auto-include
>that
>> (if present).
>
>Then we'd run into module binary format changing every release, so hard
>for
>glibc to ship that.
It's just nobody bothered to implement version dependent parsing (it's plain
text after all).
>Another thing is how would we express it in the module,
>we could just use OpenMP syntax,
> interface
>function sin(x) bind(C,name="__builtin_sin") result(res)
> import
> !$omp declare simd notinbranch
> real(c_double) :: res
> real(c_double),value :: x
>end function
> end interface
>but we'd need to temporarily enable OpenMP while parsing that module.
>I see Fortran now supports already
>!GCC$ attributes stdcall, fastcall::test
>Could we support
>!GCC$ attributes simd
>and
>!GCC$ attributes simd('notinbranch')
>too?
I guess that would be useful indeed.
Richard.
> Jakub
Re: libmvec in gcc to have vector math in fortran
On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
>> > And the easiest solution is in the Fortran FE based on some flag
>> > (e.g. -mveclibabi=glibc) through a target hook add
>> > __attribute__((__simd__ ("notinbranch")))
>> > to the builtins like __builtin_sin etc. that have them in the
>> > glibc header (x86_64 -m64 and -ffast-math only):
>> >
>> > # undef __DECL_SIMD_cos
>> > # define __DECL_SIMD_cos __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_cosf
>> > # define __DECL_SIMD_cosf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sin
>> > # define __DECL_SIMD_sin __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sinf
>> > # define __DECL_SIMD_sinf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sincos
>> > # define __DECL_SIMD_sincos __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_sincosf
>> > # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_log
>> > # define __DECL_SIMD_log __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_logf
>> > # define __DECL_SIMD_logf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_exp
>> > # define __DECL_SIMD_exp __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_expf
>> > # define __DECL_SIMD_expf __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_pow
>> > # define __DECL_SIMD_pow __DECL_SIMD_x86_64
>> > # undef __DECL_SIMD_powf
>> > # define __DECL_SIMD_powf __DECL_SIMD_x86_64
>> >
>> > The sincos/sincosf stuff is questionable, because some glibc
>versions
>> > implement it incorrectly and the simd ("notinbranch") attribute
>isn't that
>> > useful for it anyway, we'd want to use extra clauses so that it
>doesn't need
>> > to do scatter stores.
>>
>> I wonder if it is possible for glibc to ship a "module" for fortran
>instead
>> containing the appropriate declarations and gfortran auto-include
>that
>> (if present).
>
>Then we'd run into module binary format changing every release, so hard
>for
>glibc to ship that.
>
>Another thing is how would we express it in the module,
>we could just use OpenMP syntax,
> interface
>function sin(x) bind(C,name="__builtin_sin") result(res)
> import
> !$omp declare simd notinbranch
> real(c_double) :: res
> real(c_double),value :: x
>end function
> end interface
>but we'd need to temporarily enable OpenMP while parsing that module.
>I see Fortran now supports already
>!GCC$ attributes stdcall, fastcall::test
>Could we support
>!GCC$ attributes simd
>and
>!GCC$ attributes simd('notinbranch')
>too?
Maybe we can also generate this module in a fixinlclude way?
> Jakub
Re: libmvec in gcc to have vector math in fortran
On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
> > And the easiest solution is in the Fortran FE based on some flag
> > (e.g. -mveclibabi=glibc) through a target hook add
> > __attribute__((__simd__ ("notinbranch")))
> > to the builtins like __builtin_sin etc. that have them in the
> > glibc header (x86_64 -m64 and -ffast-math only):
> >
> > # undef __DECL_SIMD_cos
> > # define __DECL_SIMD_cos __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_cosf
> > # define __DECL_SIMD_cosf __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_sin
> > # define __DECL_SIMD_sin __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_sinf
> > # define __DECL_SIMD_sinf __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_sincos
> > # define __DECL_SIMD_sincos __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_sincosf
> > # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_log
> > # define __DECL_SIMD_log __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_logf
> > # define __DECL_SIMD_logf __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_exp
> > # define __DECL_SIMD_exp __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_expf
> > # define __DECL_SIMD_expf __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_pow
> > # define __DECL_SIMD_pow __DECL_SIMD_x86_64
> > # undef __DECL_SIMD_powf
> > # define __DECL_SIMD_powf __DECL_SIMD_x86_64
> >
> > The sincos/sincosf stuff is questionable, because some glibc versions
> > implement it incorrectly and the simd ("notinbranch") attribute isn't that
> > useful for it anyway, we'd want to use extra clauses so that it doesn't need
> > to do scatter stores.
>
> I wonder if it is possible for glibc to ship a "module" for fortran instead
> containing the appropriate declarations and gfortran auto-include that
> (if present).
Then we'd run into module binary format changing every release, so hard for
glibc to ship that.
Another thing is how would we express it in the module,
we could just use OpenMP syntax,
interface
function sin(x) bind(C,name="__builtin_sin") result(res)
import
!$omp declare simd notinbranch
real(c_double) :: res
real(c_double),value :: x
end function
end interface
but we'd need to temporarily enable OpenMP while parsing that module.
I see Fortran now supports already
!GCC$ attributes stdcall, fastcall::test
Could we support
!GCC$ attributes simd
and
!GCC$ attributes simd('notinbranch')
too?
Jakub
Re: GCC changes for Fedora + riscv64
On 04/10/2018 01:55 AM, Andreas Schwab wrote: > On Apr 10 2018, Kito Cheng wrote: > >> You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME >> environment variable to change the uname for qemu. > > But be aware that the emulated environment still assumes that all system > calls implemented by 4.15 are available, and qemu linux-user generally > just passes them through to the host kernel. If the host kernel is too > old to provide a particular system call the emulation may malfunction. Well understood. For my needs it likely is a non-issue. jeff
Re: GCC changes for Fedora + riscv64
On 04/10/2018 12:27 AM, Richard W.M. Jones wrote: > On Mon, Apr 09, 2018 at 04:37:30PM -0600, Jeff Law wrote: >> Are you guys using qemu user mode emulation for testing purposes? When >> I've set up a suitable riscv64 rootfs and try to do anything nontrivial >> in it with qemu user mode emulation it immediately complains that my >> kernel is too old -- which is quite odd as I've got a dozen or so of >> these kinds of environments set up for testing which don't issue that >> complaint. >> >> I'd like to avoid full system emulation just from a cost standpoint.. > > We're using full system emulation with upstream qemu. It's > surprisingly simple to set up, it supports multiple virtual CPUs up to > ‘-smp 8’, and provided you have a fast enough host hardware isn't too > bad for development. Of course compiling GCC with bootstrapping is > still going to take a long time. For instructions see the readme > here: It's actually a continuous testing system rather than development :-) A typical target using user mode emulation takes 6-10 hours to to run through its paces on one of our 56 processor build machines. I'd hazard a guess if we do full system emulation then we're likely looking at doubling that or worse, which I'd like to avoid given the number of targets I'm trying to get tested in a 24hr cycle. > > https://fedorapeople.org/groups/risc-v/disk-images/ Yea. I actually looked at those briefly to confirm that kernel too old issue triggered there too. For my tester I actually use mini roots that I cross build for the various targets. The advantage is the contents of the mini roots is consistent across the targets. Thanks, Jeff
Re: www.sgi.com/tech/stl/ is gone
On 19 March 2018 at 17:12, Jonathan Wakely wrote: > On 18 March 2018 at 23:37, Gerald Pfeifer wrote: >> ...redirecting to a dummy page. Unfortunately there are a fair >> number of references in the libstdc++ docs, see below. >> >> I'll take care of anything outside of libstdc++; can you please >> have a look as far as the libstdc++ docs go? >> >> Gerald >> >> >> http://gcc.gnu.org/onlinedocs/libstdc++/faq.html >> >> □ http://www.sgi.com/tech/stl/ >> □ http://www.sgi.com/tech/stl/FAQ.html >> □ http://www.sgi.com/tech/stl/whats_new.html >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_design.html >> >> □ http://www.sgi.com/tech/stl/ >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_numerics.html >> >> □ http://www.sgi.com/tech/stl/iota.html >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_sgi.html >> >> □ http://www.sgi.com/tech/stl/HashFunction.html >> □ http://www.sgi.com/tech/stl/hash.html >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/policy_data_structures.html >> >> □ http://www.sgi.com/tech/stl/ >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html >> >> □ http://www.sgi.com/tech/stl/Allocators.html >> □ http://www.sgi.com/tech/stl/thread_safety.html >> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/utilities.html >> >> □ http://www.sgi.com/tech/stl/functors.html > > I suggest we use the archived copy at > https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/ Done with this patch (I will regenerate the HTML after some more doc changes). Committed to trunk, backports to follow. commit 719e805c69e3ebb653ab0cc179b149ee54870807 Author: Jonathan Wakely Date: Tue Apr 10 16:46:58 2018 +0100 Update links to archived copy of SGI STL docs * doc/xml/faq.xml: Update links to archived copy of SGI STL docs. * doc/xml/manual/backwards_compatibility.xml: Likewise. * doc/xml/manual/containers.xml: Likewise. * doc/xml/manual/debug_mode.xml: Likewise. * doc/xml/manual/extensions.xml: Likewise. * doc/xml/manual/policy_data_structures_biblio.xml: Likewise. * doc/xml/manual/using.xml: Likewise. * doc/xml/manual/utilities.xml: Likewise. diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml index 3e315e2d5ba..b0b1f98e641 100644 --- a/libstdc++-v3/doc/xml/faq.xml +++ b/libstdc++-v3/doc/xml/faq.xml @@ -1132,9 +1132,9 @@ Libstdc++-v3 incorporates a lot of code from -http://www.w3.org/1999/xlink"; xlink:href="http://www.sgi.com/tech/stl/";>the SGI STL +http://www.w3.org/1999/xlink"; xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/";>the SGI STL (the final merge was from -http://www.w3.org/1999/xlink"; xlink:href="http://www.sgi.com/tech/stl/whats_new.html";>release 3.3). +http://www.w3.org/1999/xlink"; xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/whats_new.html";>release 3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code. @@ -1153,7 +1153,7 @@ compatibility documentation. -The http://www.w3.org/1999/xlink"; xlink:href="http://www.sgi.com/tech/stl/FAQ.html";>FAQ +The http://www.w3.org/1999/xlink"; xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/FAQ.html";>FAQ for SGI's STL is still recommended reading. diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml index dbb33719fb3..aa95f3eb1c9 100644 --- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml +++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml @@ -536,7 +536,7 @@ particular info iostream. against the gthr.h abstraction layer which is provided by gcc. A minor problem that pops up every so often is different interpretations of what "thread-safe" means for a - library (not a general program). We currently use the http://www.w3.org/1999/xlink"; xlink:href="http://www.sgi.com/tech/stl/thread_safety.html";>same + library (not a general program). We currently use the http://www.w3.org/1999/xlink"; xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html";>same definition that SGI uses for their STL subset. However, the exception for read-only containers only applies to the STL components. This definition is widely-used and something similar diff --git a/libstdc++-v3/doc/xml/manual/containers.xml b/libstdc++-v3/doc/xml/manual/containers.xml index e81c7f06875..5c9854efbdd 100644 --- a/libstdc++-v3/doc/xml/manual/containers.xml +++ b/libstdc++-v3/doc/xml/manual/containers.xml @@ -28,7 +28,7 @@ Yes it is, at least using the old ABI, and that's okay. This is a decision
Re: Internal compiler error building libstdc++ for vax
On Sun, 8 Apr 2018, Jeff Law wrote: > I think you need to go back to my earlier reply and read it carefully. > In particular, you need an insn where the label_ref and pc are swapped. Ouch, there are no reversed interlocked branch instructions in the VAX ISA, so these would have to branch around a jump. Like say: (define_insn "*jbbssisi_reversed" [(parallel [(set (pc) (if_then_else (ne (zero_extract:SI (match_operand:SI 0 "memory_operand" "Q") (const_int 1) (match_operand:SI 1 "general_operand" "nrm")) (const_int 0)) (pc)) (label_ref (match_operand 2 "" ""))) (set (zero_extract:SI (match_operand:SI 3 "memory_operand" "+0") (const_int 1) (match_dup 1)) (const_int 1))])] "" "jbssi %1,%0,0f;jbr %l2;0:") and likewise with the other modes. Is this what you have in mind? Maciej
Re: Internal compiler error building libstdc++ for vax
On 04/10/2018 01:27 PM, Maciej W. Rozycki wrote: > On Sun, 8 Apr 2018, Jeff Law wrote: > >> I think you need to go back to my earlier reply and read it carefully. >> In particular, you need an insn where the label_ref and pc are swapped. > > Ouch, there are no reversed interlocked branch instructions in the VAX > ISA, so these would have to branch around a jump. Like say: > > (define_insn "*jbbssisi_reversed" > [(parallel > [(set (pc) > (if_then_else > (ne (zero_extract:SI (match_operand:SI 0 "memory_operand" "Q") >(const_int 1) >(match_operand:SI 1 "general_operand" "nrm")) > (const_int 0)) > (pc)) > (label_ref (match_operand 2 "" ""))) > (set (zero_extract:SI (match_operand:SI 3 "memory_operand" "+0") > (const_int 1) > (match_dup 1)) > (const_int 1))])] > "" > "jbssi %1,%0,0f;jbr %l2;0:") > > and likewise with the other modes. > > Is this what you have in mind? Yea. Various parts of GCC assume that it can swap the pc/label_ref to invert the branch. At least that was the case in the past. You could always create the pattern with the inefficient jump-around-jump to verify behavior. Wandering through jump.c it appears that it now tries to validate the changes as they occur. So if creating the swapped pattern works, it might be beneficial to see which pass creates the swapped version and see if it can be twiddled to use validate_change or a similar API to avoid the need for the swapped pattern. Jeff
