Re: [RFC, x86] Changes for AVX and AVX2 processors
On Sat, Dec 29, 2012 at 6:26 AM, Vladimir Yakovlev wrote: > processor_alias_table contains the same processor type for all > "corei7", "corei7-avx", "core-avx-i" and "core-avx2". At least, it has > consequence on checking x86_avx256_split_unaligned_load & > ix86_tune_mask: for all these processors it results the same. Moreover > we cannot turn new features on for AVX/AVX2 using > initial_ix86_tune_features. corei7, corei7-avx and core-avx-i are all based on sandybridge (= PROCESSOR_COREI7) architecture. The only problematic entry is core-avx2, which should be based on new architecture. I propose PROCESSOR_HASWELL, in the same way as we have PROCESSOR_NOCONA. Uros.
config.{guess,sub} upgrade
Hi all.
I have just upgraded the trunk copies of config.{guess,sub} to today's
master revisions. These files are now licensed under GPLv3.
Cheers,
Ben
signature.asc
Description: Digital signature
Clean-up: Remove remaining pieces of kaos configuration
Hi, the kaOS research project ended a while ago. There is no need to keep the kaOS configuration fragments in gcc. The architecture specific pieces got removed back in 2008 already. Best regards, Uwe Stieber remove-kaos.patch Description: Binary data ChangeLog Description: Binary data
Re: Clean-up: Remove remaining pieces of kaos configuration
On Sat, Dec 29, 2012 at 3:16 AM, wrote: > Hi, > > the kaOS research project ended a while ago. There is no need to keep the > kaOS configuration fragments in gcc. The architecture specific pieces got > removed back in 2008 already. The only part of the patch which makes sense for GCC itself is configure.ac. The rest (config.sub) should be sent upstream. Note libjava/classpath has an upstream also but the config.sub there is really just copied from the same source as the toplevel's config.sub. Thanks, Andrew
Re: Clean-up: Remove remaining pieces of kaos configuration
u...@kaos-group.de writes: > Index: config.sub Patches for config.sub must be submitted to . Andreas. -- 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."
[RFC, x86] Changes for AVX and AVX2 processors
I did changes. Please take a look. 2012/12/29, Uros Bizjak : > On Sat, Dec 29, 2012 at 6:26 AM, Vladimir Yakovlev > wrote: > >> processor_alias_table contains the same processor type for all >> "corei7", "corei7-avx", "core-avx-i" and "core-avx2". At least, it has >> consequence on checking x86_avx256_split_unaligned_load & >> ix86_tune_mask: for all these processors it results the same. Moreover >> we cannot turn new features on for AVX/AVX2 using >> initial_ix86_tune_features. > > corei7, corei7-avx and core-avx-i are all based on sandybridge (= > PROCESSOR_COREI7) architecture. The only problematic entry is > core-avx2, which should be based on new architecture. I propose > PROCESSOR_HASWELL, in the same way as we have PROCESSOR_NOCONA. > > Uros. > diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c index 08e1afe..2d8abd5 100644 --- a/gcc/config/i386/i386-c.c +++ b/gcc/config/i386/i386-c.c @@ -142,11 +142,7 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag, def_or_undef (parse_in, "__corei7"); def_or_undef (parse_in, "__corei7__"); break; -case PROCESSOR_CORE_AVX: - def_or_undef (parse_in, "__core_avx"); - def_or_undef (parse_in, "__core_avx__"); - break; -case PROCESSOR_CORE_AVX2: +case PROCESSOR_HASWELL: def_or_undef (parse_in, "__core_avx2"); def_or_undef (parse_in, "__core_avx2__"); break; @@ -240,10 +236,7 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag, case PROCESSOR_COREI7: def_or_undef (parse_in, "__tune_corei7__"); break; -case PROCESSOR_CORE_AVX: - def_or_undef (parse_in, "__tune_core_avx__"); - break; -case PROCESSOR_CORE_AVX2: +case PROCESSOR_HASWELL: def_or_undef (parse_in, "__tune_core_avx2__"); break; case PROCESSOR_ATOM: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 10411da..4adbef6 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -1732,9 +1732,8 @@ const struct processor_costs *ix86_cost = &pentium_cost; #define m_P4_NOCONA (m_PENT4 | m_NOCONA) #define m_CORE2 (1<
Re: [wwwdocs] Clean up some references to cvs.html
On Fri, 28 Dec 2012, Gerald Pfeifer wrote: > Planning to simplify/improve things partly based on that thread, > I noticed that we actually have too many references to that page, > so before I proceed with the other changes, this one cleans things > up a bit (and reduces the number of direct references we have to > CVS or Subversion). And here is one for java/. Applied as well. Gerald 2012-12-29 Gerald Pfeifer * gcj2.html: Remove link to our old CVS page. Index: gcj2.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/gcj2.html,v retrieving revision 1.9 diff -u -3 -p -r1.9 gcj2.html --- gcj2.html 25 Mar 2002 20:50:21 - 1.9 +++ gcj2.html 29 Dec 2012 17:28:05 - @@ -72,9 +72,9 @@ href="http://gcc.gnu.org/";>GCC proje How to get it The new Java front end is very easy to download and install. Since -it is it fully integrated into GCC, you can simply follow the http://gcc.gnu.org/cvs.html";>GCC download and build -instructions. Note that you'll want to configure GCC to use the +it is it fully integrated into GCC, you can simply follow the +GCC download and build instructions. +Note that you'll want to configure GCC to use the appropriate threads system; see the libgcj page for details.
[wwwdocs,Java] Refer to Jessie without using a link.
I noticed that the current link to Jessie did not work any more, and could not find a good replacement (both http://jessie.nongnu.org/ and https://savannah.nongnu.org/projects/jessie/ seem quite outdated), so I applied the following. Gerald 2012-12-29 Gerald Pfeifer * news.html: Refer to Jessie without using a link. Index: news.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/news.html,v retrieving revision 1.14 diff -u -3 -p -r1.14 news.html --- news.html 1 Nov 2012 22:26:20 - 1.14 +++ news.html 29 Dec 2012 17:32:13 - @@ -95,8 +95,7 @@ packages from the latest developer snapshot release. These packages will be an official part of then next major release. Extra crypto algorithms can be obtained from the http://www.gnu.org/software/gnu-crypto/";>GNU Crypto -project, a full TLS implementation is provided by the -http://www.nongnu.org/jessie/";>Jessie project. +project, a full TLS implementation is provided by the Jessie project. July 16, 2004
[wwwdocs] Add a README for htdocs/install
In http://gcc.gnu.org/PR54711 Steve wrote the following: OK, I can check out wwwdocs but the page I am interested in doesn't seem to be there. On the web it is http://gcc.gnu.org/install/test.html, but I can't seem to find this page in a checked out version of wwwdocs. I did get an htdocs/install directory but it does not include any files (other than CVS and .cvsignore). Looking at our web tree, I can totally see how this can be confusing, and I hope the patch below that adds a new htdocs/install/README file helps avoid this going forward. Applied. Steve, if you have a suggestion for some different or additional wording, based on your experience, please advise. Gerald Index: README === RCS file: README diff -N README --- /dev/null 1 Jan 1970 00:00:00 - +++ README 29 Dec 2012 00:43:46 - @@ -0,0 +1,3 @@ +The contents of this directory is not actually maintained here, but +created from gcc/doc/install.texi and regularily synced from the GCC +source tree to gcc.gnu.org.
Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses, take 2
This is a small follow-up change that I had meant to commit for a while (ahem); done now. Thanks for taking the time to write this up! Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.133 diff -u -3 -p -r1.133 changes.html --- changes.html3 Dec 2012 18:39:27 - 1.133 +++ changes.html29 Dec 2012 17:34:01 - @@ -53,15 +53,15 @@ On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or ARMv7-M, the new option -munaligned-access is active by default, which for -some source codes generates code that accesses memory on unaligned -addresses. This will require the kernel of those systems to enable +some sources generates code that accesses memory on unaligned +addresses. This requires the kernel of those systems to enable such accesses (controlled by CP15 register c1, refer -to ARM documentation). Alternatively or for compatibility with +to ARM documentation). Alternatively, or for compatibility with kernels where unaligned accesses are not supported, all code has to be compiled with -mno-unaligned-access. -Linux/ARM in official releases has automatically and +Upstream Linux kernel releases have automatically and unconditionally supported unaligned accesses as emitted by GCC due -to this option being active, since Linux version 2.6.28. +to this option being active since version 2.6.28. Support on ARM for the legacy floating-point accelerator (FPA) and the mixed-endian floating-point format that it used has been obsoleted.
Re: [Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C)
On Fri, Dec 28, 2012 at 12:31 AM, Tobias Burnus wrote: > Dear all, > > See also the discussion in the thread starting at > http://gcc.gnu.org/ml/fortran/2012-12/msg00135.html > > a) The Fortran standard only defines LOGICAL(kind=C_Bool) as being > interoperable with C - no other LOGICAL type. That matches GCC: With gcc > (the C compiler) only _Bool is a BOOLEAN_TYPE with TYPE_PRECISION == 1. > Hence, this patch rejects other logical kinds as dummy argument/result > variable in BIND(C) procedures if -std=f2003/f2008/f2008ts is specified > (using -pedantic, one gets a warning). Sorry, I don't understand, what is the -pedantic warning about if it's already rejected? Or do you mean std=gnu -pedantic? > b) As GNU extension, other logical kinds are accepted in BIND(C) procedures; > however, as the main use of "LOGICAL(kind=4)" (for BIND(C) procedures) is to > handle logical expressions which use C's int, one has to deal with all > integer values and not only 0 and 1. Hence, a normal integer type is used > internally in that case. That has been done to avoid surprises of users and > hard to trace bugs. Does this actually work robustly? E.g. if you have a logical but really integer under the covers, what happens if you equivalence it with a "normal" logical variable. Or pass it as an argument to a procedure expecting a normal logical etc. I suspect this might be opening a can of worms.. -- Janne Blomqvist
Re: fix libquadmath build regression
On Dec 24, 2012, Paolo Bonzini wrote:
> Il 21/12/2012 06:17, Alexandre Oliva ha scritto:
>> The problem is that glibc has an extern inline definition of
>> fraiseexcept that is introduced by including fenv.h (it's in
>> bits/fenv.h), and this definition requires SSE support regardless of
>> target arch of word width, so it doesn't work for an i686 native that
>> doesn't assume SSE registers and instructions are available.
>>
>> This bug is fixed in newer versions of glibc, but I figured it wouldn't
>> hurt to have a work-around in place for libquadmath to build
> Would it be possible to fix it in fixincludes instead?
Heh, who'd have thought of using fixincludes to fix broken include
files? :-) (hint: not me :-) *blush*
Thanks for the suggestion, this patch fixes the problem. Regstrapped on
x86_64-linux-gnu and i686-linux-gnu. Ok to install?
Fix mandatory SSE in 2.1[56]ish glibc's feraiseexcept
From: Alexandre Oliva
for fixincludes/ChangeLog
* inclhack.def (feraiseexcept_nosse_invalid): New.
(feraiseexcept_nosse_divbyzero): Likewise.
* fixincl.x: Rebuilt.
* tests/base/bits/fenv.h: New.
---
fixincludes/fixincl.x | 130 ++--
fixincludes/inclhack.def | 39 +++
fixincludes/tests/base/bits/fenv.h | 29
3 files changed, 190 insertions(+), 8 deletions(-)
create mode 100644 fixincludes/tests/base/bits/fenv.h
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index 4115772..29fc52a 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed October 28, 2012 at 02:53:25 PM by AutoGen 5.17.0pre5
+ * It has been AutoGen-ed Saturday December 29, 2012 at 09:17:09 AM BRST
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Sun Oct 28 14:53:25 PDT 2012
+/* DO NOT SVN-MERGE THIS FILE, EITHER Sat Dec 29 09:17:10 BRST 2012
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -15,7 +15,7 @@
* certain ANSI-incompatible system header files which are fixed to work
* correctly with ANSI C and placed in a directory that GNU C will search.
*
- * This file contains 224 fixup descriptions.
+ * This file contains 226 fixup descriptions.
*
* See README for more information.
*
@@ -9158,14 +9158,116 @@ static const char* apzX11_SprintfPatch[] = {
#endif /* !defined __STDC__ */",
(char*)NULL };
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
+ * Description of Feraiseexcept_Nosse_Invalid fix
+ */
+tSCC zFeraiseexcept_Nosse_InvalidName[] =
+ "feraiseexcept_nosse_invalid";
+
+/*
+ * File name selection pattern
+ */
+tSCC zFeraiseexcept_Nosse_InvalidList[] =
+ "bits/fenv.h\0";
+/*
+ * Machine/OS name selection pattern
+ */
+tSCC* apzFeraiseexcept_Nosse_InvalidMachs[] = {
+"i[34567]86-*-linux*",
+"x86*-linux*",
+"amd64-*-linux*",
+(const char*)NULL };
+
+/*
+ * content selection pattern - do fix if pattern found
+ */
+tSCC zFeraiseexcept_Nosse_InvalidSelect0[] =
+ "^([\t ]*)__asm__ __volatile__ \\(\"divss %0, %0 *\" : : \"x\" \\(__f\\)\\);$";
+
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zFeraiseexcept_Nosse_InvalidBypass0[] =
+ "\"fdiv .*; fwait\"";
+
+#defineFERAISEEXCEPT_NOSSE_INVALID_TEST_CT 2
+static tTestDesc aFeraiseexcept_Nosse_InvalidTests[] = {
+ { TT_NEGREP, zFeraiseexcept_Nosse_InvalidBypass0, (regex_t*)NULL },
+ { TT_EGREP,zFeraiseexcept_Nosse_InvalidSelect0, (regex_t*)NULL }, };
+
+/*
+ * Fix Command Arguments for Feraiseexcept_Nosse_Invalid
+ */
+static const char* apzFeraiseexcept_Nosse_InvalidPatch[] = {
+"format",
+"# ifdef __SSE_MATH__\n\
+%0\n\
+# else\n\
+%1__asm__ __volatile__ (\"fdiv st, st(0); fwait\"\n\
+%1\t\t\t: \"=t\" (__f) : \"0\" (__f));\n\
+# endif",
+(char*)NULL };
+
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
+ * Description of Feraiseexcept_Nosse_Divbyzero fix
+ */
+tSCC zFeraiseexcept_Nosse_DivbyzeroName[] =
+ "feraiseexcept_nosse_divbyzero";
+
+/*
+ * File name selection pattern
+ */
+tSCC zFeraiseexcept_Nosse_DivbyzeroList[] =
+ "bits/fenv.h\0";
+/*
+ * Machine/OS name selection pattern
+ */
+tSCC* apzFeraiseexcept_Nosse_DivbyzeroMachs[] = {
+"i[34567]86-*-linux*",
+"x86*-linux*",
+"amd64-*-linux*",
+(const char*)NULL };
+
+/*
+ * content selection pattern - do fix if pattern found
+ */
+tSCC zFeraiseexcept_Nosse_DivbyzeroSelect0[] =
+ "^([\t ]*)__asm__ __volatile__ \\(\"divss %1, %0 *\" : : \"x\" \\(__f\\), \"x\" \\(__g\\)\\);$";
+
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zFeraiseexcept_Nosse_DivbyzeroBypass0[] =
+ "\"fdivp .*; fwait\"";
+
+#defineFERAISEEXCEPT_NOSSE_DIVBYZERO_TEST_CT 2
+static tTestDesc aFeraiseexcept_Nosse_DivbyzeroTests[] = {
+ { TT_NEGREP, zFeraiseexcept_
Re: fix libquadmath build regression
On Dec 21, 2012, Tobias Burnus wrote: > Otherwise, it looks okay to me. Thanks, I'd fixed all the problems you caught in the review, but then Paolo's suggestion to use fixincludes came in and I sat on it for a while. I'm now leaning towards fixincludes, but I figured I'd post the latest version of the patch for libquadmath just in case the library maintainers wish to have an internal fix for this particular bug. What do you say, should I put it in? Deal with SSE-requiring extern inline in bits/fenv.h From: Alexandre Oliva for libquadmath/ChangeLog * configure.ac: Check that calling feraiseexcept compiles when fenv.h is included. Define QUADMATH_FERAISEEXCEPT cpp macro and LIBQUAD_FERAISEEXCEPT conditional otherwise. * Makefile.am (libquadmath_la_SOURCES): Add math/feraiseexcept.c, conditional on LIBQUAD_FERAISEEXCEPT. * aclocal.m4: Rebuilt. * configure: Rebuilt. * config.h.in: Rebuilt. * Makefile.in: Rebuilt. * math/feraiseexcept.c: New file. * math/quadmath-imp.h (__quadmath_feraiseexcept): Declare. * math/ccoshq.c: Use QUADMATH_FERAISEEXCEPT macro to call, and to decide whether to call, feraiseexcept. * math/cexpq.c: Likewise. * math/csinhq.c: Likewise. * math/csinq.c: Likewise. * math/ctanhq.c: Likewise. * math/ctanq.c: Likewise. * math/ilogbq.c: Likewise. Include fenv.h if HAVE_FENV_H. --- libquadmath/Makefile.am |3 + libquadmath/Makefile.in | 90 ++ libquadmath/config.h.in |3 + libquadmath/configure| 59 - libquadmath/configure.ac | 28 libquadmath/math/ccoshq.c|8 ++- libquadmath/math/cexpq.c | 12 +++-- libquadmath/math/csinhq.c| 12 +++-- libquadmath/math/csinq.c | 12 +++-- libquadmath/math/ctanhq.c|4 +- libquadmath/math/ctanq.c |4 +- libquadmath/math/feraiseexcept.c | 12 + libquadmath/math/ilogbq.c| 16 --- libquadmath/quadmath-imp.h |5 +- 14 files changed, 204 insertions(+), 64 deletions(-) create mode 100644 libquadmath/math/feraiseexcept.c diff --git a/libquadmath/Makefile.am b/libquadmath/Makefile.am index 6c97ee8..9acf619 100644 --- a/libquadmath/Makefile.am +++ b/libquadmath/Makefile.am @@ -69,6 +69,9 @@ libquadmath_la_SOURCES = \ printf/quadmath-printf.c printf/rshift.c printf/submul_1.c printf/sub_n.c \ strtod/strtoflt128.c strtod/mpn2flt128.c strtod/tens_in_limb.c +if LIBQUAD_FERAISEEXCEPT +libquadmath_la_SOURCES += math/feraiseexcept.c +endif # Work around what appears to be a GNU make bug handling MAKEFLAGS # values defined in terms of make variables, as is the case for CC and diff --git a/libquadmath/Makefile.in b/libquadmath/Makefile.in index 92c5d25..395e236 100644 --- a/libquadmath/Makefile.in +++ b/libquadmath/Makefile.in @@ -37,6 +37,7 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @BUILD_LIBQUADMATH_FALSE@libquadmath_la_DEPENDENCIES = +@BUILD_LIBQUADMATH_TRUE@@LIBQUAD_FERAISEEXCEPT_TRUE@am__append_1 = math/feraiseexcept.c subdir = . DIST_COMMON = ChangeLog $(srcdir)/Makefile.in $(srcdir)/Makefile.am \ $(top_srcdir)/configure $(am__configure_deps) \ @@ -87,6 +88,7 @@ am__installdirs = "$(DESTDIR)$(toolexeclibdir)" "$(DESTDIR)$(infodir)" \ "$(DESTDIR)$(libsubincludedir)" LTLIBRARIES = $(toolexeclib_LTLIBRARIES) am__dirstamp = $(am__leading_dot)dirstamp +@BUILD_LIBQUADMATH_TRUE@@LIBQUAD_FERAISEEXCEPT_TRUE@am__objects_1 = math/feraiseexcept.lo @BUILD_LIBQUADMATH_TRUE@am_libquadmath_la_OBJECTS = math/x2y2m1q.lo \ @BUILD_LIBQUADMATH_TRUE@ math/isinf_nsq.lo math/acoshq.lo \ @BUILD_LIBQUADMATH_TRUE@ math/fmodq.lo math/acosq.lo \ @@ -142,7 +144,8 @@ am__dirstamp = $(am__leading_dot)dirstamp @BUILD_LIBQUADMATH_TRUE@ printf/rshift.lo printf/submul_1.lo \ @BUILD_LIBQUADMATH_TRUE@ printf/sub_n.lo strtod/strtoflt128.lo \ @BUILD_LIBQUADMATH_TRUE@ strtod/mpn2flt128.lo \ -@BUILD_LIBQUADMATH_TRUE@ strtod/tens_in_limb.lo +@BUILD_LIBQUADMATH_TRUE@ strtod/tens_in_limb.lo \ +@BUILD_LIBQUADMATH_TRUE@ $(am__objects_1) libquadmath_la_OBJECTS = $(am_libquadmath_la_OBJECTS) libquadmath_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ @@ -325,33 +328,59 @@ AUTOMAKE_OPTIONS = 1.8 foreign @BUILD_LIBQUADMATH_TRUE@libquadmath_la_DEPENDENCIES = $(version_dep) $(libquadmath_la_LIBADD) @BUILD_LIBQUADMATH_TRUE@nodist_libsubinclude_HEADERS = quadmath.h quadmath_weak.h @BUILD_LIBQUADMATH_TRUE@libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include -@BUILD_LIBQUADMATH_TRUE@libquadmath_la_SOURCES = \ -@BUILD_LIBQUADMATH_TRUE@ math/x2y2m1q.c math/isinf_nsq.c math/acoshq.c math/fmodq.c \ -@BUILD_LIBQUADMATH_TRUE@ math/acosq.c math/frexpq.c \ -@BUILD_LIBQUADMATH_TRUE@ math/rem_pio2q.c math/asinhq.c math/hypotq.c math/remainderq.c \ -@BUILD_LIBQUADMATH_TRUE@ math/asinq.c math/rintq.c math/atan2q.c math/isinfq.
Re: [PR libmudflap/53359] don't register symbols not emitted
On Dec 21, 2012, Richard Biener wrote:
> On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote:
>> libmudflap emits a global initializer that registers memory ranges for
>> global data symbols. However, even if IPA decides not to emit a symbol
>> because it's unused, we'd still emit registration sequences for them in
>> some cases, which, in the PR testcase, would result in TOC references to
>> the undefined symbols.
> Hmm, I think that at this point of the compilation you are looking for
> TREE_ASM_WRITTEN instead.
That doesn't work, several mudflap regressions show up because accesses
to global library symbols that are accessed by template methods compiled
with mudflap (say cout) are then verified but not registered. We have
to register symbols that are not emitted but that referenced.
I've now updated the comment to reflect this.
Is this ok to install? Regstrapped again (along with the patches for
feraiseexcept, since there weren't any non-comment changes here) on
x86_64-linux-gnu and i686-linux-gnu.
don't let mudflap register global symbols that won't be emitted
From: Alexandre Oliva
for gcc/ChangeLog
PR libmudflap/53359
* tree-mudflap.c (mudflap_finish_file): Skip deferred decls
not found in the symtab.
---
gcc/tree-mudflap.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/gcc/tree-mudflap.c b/gcc/tree-mudflap.c
index 90d0448..e20f06e 100644
--- a/gcc/tree-mudflap.c
+++ b/gcc/tree-mudflap.c
@@ -1335,6 +1335,16 @@ mudflap_finish_file (void)
if (! TREE_PUBLIC (obj) && ! TREE_ADDRESSABLE (obj))
continue;
+ /* If we're neither emitting nor referencing the symbol,
+ don't register it. We have to register external symbols
+ if they happen to be in other files not compiled with
+ mudflap (say system libraries), and we must not register
+ internal symbols that we don't emit or they'll become
+ dangling references or force symbols to be emitted that
+ didn't have to. */
+ if (!symtab_get_node (obj))
+ continue;
+
if (! COMPLETE_TYPE_P (TREE_TYPE (obj)))
{
warning (OPT_Wmudflap,
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
