GCC support of openACC
Hi, I would like to know if the next release of GCC will support the openACC directives. At the moment only commercial compilers support the openACC standard. Thank you Salvatore
Re: GCC support of openACC
On Tue, Dec 4, 2012 at 3:37 PM, wrote: > Hi, > > I would like to know if the next release of GCC will support the openACC > directives. At the moment only commercial compilers support the openACC > standard. No, it won't. Richard. > Thank you > Salvatore >
Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
Hello, Someone broke bootstrap on powerpc64-linux between r194084 and r194141. Anyone else seeing this? Ciao! Steven ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:338:8: error: 'void _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_()' aliased to undefined symbol '_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_' _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_); ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: in definition of macro '_GLIBCXX_LDBL_COMPAT' extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:336:8: error: 'void _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_()' aliased to undefined symbol '_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_' _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_); ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: in definition of macro '_GLIBCXX_LDBL_COMPAT' extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:334:8: error: 'void _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIlEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_()' aliased to undefined symbol '_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_' _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIlEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_); ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: in definition of macro '_GLIBCXX_LDBL_COMPAT' extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:332:8: error: 'void _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_()' aliased to undefined symbol '_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_' _ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_); ^ ../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: in definition of macro '_GLIBCXX_LDBL_COMPAT' extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) ^ make[6]: *** [locale-inst.lo] Error 1 make[6]: Leaving directory `/home/stevenb/devel/build-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++98' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/stevenb/devel/build-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/stevenb/devel/build-test/powerpc64-unknown-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/stevenb/devel/build-test/powerpc64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/home/stevenb/devel/build-test' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/stevenb/devel/build-test' make: *** [all] Error 2
Re: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-12-03 Benjamin Kosnik
* include/ext/pb_ds/detail/cc_hash_table_map_/standard_policies.hpp:
Remove.
* include/ext/pb_ds/detail/gp_hash_table_map_/standard_policies.hpp:
Remove.
* include/Makefile.am (pb_headers): Remove include files.
* include/Makefile.in: Regenerated.
Index: libstdc++-v3/include/Makefile.am
===
--- libstdc++-v3/include/Makefile.am(revision 194084)
+++ libstdc++-v3/include/Makefile.am(revision 194141)
@@ -313,8 +313,7 @@ pb_headers2 = \
${pb_srcdir}/detail/cc_hash_table_map_/resize_fn_imps.hpp \
${pb_srcdir}/detail/cc_hash_table_map_/resize_no_store_hash_fn_imps.hpp
\
${pb_srcdir}/detail/cc_hash_table_map_/resize_store_hash_fn_imps.hpp \
- ${pb_srcdir}/detail/cc_hash_table_map_/size_fn_imps.hpp \
- ${pb_srcdir}/detail/cc_hash_table_map_/standard_policies.hpp
+ ${pb_srcdir}/detail/cc_hash_table_map_/size_fn_imps.hpp
pb_headers3 = \
${pb_srcdir}/detail/cc_hash_table_map_/trace_fn_imps.hpp \
@@ -344,7 +343,6 @@ pb_headers3 = \
${pb_srcdir}/detail/gp_hash_table_map_/resize_fn_imps.hpp \
${pb_srcdir}/detail/gp_hash_table_map_/resize_no_store_hash_fn_imps.hpp
\
${pb_srcdir}/detail/gp_hash_table_map_/resize_store_hash_fn_imps.hpp \
- ${pb_srcdir}/detail/gp_hash_table_map_/standard_policies.hpp \
${pb_srcdir}/detail/gp_hash_table_map_/trace_fn_imps.hpp \
${pb_srcdir}/detail/hash_fn/direct_mask_range_hashing_imp.hpp \
${pb_srcdir}/detail/hash_fn/direct_mod_range_hashing_imp.hpp \
@@ -1107,7 +1105,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
visibility=`cat stamp-visibility` ;\
externtemplate=`cat stamp-extern-template` ;\
ldbl_compat='s,g,g,' ;\
- grep "^[]*#[]*define[ ][
]*_GLIBCXX_LONG_DOUBLE_COMPAT[ ][ ]*1[]*$$" \
+ grep "^[]*#[]*define[ ][
]*_GLIBCXX_LONG_DOUBLE_COMPAT[ ][ ]*1[]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& ldbl_compat='s,^#undef
_GLIBCXX_LONG_DOUBLE_COMPAT$$,#define _GLIBCXX_LONG_DOUBLE_COMPAT 1,'
;\
sed -e "s,define __GLIBCXX__,define __GLIBCXX__ $$date," \
@@ -1121,7 +1119,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
- -e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
+ -e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
< ${CONFIG_HEADER} >> $@ ;\
echo "" >> $@ ;\
echo "#endif // _GLIBCXX_CXX_CONFIG_H" >> $@
Re: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote: > On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote: >> Hello, >> >> Someone broke bootstrap on powerpc64-linux between r194084 and >> r194141. Anyone else seeing this? >> >> Ciao! >> Steven > > Looks like someone used a broken editor replacing tabs with spaces: > > 2012-12-03 Benjamin Kosnik > > * include/ext/pb_ds/detail/cc_hash_table_map_/standard_policies.hpp: > Remove. > * include/ext/pb_ds/detail/gp_hash_table_map_/standard_policies.hpp: > Remove. > * include/Makefile.am (pb_headers): Remove include files. > * include/Makefile.in: Regenerated. Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152 Please, kindly, test your patches before committing. Ciao! Steven
Re: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
Steven Bosscher writes: > Looks like someone used a broken editor replacing tabs with spaces: Rather the other way round. 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: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
Steven Bosscher writes: > Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152 I think if you had changed to it would have a better chance to survive broken editors. 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: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote: > Steven Bosscher writes: > >> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152 > > I think if you had changed to it would have a > better chance to survive broken editors. I only put back what was there before. To be honest, I have no idea what the regexp is supposed to do anyway. Ciao! Steven
OpenMP pragma expansion problem
Hello everybody,
I am modifying GCC for inserting a new OpenMP pragma. This pragma has a
clause that accepts a MYVAR (integer), and modifies its value. It behaves
more or less as a PARALLEL pragma, except that the return value of the
inserted function call is assigned to MYVAR. However, I never manage this to
happen. I investigated a bit and found that:
1) If the MYVAR is declared inside the scope of pragma, it works
2) If the MYVAR is declare outside, then the value it's never assigned. or
better, it's overwritten right after the annotated code, hence before the
following usage. Please see pseudo-code below, where I decleare MYVAR
outside the parallel region, and then annotate it as PRIVATE.
int main ()
{
int myvar;
#pragma omp parallel private(myvar)
{
#pragma omp mypragma myclause(myvar)
{
// this code here does NOT use myvar
}
printf ("%d", myvar);
}
}
Is transformed by the compiler into (the following pseudo-code reflects what
I see in the dump of the expansion pass)
int main ()
{
int myvar;
GOMP_parallel_start(...)
main.omp.fn.0 (...)
GOMP_parallel_end(...)
}
// the "normal" parallel function
void main.omp.fn.0(..)
{
int myvar;
int myvar; // ...nope, this is *not* a typo!!
myvar = main.omp.fn.1 (...);
// this prints a wrong (always '0') value
printf ("%d", myvar);
}
// my OpenMP extension
void main.omp.fn.1(..)
{
// this code here does NOT use myvar
return SOMETHING;
}
All of the generation of main.omp.fn.1 (...) and insertion of the calls is
done by my modifications, the rest is a "normal" OpenMP expansion pass. My
problem is that the following printf always prints '0' value, which is not
the one I returned from the main.omp.fn.1(..) function.
I investigated a bit, and found that MYVAR is replicated during the
expansion pass of the outer parreg (The "real" one). Thus, the variable
MYVAR that I write is *different* than the MYVAR I pass to the prinrf: the
latter is uninitialized. GCC replaces it inside move_stmt_op function, in
tree-cfg.c file, at
...
/* Replace T with its duplicate. T should no longer appear in the
parent function, so this looks wasteful; however, it may appear
in referenced_vars, and more importantly, as virtual operands of
statements, and in alias lists of other variables. It would be
quite difficult to expunge it from all those places. ??? It might
suffice to do this for addressable variables. */
if ((TREE_CODE (t) == VAR_DECL
&& !is_global_var (t))
|| TREE_CODE (t) == CONST_DECL)
replace_by_duplicate_decl (tp, p->vars_map, p->to_context);
...
I tried to "mark" MYVAR as "NON REPLICABLE" as soon as I scan it (and
modified the IF stmt up here), but then I have a segfault somewhere else in
the compiler (probably because the tree of that function is not consistent
anymore).
Anyone can help? maybe I have to set another property of the VAR_DECL for
MYVAR during the scan/lowering pass..?
Thanks, cheers
Paolo
--
View this message in context:
http://old.nabble.com/OpenMP-pragma-expansion-problem-tp34758091p34758091.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
PING [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On Thu, May 17, 2012 at 12:50 PM, H.J. Lu wrote: > On Tue, May 15, 2012 at 9:07 AM, Michael Matz wrote: >> Hi, >> >> On Mon, 14 May 2012, H.J. Lu wrote: >> >>> > As a minor nitpick, I have always used x32 with a lower case x. The >>> > capital X32 looks odd to me. >>> > >>> >>> I used X32 together with LP64. I can use ILP32 instead of X32 when LP64 >>> is mentioned at the same time. >> >> I'd prefer that. x32 is a nice short-hand name for the whole thing, but >> not descriptive, unlike LP64. So, yes, IMO it should be ILP32 in the ABI >> document. >> > > Here is the updated change. Any comments? > > Thanks. > PING. -- H.J.
Re: DRIVER_SELF_SPECS and multilib
gnubie gnubie writes:
> Hi,
>
> I notice that if you add a DRIVER_SELF_SPEC option and then add that
> option as a MULTILIB_OPTION, it doesn't build certain libraries for
> that multilib variant.
>
> for example, if you add:
>
> "%{mtestoption:-mcpu=cortex-a5 %
> (and then define mtestoption in the opt file)
>
> then add mtestoption as a multilib variant, it builds some of the
> libraries for that variant but not others. notable missing libraries
> being:
>
> libstdc++, libssp and libsupc++.
>
> most of the others are there. If you just add cortex-a5 as the
> variant then it works fine.
>
> Is this by design?
Kind-of. It's certainly by design that DRIVER_SELF_SPECS are applied
before multilib selection, because one of DRIVER_SELF_SPEC's main uses
is to infer an explicit multilib option from other non-multilib options.
The %
Re: DRIVER_SELF_SPECS and multilib
Richard Sandiford writes:
> On the face of it, plain:
>
> "%{mtestoption:-mcpu=cortex-a5 %
> ought to be OK. mtestoption will get passed down the cc1 etc., but
> adding it to the .opt file should mean that it is accepted and ignored.
Er, I meant "%{mtestoption:-mcpu=cortex-a5}".
Richard
Re: Bootstrap broken on powerpc64-unknown-linux-gnu "aliased to undefined symbol" (in definition of macro '_GLIBCXX_LDBL_COMPAT')
Like this. Tested on powerpc-linux and installed as obvious.
Andreas.
* include/Makefile.am (${host_builddir}/c++config.h): Replace
[] by [].
* include/Makefile.in: Regenerate.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 44200ee..7bdd1b8 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1103,7 +1103,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
visibility=`cat stamp-visibility` ;\
externtemplate=`cat stamp-extern-template` ;\
ldbl_compat='s,g,g,' ;\
- grep "^[]*#[]*define[ ][
]*_GLIBCXX_LONG_DOUBLE_COMPAT[ ][ ]*1[]*$$" \
+ grep "^[ ]*#[]*define[ ][
]*_GLIBCXX_LONG_DOUBLE_COMPAT[ ][ ]*1[]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& ldbl_compat='s,^#undef _GLIBCXX_LONG_DOUBLE_COMPAT$$,#define
_GLIBCXX_LONG_DOUBLE_COMPAT 1,' ;\
sed -e "s,define __GLIBCXX__,define __GLIBCXX__ $$date," \
@@ -1117,7 +1117,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
- -e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
+ -e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
< ${CONFIG_HEADER} >> $@ ;\
echo "" >> $@ ;\
echo "#endif // _GLIBCXX_CXX_CONFIG_H" >> $@
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
