Re: [RFC] Offloading Support in libgomp
Hi!
On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin"
wrote:
> [patch for adding plugins support in libgomp]
One question:
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> +/* This functions scans folder, specified in environment variable
> + LIBGOMP_PLUGIN_PATH, and loads all suitable libgomp plugins from this
> folder.
> + For a plugin to be suitable, its name should be "libgomp-plugin-*.so.1"
> and
> + it should implement a certain set of functions.
> + Result of this function is properly initialized variable NUM_DEVICES and
> + array DEVICES, containing all plugins and their callback handles. */
> +static void
> +gomp_find_available_plugins (void)
> +{
> + char *plugin_path = NULL;
> +[...]
> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
What is the benefit of making this an environment variable that the user
set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
(There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
easier, and it generally seems to make sense to me that the compiler
(libgomp) should be able to locate its own resources, and I don't think
the plugin search path is something that a user generally would want to
override -- or is your use case indeed that the plugin is not built as
part of libgomp's build process? (But, in this case you still could use
LD_LIBRARY_PATH to have it found.)
Grüße,
Thomas
pgp0x_Eqo0MfP.pgp
Description: PGP signature
Re: [RFC] Offloading Support in libgomp
2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
>> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
>
> What is the benefit of making this an environment variable that the user
> set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
> (There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
> LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
> easier, and it generally seems to make sense to me that the compiler
> (libgomp) should be able to locate its own resources, and I don't think
> the plugin search path is something that a user generally would want to
> override -- or is your use case indeed that the plugin is not built as
> part of libgomp's build process? (But, in this case you still could use
> LD_LIBRARY_PATH to have it found.)
Hi,
We invented this environment variable almost a year ago, when we
didn’t fully understand how all the parts will work together. So for
now, likely, your proposal is better.
Jakub, what do you think?
-- Ilya
P.S. Michael is no longer working on this, I'm continuing his work.
Re: [RFC] Offloading Support in libgomp
On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> >
> > What is the benefit of making this an environment variable that the user
> > set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> > somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
> > (There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
> > LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
> > easier, and it generally seems to make sense to me that the compiler
> > (libgomp) should be able to locate its own resources, and I don't think
> > the plugin search path is something that a user generally would want to
> > override -- or is your use case indeed that the plugin is not built as
> > part of libgomp's build process? (But, in this case you still could use
> > LD_LIBRARY_PATH to have it found.)
>
> We invented this environment variable almost a year ago, when we
> didn’t fully understand how all the parts will work together. So for
> now, likely, your proposal is better.
> Jakub, what do you think?
Yeah, certainly. Though, ideally the path it looks at should be relative
to the directory where libgomp is installed, and I'm afraid it is hard to
figure out portably where it was loaded from, and DT_RPATH/DT_RUNPATH on
libgomp would affect all dlopen calls, not just the loading of the plugins.
Not sure if one can use at least on Linux ${ORIGIN} in dlopen and what
exactly will it expand to.
Jakub
Re: [RFC] Offloading Support in libgomp
Hi!
On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek wrote:
> On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> > >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> > >
> > > What is the benefit of making this an environment variable that the user
> > > set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> > > somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
> > > (There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
> > > LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
> > > easier, and it generally seems to make sense to me that the compiler
> > > (libgomp) should be able to locate its own resources, and I don't think
> > > the plugin search path is something that a user generally would want to
> > > override -- or is your use case indeed that the plugin is not built as
> > > part of libgomp's build process? (But, in this case you still could use
> > > LD_LIBRARY_PATH to have it found.)
> >
> > We invented this environment variable almost a year ago, when we
> > didn’t fully understand how all the parts will work together. So for
> > now, likely, your proposal is better.
> > Jakub, what do you think?
>
> Yeah, certainly. Though, ideally the path it looks at should be relative
> to the directory where libgomp is installed
Right...
> and I'm afraid it is hard to
> figure out portably where it was loaded from, and DT_RPATH/DT_RUNPATH on
> libgomp would affect all dlopen calls, not just the loading of the plugins.
> Not sure if one can use at least on Linux ${ORIGIN} in dlopen and what
> exactly will it expand to.
I haven't verified, but I'd guess it to expand to the *executable*
linking against libgomp, so that won't help...
I have, however, found some logic in gcc/plugin.c that seems at least
similar to what we need:
gcc/doc/plugins.texi:
@node Plugins loading
@section Loading Plugins
Plugins are supported on platforms that support @option{-ldl
-rdynamic}. They are loaded by the compiler using @code{dlopen}
and invoked at pre-determined locations in the compilation
process.
Plugins are loaded with
@option{-fplugin=/path/to/@var{name}.so} [...]
[...]
A plugin can be simply given by its short name (no dots or
slashes). When simply passing @option{-fplugin=@var{name}}, the plugin is
loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}} is
the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
using backquote shell syntax to query the @file{plugin} directory.
gcc/plugin.c:
/* Retrieve the default plugin directory. The gcc driver should have passed
it as -iplugindir to the cc1 program, and it is queriable through
the
-print-file-name=plugin option to gcc. */
const char*
default_plugin_dir_name (void)
{
if (!plugindir_string)
fatal_error ("-iplugindir option not passed from the gcc driver");
return plugindir_string;
}
But I'm not yet sure how we could use this to tie the libgomp plugin
search path to the location of libgomp.so... Especially, given that the
location of libgomp.so during compilation need not match the location
during execution. A show-stopper? (No time currently to explore this in
more detail.)
Grüße,
Thomas
pgpM1fisFTYnW.pgp
Description: PGP signature
Re: [RFC] Offloading Support in libgomp
Hi!
On Thu, 17 Jul 2014 14:58:04 +0200, I wrote:
> On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek wrote:
> > On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> > > >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> > > >
> > > > What is the benefit of making this an environment variable that the user
> > > > set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> > > > somewhere inside the GCC installation directory
> > > > ([...]/lib/libgomp/*.so)?
> > > > (There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH,
> > > > and
> > > > LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
> > > > easier, and it generally seems to make sense to me that the compiler
> > > > (libgomp) should be able to locate its own resources, and I don't think
> > > > the plugin search path is something that a user generally would want to
> > > > override -- or is your use case indeed that the plugin is not built as
> > > > part of libgomp's build process? (But, in this case you still could use
> > > > LD_LIBRARY_PATH to have it found.)
> > >
> > > We invented this environment variable almost a year ago, when we
> > > didn’t fully understand how all the parts will work together. So for
> > > now, likely, your proposal is better.
> > > Jakub, what do you think?
> >
> > Yeah, certainly. Though, ideally the path it looks at should be relative
> > to the directory where libgomp is installed
>
> Right...
>
> > and I'm afraid it is hard to
> > figure out portably where it was loaded from, and DT_RPATH/DT_RUNPATH on
> > libgomp would affect all dlopen calls, not just the loading of the plugins.
> > Not sure if one can use at least on Linux ${ORIGIN} in dlopen and what
> > exactly will it expand to.
>
> I haven't verified, but I'd guess it to expand to the *executable*
> linking against libgomp, so that won't help...
>
> I have, however, found some logic in gcc/plugin.c that seems at least
> similar to what we need:
>
> gcc/doc/plugins.texi:
>
> @node Plugins loading
> @section Loading Plugins
>
> Plugins are supported on platforms that support @option{-ldl
> -rdynamic}. They are loaded by the compiler using @code{dlopen}
> and invoked at pre-determined locations in the compilation
> process.
>
> Plugins are loaded with
>
> @option{-fplugin=/path/to/@var{name}.so} [...]
>
> [...]
>
> A plugin can be simply given by its short name (no dots or
> slashes). When simply passing @option{-fplugin=@var{name}}, the plugin is
> loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}}
> is
> the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
> using backquote shell syntax to query the @file{plugin} directory.
>
> gcc/plugin.c:
>
> /* Retrieve the default plugin directory. The gcc driver should have
> passed
>it as -iplugindir to the cc1 program, and it is queriable
> through the
>-print-file-name=plugin option to gcc. */
> const char*
> default_plugin_dir_name (void)
> {
> if (!plugindir_string)
> fatal_error ("-iplugindir option not passed from the gcc
> driver");
> return plugindir_string;
> }
>
> But I'm not yet sure how we could use this to tie the libgomp plugin
> search path to the location of libgomp.so... Especially, given that the
> location of libgomp.so during compilation need not match the location
> during execution. A show-stopper? (No time currently to explore this in
> more detail.)
Heh, would a "hack" like the following work?
libcilkrts/runtime/sysdep-unix.c:
/* (Non-static) dummy function is used by get_runtime_path() to find the
path
* to the .so containing the Cilk runtime.
*/
void dummy_function() { }
/* return a string with the path to the Cilk runtime, or "unknown" if the
path
* cannot be determined.
*/
static const char *get_runtime_path ()
{
#ifdef __CYGWIN__
// Cygwin doesn't support dladdr, which sucks
return "unknown";
#else
Dl_info info;
if (0 == dladdr(dummy_function, &info)) return "unknown";
return info.dli_fname;
#endif
}
Putting that into libgomp, it should give the path to the libgomp.so
actually loaded, and then we can load the plugins relative from its
dirname?
Grüße,
Thomas
pgpwIHYA7sCxi.pgp
Description: PGP signature
Re: [RFC] Offloading Support in libgomp
On Thu, Jul 17, 2014 at 03:09:32PM +0200, Thomas Schwinge wrote:
> > But I'm not yet sure how we could use this to tie the libgomp plugin
> > search path to the location of libgomp.so... Especially, given that the
> > location of libgomp.so during compilation need not match the location
> > during execution. A show-stopper? (No time currently to explore this in
> > more detail.)
>
> Heh, would a "hack" like the following work?
>
> libcilkrts/runtime/sysdep-unix.c:
>
> /* (Non-static) dummy function is used by get_runtime_path() to find the
> path
> * to the .so containing the Cilk runtime.
> */
> void dummy_function() { }
>
> /* return a string with the path to the Cilk runtime, or "unknown" if the
> path
> * cannot be determined.
> */
> static const char *get_runtime_path ()
> {
> #ifdef __CYGWIN__
> // Cygwin doesn't support dladdr, which sucks
> return "unknown";
> #else
> Dl_info info;
> if (0 == dladdr(dummy_function, &info)) return "unknown";
> return info.dli_fname;
> #endif
> }
>
> Putting that into libgomp, it should give the path to the libgomp.so
> actually loaded, and then we can load the plugins relative from its
> dirname?
Well, libgomp has to be far more portable than this, so the question is
if we want to live with one behavior on Linux and another one elsewhere
(fallback to absolute path)? In any case, as last resort it should just try
to dlopen the plugin without full path, and the plugins really should have
libgomp-plugin or something similar in their names to make it less likely
to clash with something else.
If we would be ok with that, then a function to return that would need
to go into config/linux/ and config/posix/.
Jakub
Re: [GSoC] generation of Gimple loops with empty bodies
On 16/07/2014 11:40, Richard Biener wrote: On Tue, Jul 15, 2014 at 5:45 PM, Tobias Grosser wrote: This is not a patch review, lets move this to gcc@gcc.gnu.org. On 15/07/2014 17:03, Roman Gareev wrote: I've found out that int128_integer_type_node and long_long_integer_type_node are NULL at the moment of definition of the graphite_expression_size_type. Maybe we should use long_long_integer_type_node, because, as you said before, using of signed 64 has also been proved to be very robust. What do you think about this? I do not fully understand this message. You first say that long_long_integer_type_node is NULL, but then want to use this. This does not seem to be a solution. Most likely it is the solution, but the problem description makes it hard to understand it. Is the problem caused by initialization order issues? Or why are such types NULL? Because they are not available on all targets or for all languages. I suggest you use the largest available integer mode via mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0); type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]); Roman, can you give this a shot? Cheers, Tobias
Re: [RFC] Offloading Support in libgomp
Hi!
On Thu, 17 Jul 2014 15:35:36 +0200, Jakub Jelinek wrote:
> On Thu, Jul 17, 2014 at 03:09:32PM +0200, Thomas Schwinge wrote:
> > > But I'm not yet sure how we could use this to tie the libgomp plugin
> > > search path to the location of libgomp.so... Especially, given that the
> > > location of libgomp.so during compilation need not match the location
> > > during execution. A show-stopper? (No time currently to explore this in
> > > more detail.)
> >
> > Heh, would a "hack" like the following work?
> >
> > libcilkrts/runtime/sysdep-unix.c:
> >
> > /* (Non-static) dummy function is used by get_runtime_path() to find
> > the path
> > * to the .so containing the Cilk runtime.
> > */
> > void dummy_function() { }
> >
> > /* return a string with the path to the Cilk runtime, or "unknown" if
> > the path
> > * cannot be determined.
> > */
> > static const char *get_runtime_path ()
> > {
> > #ifdef __CYGWIN__
> > // Cygwin doesn't support dladdr, which sucks
> > return "unknown";
> > #else
> > Dl_info info;
> > if (0 == dladdr(dummy_function, &info)) return "unknown";
> > return info.dli_fname;
> > #endif
> > }
> >
> > Putting that into libgomp, it should give the path to the libgomp.so
> > actually loaded, and then we can load the plugins relative from its
> > dirname?
>
> Well, libgomp has to be far more portable than this, so the question is
> if we want to live with one behavior on Linux and another one elsewhere
> (fallback to absolute path)?
Hmm, that doesn't really seem appealing.
> In any case, as last resort it should just try
> to dlopen the plugin without full path, and the plugins really should have
> libgomp-plugin or something similar in their names to make it less likely
> to clash with something else.
The problem is that we don't know the plugins' names. Currently, we're
scanning a directory for all filenames matching libgomp-plugin-*.so.1.
> If we would be ok with that, then a function to return that would need
> to go into config/linux/ and config/posix/.
(config/gnu/ instead of config/linux/, as that's more a GNU/glibc thing
than a Linux kernel thing.)
Hmm, take one step back. Putting the plusing next to libgomp.so will
make their discovery easy, as that'll be governed by the very same
searching rules that led the dynamic linker to libgomp.so. All plugins
are named libgomp-plugin-*.so.1. But we'd have to know the plugins'
names (for use with dlopen), losing the ability to dynamically extend the
set of libgomp plugins. This in turn could be achieved by setting an
environment variable that specifies an additional -- or replacement? --
directory to scan, or even just specifies a list of additional plugin
*names* to load, again relying on the standard searching rules for them
to be found. Is that a reasonable price to pay?
Grüße,
Thomas
pgpSyIMIqLOge.pgp
Description: PGP signature
What would it take to always force indirect inlining?
I've recently discovered that a function marked always_inline but called
by pointer won't always be inlined. What would it take to assure that
this either always happens or generates an error? Unfortunately, it's
breaking (well, failing to properly optimize) some code where I need the
optimizer to see what's in the inline function (which is a constant at
compile time) so it can optimize it into a REP MOVSx loop on x86 or
similar on other archs. I kinda designed the function so that it would
work that way, but it ends up making a function call and then can't
optimize any further.
static __always_inline void my_copy(const struct qsort_def *def, void
*dest, const void *src) {
const struct size_type __aligned(ALIGN_SIZE) *s = src;
struct size_type __aligned(ALIGN_SIZE) *d = dest;
//fprintf(stderr, "copy: d=%p, s=%p\n", d, s);
*d = *s;
0020 mov(%rdx),%rax
0023 mov%rax,(%rsi)
0026 retq
...
static __always_inline __flatten void
_quicksort_ror(const struct qsort_def *def, void *left, void *right,
void *tmp, size_t tmp_size) {
const size_t size = def->size;
char *r = right;
char *l = left;
const ssize_t dist = (r - l) / (ssize_t)def->size; /* left to
right offset */
03c1 sub %rbx,%rdx
03c4 test %rdx,%rdx
03c7 lea 0x7(%rdx),%r12
03cb cmovns %rdx,%r12
if (size <= tmp_size) {
ssize_t i;
char *left_minus_one = l - size;
def->copy(def, tmp, r);
03cf mov %r13,%rdx
static __always_inline __flatten void
_quicksort_ror(const struct qsort_def *def, void *left, void *right,
void *tmp, size_t tmp_size) {
const size_t size = def->size;
char *r = right;
char *l = left;
const ssize_t dist = (r - l) / (ssize_t)def->size; /* left to
right offset */
03d2 sar $0x3,%r12
if (size <= tmp_size) {
ssize_t i;
char *left_minus_one = l - size;
def->copy(def, tmp, r);
03d6 callq 0020
/* rep movs-friendly loop */
for (i = dist; i; --i) {
03db test %r12,%r12
03de je 041d
03e0 lea 0x0(,%r12,8),%rdx
03e8 lea (%rbx,%rdx,1),%r14
03ec add %rdx,%r15
03ef xchg %ax,%ax
03f1 data32 data32 data32 data32
data32 nopw %cs:0x0(%rax,%rax,1)
def->copy(def, &l[i * size], &left_minus_one[i
* size]);
0400 mov %r15,%rdx
0403 mov %r14,%rsi
0406 mov $0x0,%edi
407: R_X86_64_32.rodata+0x20
040b callq 0020
0410 sub $0x8,%r14
0414 sub $0x8,%r15
ssize_t i;
char *left_minus_one = l - size;
def->copy(def, tmp, r);
/* rep movs-friendly loop */
for (i = dist; i; --i) {
0418 dec%r12
041b jne 0400
def->copy(def, &l[i * size], &left_minus_one[i
* size]);
}
def->copy(def, left, tmp);
041d mov -0x450(%rbp),%rdx
0424 mov %rbx,%rsi
0427 mov $0x0,%edi
428: R_X86_64_32.rodata+0x20
042c callq 0020
0431 jmpq 0378
If the optimizer had the body of my_copy above, it should be able to use
two pointers (one for l and another for left_minus_one) and a single
index as long as size is either 1, 2, 4 or 8. All and all, I need to
refine my strategy, but if I can solve this little part, it will help
greatly.
Thanks,
Daniel
m32c-*-* Build Issue (Multilib?)
Hi m32c-rtems4.11 doesn't build in 4.9.x. I looked at m32c-rtems4.11 and m32c-elf on the head and both fail in the same way. I can't see any recent changes to the m32c which would have caused this so I am reaching out. binutils is the head and newlib is close to their head. Both builds fail with: make[4]: Entering directory `/users/joel/test-gcc/b-m32c-elfgcc/m32c-elf/m32cm/libgcc' make[4]: *** No rule to make target `all'. Stop. At the point of the failure, the m32c-elf directory has these: $ find m32c-elf/ -type d m32c-elf/ m32c-elf/libgcc m32c-elf/libgcc/confhUyTPp m32c-elf/m32cm m32c-elf/m32cm/libgcc I think that looks odd. Normally the top directory is named for libraries not multilib variants. Any ideas? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: m32c-*-* Build Issue (Multilib?)
I just tried a 4.9.1 build and got this error:
configure:4222: checking whether to use setjmp/longjmp exceptions
configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
-B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
-B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/
-isystem /greed/dj/m32c/install/m32c-elf/include -isystem
/greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
-fexceptions conftest.c >&5
conftest.c: In function 'foo':
conftest.c:19:1: error: insn does not satisfy its constraints:
}
^
(insn 52 38 23 (set (reg:SI 2 r1 [29])
(reg:SI 4 a0)) 99 {movsi_24}
(nil))
conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
0x6258ef final(rtx_def*, _IO_FILE*, int)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
0x626035 rest_of_handle_final
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
0x626035 execute
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
Re: m32c-*-* Build Issue (Multilib?)
On 7/17/2014 3:08 PM, DJ Delorie wrote:
> I just tried a 4.9.1 build and got this error:
Same error in m32c-elf/m32cm/libgcc/config.log for a build of the
head. I apparently just saw the symptoms and missed this.
I have a gcc 4.8.2 RTEMS toolset installed so that provides some
window.
What's the next step?
> configure:4222: checking whether to use setjmp/longjmp exceptions
> configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
> -B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
> -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/
> -isystem /greed/dj/m32c/install/m32c-elf/include -isystem
> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
> -fexceptions conftest.c >&5
> conftest.c: In function 'foo':
> conftest.c:19:1: error: insn does not satisfy its constraints:
> }
> ^
> (insn 52 38 23 (set (reg:SI 2 r1 [29])
> (reg:SI 4 a0)) 99 {movsi_24}
> (nil))
>
> conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
> 0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
> 0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
> 0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
> 0x6258ef final(rtx_def*, _IO_FILE*, int)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
> 0x626035 rest_of_handle_final
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
> 0x626035 execute
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: m32c-*-* Build Issue (Multilib?)
I also missed something Chris was reporting.
We see other failures in the log because newlib/targ-include
isn't created. The rtems build include path includes that and
needs it but it isn't created before libgcc is built. That isn't a
problem on other targets. I don't see anything odd in the top
configurery magic for m32c which could cause this but I could
easily be missing something.
On 7/17/2014 3:17 PM, Joel Sherrill wrote:
> On 7/17/2014 3:08 PM, DJ Delorie wrote:
>> I just tried a 4.9.1 build and got this error:
> Same error in m32c-elf/m32cm/libgcc/config.log for a build of the
> head. I apparently just saw the symptoms and missed this.
>
> I have a gcc 4.8.2 RTEMS toolset installed so that provides some
> window.
>
> What's the next step?
>> configure:4222: checking whether to use setjmp/longjmp exceptions
>> configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
>> -B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
>> -B/greed/dj/m32c/install/m32c-elf/bin/
>> -B/greed/dj/m32c/install/m32c-elf/lib/ -isystem
>> /greed/dj/m32c/install/m32c-elf/include -isystem
>> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
>> -fexceptions conftest.c >&5
>> conftest.c: In function 'foo':
>> conftest.c:19:1: error: insn does not satisfy its constraints:
>> }
>> ^
>> (insn 52 38 23 (set (reg:SI 2 r1 [29])
>> (reg:SI 4 a0)) 99 {movsi_24}
>> (nil))
>>
>> conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
>> 0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
>> const*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
>> 0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
>> 0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
>> 0x6258ef final(rtx_def*, _IO_FILE*, int)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
>> 0x626035 rest_of_handle_final
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
>> 0x626035 execute
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
gcc-4.8-20140717 is now available
Snapshot gcc-4.8-20140717 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140717/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 212766 You'll find: gcc-4.8-20140717.tar.bz2 Complete GCC MD5=eb187e328fefd011244bce8b3eebc3f6 SHA1=96bfdb60cfb9a3dfe21d46addb0518dd31300036 Diffs from 4.8-20140710 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
[wwwdocs] Patch for Re: PLEASE RE-ADD MIRRORS (small correction)
On Tue, 15 Jul 2014, Dan D. wrote: > Are you still interested in the mirrors? Yep. This is the patch I just committed to our web site. If there are further updates, best propose a patch against https://gcc.gnu.org/mirrors.html , that is the fastest way and ensure things show up as you want them to. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.222 diff -u -r1.222 mirrors.html --- mirrors.html6 Jul 2014 22:00:24 - 1.222 +++ mirrors.html17 Jul 2014 22:59:18 - @@ -14,6 +14,10 @@ (Phoenix, Arizona, USA) directly: +Australia: + http://mirrors-au.go-parts.com/gcc/";>http://mirrors-au.go-parts.com/gcc +| ftp://mirrors-au.go-parts.com/gcc";>ftp://mirrors-au.go-parts.com/gcc +| rsync://mirrors-au.go-parts.com/gcc, thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin.Sprinzl at tuwien.ac.at Bulgaria: http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks to igor at onlinedirect.bg Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica.com). @@ -36,11 +40,19 @@ Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp) Latvia, Riga: http://mirrors.webhostinggeeks.com/gcc/";>mirrors.webhostinggeeks.com/gcc/, thanks to Igor (whg.igp at gmail.com) The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan Cristiaan van Winkel (jc at ATComputing.nl) +Russia: + http://mirrors-ru.go-parts.com/gcc/";>http://mirrors-ru.go-parts.com/gcc +| ftp://mirrors-ru.go-parts.com/gcc";>ftp://mirrors-ru.go-parts.com/gcc +| rsync://mirrors-ru.go-parts.com/gcc Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (admin at 2600.sk) UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/, thanks to mirror at mirrorservice.org UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet.bs) US, Saint Louis: http://gcc.petsads.us";>http://gcc.petsads.us, thanks to Sergey Kutserey (s.kutserey at gmail.com) US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin at netgull.com +US: + http://mirrors-usa.go-parts.com/gcc/";>http://mirrors-usa.go-parts.com/gcc +| ftp://mirrors-usa.go-parts.com/gcc";>ftp://mirrors-usa.go-parts.com/gcc +| rsync://mirrors-usa.go-parts.com/gcc The archives there will be signed by one of the following GnuPG keys:
Re: Mirror Setup
Hi Timo, On Wed, 13 Nov 2013, Timo Jacob wrote: > Hi, I have set up new mirrors for GCC for the following locations: : > + Mirrors-usa: > http://mirrors-usa.go-parts.com/crux/ > ftp://mirrors-usa.go-parts.com/crux/ > rsync://mirrors-usa.go-parts.com/mirrors/crux/ these did not look like GCC mirrors to me. ;-) I have now applied a patch that I created and https://gcc.gnu.org/mirrors.html now has links to current mirrors one of your colleagues provided. As I wrote in June 2013, "then send us a patch for http://gcc.gnu.org/mirrors.html and I'll take care of that (feel free to copy me)" is the best way to get that page of ours updated. Thanks, Gerald
Re: m32c-*-* Build Issue (Multilib?)
> We see other failures in the log because newlib/targ-include > isn't created. The rtems build include path includes that and > needs it but it isn't created before libgcc is built. That isn't a > problem on other targets. I don't see anything odd in the top > configurery magic for m32c which could cause this but I could > easily be missing something. If you're building in separate trees, you need to build gcc-host, then newlib, then gcc-target. If you're building in a combined tree, I don't know.
Re: m32c-*-* Build Issue (Multilib?)
> What's the next step? Someone finds time and desire to debug it ;-)
Re: obsolete targets
On 07/09/14 20:23, Trevor Saunders wrote: Hi, I've noticed that the following targets are built in config-list.mk with --enable-obsolete i686-interix3 - doesn't appear to actually require --enable-obsolete though, should it be marked as obsolete in config.gcc? score-* and picochip-* since atleast sept 2012, is there a reason they haven't been removed yet? I think the interix bits were resurrected back in 2012 and thus shouldn't be considered obsolete anymore. Jeff
