sh-*-linux build failure
Bootstrap failed in following configuration. configure --target=sh-unknown-linux --enable-languages=c --disable-libatomic --disable-threads --disable-shared --disable-libssp --disable-libquadmath --disable-libgomp xgcc: error: SH2a does not support little-endian So add build exception for SH2A. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index ce183a0..1fb2344 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2015-03-08 Yoshinori Sato + + * config/sh/t-linux: Add exception for SH2A. + 2015-03-05 Jan Hubicka PR ipa/65316 diff --git a/gcc/config/sh/t-linux b/gcc/config/sh/t-linux index d33c638..22b8e3e 100644 --- a/gcc/config/sh/t-linux +++ b/gcc/config/sh/t-linux @@ -1,2 +1,3 @@ MULTILIB_DIRNAMES= -MULTILIB_MATCHES = +MULTILIB_MATCHES = +MULTILIB_EXCEPTIONS = m2a m2a/ml -- Yoshinori Sato
Re: [PATCH] PR63175 - [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
On March 7, 2015 5:20:08 PM CET, Jeff Law wrote: >On 03/07/15 01:34, Richard Biener wrote: >> On March 6, 2015 9:22:05 PM CET, Martin Sebor >wrote: >>> On 03/06/2015 10:28 AM, Jeff Law wrote: On 03/02/15 09:28, Martin Sebor wrote: > On 03/02/2015 06:58 AM, Richard Biener wrote: >> On Fri, 27 Feb 2015, Martin Sebor wrote: >> > Given that Martin's fix to the testcase allowed it to succeed >>> without > Richi's fix for the underlying problem, is there a >modification >>> to > the > testcase or a new testcase that would really test the >>> optimization? Let me work on it. >>> >>> Below is a patch with a couple of minor tweaks to the existing >>> test first to update the search string and second to better >>> exercise the vectorization not only when the source address >>> isn't aligned on the expected boundary but also when the >>> destination address isn't. This enhancement revealed >>> an outstanding aspect of the regression (not fixed by Richard's >>> already committed patch). >>> >>> Besides this change, the patch also adds a number of other >>> tests to better exercise the vectorization by verifying it >>> takes place for arrays of elements of other sizes besides >>> word: byte, half word, and double word. Those tests reveal >>> both another regression WRT 4.8 and further vectorization >>> opportunities not exploited even in 4.8. I marked the latter >>> XFAIL in the tests so that when the regression is fully >>> resolved, the tests should pass with no unexpected failures. >> >> I have a hard time applying the patch because of line-wrapping >>> issues >> or my patch tool not groking the git diffs. >> >> Can you please either commit the patch or extract the testcase >> that still regresses and paste it into PR63175? > > I pasted a couple of such test cases to the bug. The full patch > is also attached to this email in case there was a problem with > line wrapping. So for the unaligned case, is that really a regression when >compared >>> to earlier compilers? If not, then it seems that we ought to at >least >>> be at a point where the regression marker for that BZ can be removed, right? ie, Richi's patch fixed the actual code quality regression >>> and your patch fixes the testsuite aspects, right? >>> >>> My interpretation of the bug report is that it points out >>> two problems: >>> >>> 1) a failure in the costmodel-bb-slp-9a.c test >>> 2) a quality regression observed by inspecting the assembly >>> emitted for the test >>> >>> The two are unrelated in that (2) didn't cause (1). >>> >>> Since Richi's patch fixed (2) and my latest patch fixes (1) >>> I would be inclined to consider the bug resolved. >>> >>> While GCC 5 doesn't vectorize some code that 4.8 does with >>> the same options, it's apparently by accident (or due to >>> a bug in 4.8). Since 5.0 does vectorize the same code when >>> the right set of options is specified, I agree with others >>> that none of my additional tests has exposed any other >>> regressions than the one that's already been addressed. >> >> Yes. Once the test cases have been fixed we should close the bug as >fixed. >Trunk regression marker removed. Not sure if it is worth backporting >to >4.9, but I left the 4.9 regression marker and the BZ open just in case. I backported the fix to the 4.9 branch already, so it would be nice to get the test cases fixes there as well. Richard. >jeff
Re: [Patch, fortran] PR65024 - [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer
ping!!! On 26 February 2015 at 06:33, Paul Richard Thomas wrote: > Dear All, > > This patch has something of a band aid flavour about it. However, the > more I look at it the more I like it and it cannot do any harm. In any > case, I spent a silly amount of time trying to understand why this > component fails to get its backend_decl in the usual way and failed. > That it is specific to unlimited polymorphic components and only > appears when 'bug' precedes 'next' were, in principle, giveaways that > didn't do it for me. > > Bootstraps and regtests on x86_64/FC21 - OK for trunk and 4.9? > > Paul > > 2015-02-26 Paul Thomas > > PR fortran/65024 > * trans-expr.c (gfc_conv_component_ref): If the component > backend declaration is missing and the derived type symbol is > available in the reference, call gfc_build_derived_type. > > 2015-02-26 Paul Thomas > > PR fortran/65024 > * gfortran.dg/unlimited_polymorphic_23.f90: New test -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [Patch, fortran] PR65024 - [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer
>> This patch has something of a band aid flavour about it. However, the >> more I look at it the more I like it and it cannot do any harm. In any >> case, I spent a silly amount of time trying to understand why this >> component fails to get its backend_decl in the usual way and failed. Well, it fixes things and seems safe, so let’s do it. OK to commit. FX
Re: sh-*-linux build failure
On Sun, 2015-03-08 at 17:14 +0900, Yoshinori Sato wrote: > Bootstrap failed in following configuration. > > configure --target=sh-unknown-linux --enable-languages=c > --disable-libatomic --disable-threads --disable-shared --disable-libssp > --disable-libquadmath --disable-libgomp > > xgcc: error: SH2a does not support little-endian > > So add build exception for SH2A. > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index ce183a0..1fb2344 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -1,3 +1,7 @@ > +2015-03-08 Yoshinori Sato > + > + * config/sh/t-linux: Add exception for SH2A. > + > 2015-03-05 Jan Hubicka > > PR ipa/65316 > diff --git a/gcc/config/sh/t-linux b/gcc/config/sh/t-linux > index d33c638..22b8e3e 100644 > --- a/gcc/config/sh/t-linux > +++ b/gcc/config/sh/t-linux > @@ -1,2 +1,3 @@ > MULTILIB_DIRNAMES= > -MULTILIB_MATCHES = > +MULTILIB_MATCHES = > +MULTILIB_EXCEPTIONS = m2a m2a/ml This disables SH2A completely? AFAIK SH2A big-endian Linux is a valid configuration. It should be 'm2a/ml' only, as in t-sh. Although all of that will probably not work if --with-endian=little,big or --with-endian=little is specified as configure option. Cheers, Oleg
Re: sh-*-linux build failure
Oleg Endo wrote: >> diff --git a/gcc/config/sh/t-linux b/gcc/config/sh/t-linux >> index d33c638..22b8e3e 100644 >> --- a/gcc/config/sh/t-linux >> +++ b/gcc/config/sh/t-linux >> @@ -1,2 +1,3 @@ >> MULTILIB_DIRNAMES= >> -MULTILIB_MATCHES = >> +MULTILIB_MATCHES = >> +MULTILIB_EXCEPTIONS = m2a m2a/ml > > This disables SH2A completely? AFAIK SH2A big-endian Linux is a valid > configuration. It should be 'm2a/ml' only, as in t-sh. Although all of > that will probably not work if --with-endian=little,big or > --with-endian=little is specified as configure option. How about a bit modified patch below? Regards, kaz -- * config/sh/t-linux (MULTILIB_EXCEPTIONS): Define for m2a cases. diff --git a/config/sh/t-linux b/config/sh/t-linux index d33c638..a30ab2e 100644 --- a/config/sh/t-linux +++ b/config/sh/t-linux @@ -1,2 +1,9 @@ MULTILIB_DIRNAMES= MULTILIB_MATCHES = + +DEFAULT_ENDIAN = $(word 1,$(TM_ENDIAN_CONFIG)) +ifeq ($(DEFAULT_ENDIAN),ml) +MULTILIB_EXCEPTIONS = m2a m2a/ml +else +MULTILIB_EXCEPTIONS = ml/m2a +endif
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
+Ian + ping On 11 Feb 2015, at 14:37, Iain Sandoe wrote: > Hi Jeff, > > On 9 Feb 2015, at 14:47, Jeff Law wrote: > >> On 02/01/15 09:42, Iain Sandoe wrote: >>> >>> This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a >>> PR if that is considered necessary). >> Has this been addressed or is it still pending? > > I believe it's still awaiting review Dominque has raised PR65351 to track this. (i can rebase the patch if needed, it's being regularly tested on trunk) thanks, Iain > >> >> >>> >>> In fact it is not libcc1, but libiberty that is the cause - >>> >>> On 26 Jan 2015, at 14:13, Rainer Orth wrote: >>> FX writes: >> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >> This means that the PIC library is being built with non-pic relocs. > > config/mh-darwin says that -mdynamic-no-pic is there because it “speeds > compiles by 3-5%”. I don’t think we care about speed when the bootstrap > fails, so can we remove it altogether? Darwin/i686 still doesn't bootstrap without this patch, I believe. Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving that target broken? >>> >>> The PIC variant of libiberty, has never (since it was added, AFAICT) >>> catered for the possibility that non-PIC and PIC options might conflict >>> (and/or that it might not be possible to override non-PIC options simply by >>> appending PIC ones). >>> >>> This has gone un-noticed until the libcc1 plugin started linking with the >>> pic version of libiberty. >>> >>> Darwin uses -mdynamic-no-pic as a default flag during bootstrap for 32bit >>> targets, since that gives a stated ~ 3-5% improvement in performance. >>> >>> It is not possible to override this non-pic option by appending -fPIC (that >>> simply results in a warning that mdynamic-no-pic takes precedence). >>> >>> I'd rather not pretend that there's no problem and simply penalise >>> performance on m32 darwin by removing the option from the bootflags. >>> >>> So here's a patch that allows a target to declare incompatible non-pic >>> options (in the same way that we have PIC options already declared as >>> distinct). >>> >>> The patch is largely mechanical (each of the targets adjusted to use the >>> NONPIC flag for the relevant case). >>> >>> As an aside, is there a portability reason that we don't make this repeated >>> operation into a make function? >>> >>> bootstapped on x86_64-linux, x86_64-darwin12, i686-darwin10, >>> powerpc-darwin9, >>> cross-compiled x86-64-darwin12 X i686-darwin10 , native X i686-darwin10 >>> (x86_64-darwin12 build). >>> >>> all languages including Ada (note that there's a local patch needed to >>> work-around an Ada bootstrap issue - pr64349) >>> >>> OK for trunk? >>> Iain >>> >>> libiberty: >>> * Makefile.in (NONPICFLAG, NEWCFLAGS, NEWCPPFLAGS): New. >>> (COMPILE.c): Adjust to use new flags. (all non-pic targets): >>> Adjust to use NONPIC flag. >>> * configure.ac (NOPICFLAG): New. >>> * configure: Regenerate. >>> >> > diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in index f06cc69..8674b4a 100644 --- a/libiberty/Makefile.in +++ b/libiberty/Makefile.in @@ -62,6 +62,7 @@ MAKEINFO = @MAKEINFO@ PERL = @PERL@ PICFLAG = @PICFLAG@ +NOPICFLAG = @NOPICFLAG@ NOASANFLAG = @NOASANFLAG@ MAKEOVERRIDES = @@ -113,7 +114,16 @@ installcheck: installcheck-subdir INCDIR=$(srcdir)/$(MULTISRCTOP)../include -COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. -I$(INCDIR) $(HDEFINES) @ac_libiberty_warn_cflags@ +# If the passed CFLAGS or CPPFLAGS include options which are incompatible +# with PIC code (and cannot be overridden) save them for non-pic code... +NONPIC = $(filter $(NOPICFLAG), $(CFLAGS)) +NONPIC += $(filter $(NOPICFLAG), $(CPPFLAGS)) +# ... and then remove them from the default. +NEWCFLAGS = $(filter-out $(NOPICFLAG), $(CFLAGS)) +NEWCPPFLAGS = $(filter-out $(NOPICFLAG), $(CPPFLAGS)) + +COMPILE.c = $(CC) -c @DEFS@ $(NEWCFLAGS) $(NEWCPPFLAGS) -I. -I$(INCDIR) \ +$(HDEFINES) @ac_libiberty_warn_cflags@ # Just to make sure we don't use a built-in rule with VPATH .c.$(objext): @@ -519,7 +529,7 @@ $(CONFIGURED_OFILES): stamp-picdir stamp-noasandir if [ x"$(NOASANFLAG)" != x ]; then \ $(COMPILE.c) $(PICFLAG) $(NOASANFLAG) $(srcdir)/_doprnt.c -o noasan/$@; \ else true; fi - $(COMPILE.c) $(srcdir)/_doprnt.c $(OUTPUT_OPTION) + $(COMPILE.c) $(NONPIC) $(srcdir)/_doprnt.c $(OUTPUT_OPTION) ./alloca.$(objext): $(srcdir)/alloca.c config.h $(INCDIR)/ansidecl.h \ $(INCDIR)/libiberty.h @@ -529,7 +539,7 @@ $(CONFIGURED_OFILES): stamp-picdir stamp-noasandir if [ x"$(NOASANFLAG)" != x ]; then \ $(COMPILE.c) $(PICFLAG) $(NOASANFLAG) $(srcdir)/alloca.c -o noasan/$
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
Iain Sandoe writes: > +Ian > + ping The patch is missing the change to maint-tool to generate the rules at the bottom of libiberty/Makefile.in. Right now the libiberty Makefile does not require GNU make, and it's not clear to me that we want to push that dependency onto all projects that use libiberty. It looks feasible to change this patch to not require GNU make, by using a shell expansion rather than a make expansion, and I think that would be the conservative thing to do. > +# If the passed CFLAGS or CPPFLAGS include options which are incompatible > +# with PIC code (and cannot be overridden) save them for non-pic code... Is this a likely scenario? Where would these options be coming from? > +NONPIC = $(filter $(NOPICFLAG), $(CFLAGS)) > +NONPIC += $(filter $(NOPICFLAG), $(CPPFLAGS)) CPPFLAGS should precede CFLAGS. Ian > On 11 Feb 2015, at 14:37, Iain Sandoe wrote: > >> Hi Jeff, >> >> On 9 Feb 2015, at 14:47, Jeff Law wrote: >> >>> On 02/01/15 09:42, Iain Sandoe wrote: This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if that is considered necessary). >>> Has this been addressed or is it still pending? >> >> I believe it's still awaiting review > > Dominque has raised PR65351 to track this. > (i can rebase the patch if needed, it's being regularly tested on trunk) > > thanks, > Iain > >> >>> >>> In fact it is not libcc1, but libiberty that is the cause - On 26 Jan 2015, at 14:13, Rainer Orth wrote: > FX writes: > >>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >>> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >>> This means that the PIC library is being built with non-pic relocs. >> >> config/mh-darwin says that -mdynamic-no-pic is there because it “speeds >> compiles by 3-5%”. I don’t think we care about speed when the bootstrap >> fails, so can we remove it altogether? > > Darwin/i686 still doesn't bootstrap without this patch, I believe. > Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving > that target broken? The PIC variant of libiberty, has never (since it was added, AFAICT) catered for the possibility that non-PIC and PIC options might conflict (and/or that it might not be possible to override non-PIC options simply by appending PIC ones). This has gone un-noticed until the libcc1 plugin started linking with the pic version of libiberty. Darwin uses -mdynamic-no-pic as a default flag during bootstrap for 32bit targets, since that gives a stated ~ 3-5% improvement in performance. It is not possible to override this non-pic option by appending -fPIC (that simply results in a warning that mdynamic-no-pic takes precedence). I'd rather not pretend that there's no problem and simply penalise performance on m32 darwin by removing the option from the bootflags. So here's a patch that allows a target to declare incompatible non-pic options (in the same way that we have PIC options already declared as distinct). The patch is largely mechanical (each of the targets adjusted to use the NONPIC flag for the relevant case). As an aside, is there a portability reason that we don't make this repeated operation into a make function? bootstapped on x86_64-linux, x86_64-darwin12, i686-darwin10, powerpc-darwin9, cross-compiled x86-64-darwin12 X i686-darwin10 , native X i686-darwin10 (x86_64-darwin12 build). all languages including Ada (note that there's a local patch needed to work-around an Ada bootstrap issue - pr64349) OK for trunk? Iain libiberty: * Makefile.in (NONPICFLAG, NEWCFLAGS, NEWCPPFLAGS): New. (COMPILE.c): Adjust to use new flags. (all non-pic targets): Adjust to use NONPIC flag. * configure.ac (NOPICFLAG): New. * configure: Regenerate. >>> >> > > diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in > index f06cc69..8674b4a 100644 > --- a/libiberty/Makefile.in > +++ b/libiberty/Makefile.in > @@ -62,6 +62,7 @@ MAKEINFO = @MAKEINFO@ > PERL = @PERL@ > > PICFLAG = @PICFLAG@ > +NOPICFLAG = @NOPICFLAG@ > NOASANFLAG = @NOASANFLAG@ > > MAKEOVERRIDES = > @@ -113,7 +114,16 @@ installcheck: installcheck-subdir > > INCDIR=$(srcdir)/$(MULTISRCTOP)../include > > -COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. -I$(INCDIR) > $(HDEFINES) @ac_libiberty_warn_cflags@ > +# If the passed CFLAGS or CPPFLAGS include options which are incompatible > +# with PIC code (and cannot be overridden) save them for non-pic code... > +NONPIC = $(filter $(NOPICFLAG), $(CFLAGS)) > +NONPIC += $(filter $(NOPICFLAG), $(CPPFLAGS)) > +# ... and then remove them from th
[SH] Backport fix of PR 53988 to 4.9/4.8
Hi,
Backporting of the fix went into GCC 5 seems to intrusive for the
released branches. Hence I'd propose to remove the problematic patterns
altogether, as they can silently generate wrong code. The attached
patch does that. Tested briefly with 'make all' and with
make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Kaz, do you have any objections?
Cheers,
Oleg
gcc/ChangeLog:
PR target/53988
* config/sh/sh.md (*tst_t_zero): Remove insns.
gcc/testsuite/ChangeLog:
PR target/53988
* gcc.target/sh/pr53988.c: Mark tests as xfail.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 221258)
+++ gcc/config/sh/sh.md (working copy)
@@ -651,32 +651,6 @@
"tst #255,%0"
[(set_attr "type" "mt_group")])
-;; This pattern might be risky because it also tests the upper bits and not
-;; only the subreg. However, it seems that combine will get to this only
-;; when testing sign/zero extended values. In this case the extended upper
-;; bits do not matter.
-(define_insn "*tst_t_zero"
- [(set (reg:SI T_REG)
- (eq:SI
- (subreg:QIHI
- (and:SI (match_operand:SI 0 "arith_reg_operand" "%r")
- (match_operand:SI 1 "arith_reg_operand" "r")) )
- (const_int 0)))]
- "TARGET_SH1 && TARGET_LITTLE_ENDIAN"
- "tst %0,%1"
- [(set_attr "type" "mt_group")])
-
-(define_insn "*tst_t_zero"
- [(set (reg:SI T_REG)
- (eq:SI
- (subreg:QIHI
- (and:SI (match_operand:SI 0 "arith_reg_operand" "%r")
- (match_operand:SI 1 "arith_reg_operand" "r")) )
- (const_int 0)))]
- "TARGET_SH1 && TARGET_BIG_ENDIAN"
- "tst %0,%1"
- [(set_attr "type" "mt_group")])
-
;; Extract LSB, negate and store in T bit.
(define_insn "tstsi_t_and_not"
[(set (reg:SI T_REG)
Index: gcc/testsuite/gcc.target/sh/pr53988.c
===
--- gcc/testsuite/gcc.target/sh/pr53988.c (revision 221258)
+++ gcc/testsuite/gcc.target/sh/pr53988.c (working copy)
@@ -5,9 +5,9 @@
/* { dg-do compile } */
/* { dg-options "-O1" } */
/* { dg-skip-if "" { "sh*-*-*" } { "-m5*"} { "" } } */
-/* { dg-final { scan-assembler-times "tst\tr" 8 } } */
-/* { dg-final { scan-assembler-not "tst\t#255" } } */
-/* { dg-final { scan-assembler-not "exts|extu|and|movu" } } */
+/* { dg-final { scan-assembler-times "tst\tr" 8 { xfail *-*-*} } } */
+/* { dg-final { scan-assembler-not "tst\t#255" { xfail *-*-*} } } */
+/* { dg-final { scan-assembler-not "exts|extu|and|movu" { xfail *-*-*} } } */
int
test00 (char* a, char* b, int c, int d)
PR c++/64626 - C++14 single quote should not always be a digit separator
I just look to see if a lexed number in libcpp ends in a '.
If so, back up one character and let string processing handle it.
I get one warning and one error for each instance but I'd rather not
error when it should pass.
Built and tests clean on x86_64-linux.
OK?
libcpp/
2015-03-09 Edward Smith-Rowland <3dw...@verizon.net>
PR c++/64626
* expr.c (parse_has_attribute): New function; (eval_token): Look for
__has_attribute__ and route to parse_has_attribute.
gcc/testsuite/
2015-03-09 Edward Smith-Rowland <3dw...@verizon.net>
PR c++/64626
g++.dg/cpp1y/pr64626.C: New.
g++.dg/cpp1y/digit-sep-neg.C: Adjust errors and warnings.
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 221218)
+++ libcpp/lex.c(working copy)
@@ -1400,6 +1400,9 @@
NORMALIZE_STATE_UPDATE_IDNUM (nst, *cur);
cur++;
}
+ /* A number can't end with a digit separator. */
+ if (DIGIT_SEP (cur[-1]))
+ --cur;
pfile->buffer->cur = cur;
}
Index: gcc/testsuite/g++.dg/cpp1y/pr64626.C
===
--- gcc/testsuite/g++.dg/cpp1y/pr64626.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp1y/pr64626.C(working copy)
@@ -0,0 +1,20 @@
+// PR c++/64626
+// { dg-do compile { target c++14 } }
+
+#define STR(s) #s
+int
+main()
+{
+ int i = 1'2;
+ const char *s[3]
+ {
+STR(1' '),
+STR(..),
+STR(%:%),
+ };
+}
+#if 0
+1' '
+..
+%:%
+#endif
Index: gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C
===
--- gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C (revision 221218)
+++ gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C (working copy)
@@ -10,7 +10,7 @@
i = 0004''000'000; // { dg-error "adjacent digit separators" }
i = 0B1'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0; // OK
i = 0b'0001'''''; // { dg-error "digit separator after
base indicator" }
- i = 0b0001''''''; // { dg-error "digit separator outside
digit sequence" }
+ i = 0b0001''''''; // { dg-error "missing terminating" }
unsigned u = 0b0001''''''U; // { dg-error "digit
separator outside digit sequence" }
double d = 0.0;
@@ -18,9 +18,15 @@
d = 1.'602'176'565e-19; // { dg-error "digit separator adjacent to decimal
point" }
d = 1.602''176'565e-19; // { dg-error "adjacent digit separators" }
d = 1.602'176'565'e-19; // { dg-error "digit separator adjacent to exponent"
}
- d = 1.602'176'565e'-19; // { dg-error "digit separator adjacent to exponent"
}
+ d = 1.602'176'565e'-19; // { dg-error "missing terminating" }
d = 1.602'176'565e-'19; // { dg-error "digit separator adjacent to exponent"
}
d = 1.602'176'565e-1'9; // OK
- d = 1.602'176'565e-19'; // { dg-error "digit separator outside digit
sequence" }
+ d = 1.602'176'565e-19'; // { dg-error "missing terminating" }
float f = 1.602'176'565e-19'F; // { dg-error "digit separator outside digit
sequence" }
}
+
+// { dg-warning "missing terminating" { target *-*-* } 13 }
+
+// { dg-warning "missing terminating" { target *-*-* } 21 }
+
+// { dg-warning "missing terminating" { target *-*-* } 24 }
Re: PR c++/64626 - C++14 single quote should not always be a digit separator
On Sun, Mar 08, 2015 at 02:33:03PM -0400, Ed Smith-Rowland wrote: > I just look to see if a lexed number in libcpp ends in a '. > If so, back up one character and let string processing handle it. > > I get one warning and one error for each instance but I'd rather not error > when it should pass. > > Built and tests clean on x86_64-linux. > > OK? > > > > libcpp/ > > 2015-03-09 Edward Smith-Rowland <3dw...@verizon.net> > > PR c++/64626 > * expr.c (parse_has_attribute): New function; (eval_token): Look for > __has_attribute__ and route to parse_has_attribute. This ChangeLog entry doesn't match the patch, you've changed lex.c (lex_number) instead... > --- libcpp/lex.c (revision 221218) > +++ libcpp/lex.c (working copy) > @@ -1400,6 +1400,9 @@ > NORMALIZE_STATE_UPDATE_IDNUM (nst, *cur); > cur++; > } > + /* A number can't end with a digit separator. */ > + if (DIGIT_SEP (cur[-1])) > + --cur; > >pfile->buffer->cur = cur; > } Jakub
[committed] Add dg-require-alias to gcc.dg/ipa/ipa-icf-34.c
This test requires alias support and fails on hppa2.0-hp-hpux11.11 as a result.
Tested on hppa2.0-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
* gcc.dg/ipa/ipa-icf-34.c: Add dg-require-alias.
Index: gcc.dg/ipa/ipa-icf-34.c
===
--- gcc.dg/ipa/ipa-icf-34.c (revision 221239)
+++ gcc.dg/ipa/ipa-icf-34.c (working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-require-alias "" } */
/* { dg-options "-O0 -fipa-icf -fdump-ipa-icf" } */
static int do_work(void)
[committed] Add target c99_runtime to gcc.dg/ipa/pr64307.c
gcc.dg/ipa/pr64307.c includes complex.h. It is only available on c99 targets
and fails
as a result on hppa*-*-hpux*.
Tested on hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
* gcc.dg/ipa/pr64307.c: Add target c99_runtime.
Index: gcc.dg/ipa/pr64307.c
===
--- gcc.dg/ipa/pr64307.c(revision 221239)
+++ gcc.dg/ipa/pr64307.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c99_runtime } } */
/* { dg-options "-O0 -fipa-icf -fdump-ipa-icf" } */
#include
[committed] Add dg-require-effective-target c99_runtime to gcc.dg/signbit-sa.c
The signbit function was introduced in c99.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
* gcc.dg/signbit-sa.c: Add dg-require-effective-target c99_runtime
Index: gcc.dg/signbit-sa.c
===
--- gcc.dg/signbit-sa.c (revision 221239)
+++ gcc.dg/signbit-sa.c (working copy)
@@ -1,5 +1,6 @@
/* Some versions of Solaris give strict-aliasing warnings for
signbit. */
+/* { dg-require-effective-target c99_runtime } */
/* { dg-options "-std=c99 -O2 -Wstrict-aliasing" } */
#include
Re: [patch, fortran] Bug 64432 - [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
On Sun, Mar 8, 2015 at 6:43 AM, Jerry DeLisle wrote: > The attached patch fixes this regression Nice, thanks for working on this! Just out of curiosity, what was the reason for the powerpc failures you had with the previous version of the patch? > and implements KIND=1 and KIND=2 > compatible calls. ... but I'm not convinced this is worth it. As far as I can see, the reason you needed to add the *K symbols to the library is solely to correctly handle the kind=1 and 2 cases, right? However, IMHO kind=1 and 2 integers have too little room for decent precision and for avoiding wraparound anyway. I can see people using the kind=4 version, as that is the default that you get if you don't play around with non-default kinds. I can also see people using the kind=8 version, in order to get better resolution and avoid wraparound. But explicitly using kind=1 or 2, why on earth would anyone do that? So the only reason why we need to support it is because the standard says so. So I would prefer if we just hardcode the error values in the frontend (-HUGE, 0, 0), in case somebody tries to use the kind=1,2 versions, thus also removing the need for the new library functions, keeping the existing simpler ones instead. AFAICT this would be standards conforming. Any other opinions on this? Cheers, -- Janne Blomqvist
[committed] xfail gfortran.dg/quad_2.f90 on hppa*-*-hpux*
The HP quad precision libcall has a 1 ULP error in computing the sqrt of 2.
This causes the test
to fail.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
PR target/62251
* gfortran.dg/quad_2.f90: xfail hppa*-*-hpux*.
Index: gfortran.dg/quad_2.f90
===
--- gfortran.dg/quad_2.f90 (revision 221266)
+++ gfortran.dg/quad_2.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { xfail hppa*-*-hpux* } }
! { dg-require-effective-target fortran_largest_fp_has_sqrt }
!
! This test checks whether the largest possible
[committed] Add dg-require-effective-target named_sections to g++.dg/ipa/pr63621.C
The test uses named sections.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
* g++.dg/ipa/pr63621.C: Add dg-require-effective-target named_sections.
Index: g++.dg/ipa/pr63621.C
===
--- g++.dg/ipa/pr63621.C(revision 221267)
+++ g++.dg/ipa/pr63621.C(working copy)
@@ -1,4 +1,5 @@
// { dg-do compile }
+// { dg-require-effective-target named_sections }
class A
{
public:
Re: Fix increase_alignment
> > I unforutnately spot another problem. With presence of section anchors we > can not increase alignment of symbol that was already placed into the section. > I think this is reason why we still have pass_increase_alignments that runs > only on target with anchors. > > I added the following check: > > + /* If target is already placed in an anchor, we can not touch its > + alignment. */ > + if (DECL_RTL_SET_P (target->decl) > + && MEM_P (DECL_RTL (target->decl)) > + && SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (DECL_RTL (target->decl), 0))) > +return false; > > but found it breaks several vectorization testcases with LTO. This is > becuase notice_global_symbol computes DECL_RTL even before > node->increase_alignment is run and we are stuck. > > I decided to track this separately from this patch that snowballed quite a bit > already. I do not see how to solve it short of making notice_global_symbol to > not compute DECL_RTL. It was never quite clear to me why notice_global_symbol > is actually doing this at first place. Is it becuase of target mangling > happing only at RTL generation time? This is now PR65355
Re: [SH] Backport fix of PR 53988 to 4.9/4.8
Oleg Endo wrote:
> Backporting of the fix went into GCC 5 seems to intrusive for the
> released branches. Hence I'd propose to remove the problematic patterns
> altogether, as they can silently generate wrong code. The attached
> patch does that. Tested briefly with 'make all' and with
> make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> Kaz, do you have any objections?
I have no objection.
Regards,
kaz
[committed] Skip failing scan-assembler checks in g++.dg/abi/anon3.C and g++.dg/abi/rtti3.C
Since r214177, DECL_COMDAT no longer triggers comdat_linkage. As a result,
some types that were
previously "weak" are no longer weak on hppa-hpux.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-03-08 John David Anglin
PR target/62247
* g++.dg/abi/anon3.C: Skip failing scan-assembler checks on
hppa*-*-hpux*.
* g++.dg/abi/rtti3.C: Likewise.
Index: g++.dg/abi/anon3.C
===
--- g++.dg/abi/anon3.C (revision 221270)
+++ g++.dg/abi/anon3.C (working copy)
@@ -2,13 +2,13 @@
typedef struct {
// { dg-final { scan-assembler ".weak\(_definition\)?\[
\t\]_?_ZN4Heya4blahEv" } }
- // { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTI4Heya" } }
+ // { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTI4Heya" {
target { ! { hppa*-*-hpux* } } } } }
// { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTV4Heya" } }
virtual const char *blah() {
return "Heya::blah";
}
// { dg-final { scan-assembler ".weak\(_definition\)?\[
\t\]_?_ZN4Heya1A1fEv" } }
- // { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTIN4Heya1AE"
} }
+ // { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTIN4Heya1AE"
{ target { ! { hppa*-*-hpux* } } } } }
// { dg-final { scan-assembler ".weak\(_definition\)?\[ \t\]_?_ZTVN4Heya1AE"
} }
struct A {
virtual void f() { }
Index: g++.dg/abi/rtti3.C
===
--- g++.dg/abi/rtti3.C (revision 221270)
+++ g++.dg/abi/rtti3.C (working copy)
@@ -3,7 +3,7 @@
// { dg-require-weak "" }
// { dg-skip-if "Linkonce not weak" { *-*-mingw* *-*-cygwin } { "*" } { "" } }
-// { dg-final { scan-assembler ".weak\[ \t\]_?_ZTSPP1A" { target { ! {
*-*-darwin* } } } } }
+// { dg-final { scan-assembler ".weak\[ \t\]_?_ZTSPP1A" { target { ! {
*-*-darwin* hppa*-*-hpux* } } } } }
// { dg-final { scan-assembler-not ".weak\[ \t\]_?_ZTIPP1A" { target { ! {
*-*-darwin* } } } } }
// { dg-final { scan-assembler ".weak_definition\[ \t\]_?_ZTSPP1A" { target {
*-*-darwin* } } } }
// { dg-final { scan-assembler-not ".weak_definition\[ \t\]_?_ZTIPP1A" {
target { *-*-darwin* } } } }
Re: [patch, fortran] Bug 64432 - [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote: > So I would prefer if we just hardcode the error values in the frontend > (-HUGE, 0, 0), in case somebody tries to use the kind=1,2 versions, > thus also removing the need for the new library functions, keeping the > existing simpler ones instead. AFAICT this would be standards > conforming. Any other opinions on this? > +1 -- Steve
Fix ODR hash corrpution
Hi,
the odr_type_hash has two modes - if type names are availale it is hashing
by type names, if they are not it is hashing by virtual tables (and workks only
on polymorphic types).
What I did not consider however was units where both are mixed. Here the
hash does not play well with the equivalence predicate and we get random
hash tale corruption.
This patch fixes it by splitting odr_type_hash into two hashes that are
maintained in parallel and kept in sync.
Bootstrapped/regtested x86_64-linux and also tested with firefox and chromium
Will commit it shortly.
Honza
PR lto/65316
* ipa-utils.h (types_odr_comparable): Add strict argument.
* ipa-devirt.c: Fix whitespace;
(odr_hasher): Remove.
(odr_name_hasher, odr_vtable_hasher): New hashers.
(can_be_name_hashed_p): New predicate.
(hash_type_name): remove.
(hash_odr_name): New.
(odr_name_hasher::hash): new.
(can_be_vtable_hashed_p): New.
(hash_odr_vtable): New.
(odr_vtable_hasher::hash): New.
(types_same_for_odr): Add strict parameter.
(types_odr_comparable): Likewise.
(odr_name_hasher::equal): New.
(odr_vtable_hasher::equal): New.
(odr_name_hasher::remove): New.
(odr_hash_type): Change to hash_table.
(odr_vtable_hash_type): New.
(odr_vtable_hash): New.
(odr_subtypes_equivalent_p): Do strict comparsion.
(add_type_duplicate): Merge type names; cleanup; avoid type
duplicates.
(register_odr_type): Initialize vtable hash.
(build_type_inheritance_graph): Likewise
(get_odr_type): Reorg to use two hashes.
(dump_possible_polymorphic_call_targets): Move sanity check after debug
output.
(ipa_devirt): Dump type_inheritance_graph.
(types_same_for_odr): Add strict mode.
* g++.dg/lto/pr65316_0.C: New testcase.
* g++.dg/lto/pr65316_1.C: New testcase.
Index: ipa-utils.h
===
--- ipa-utils.h (revision 221267)
+++ ipa-utils.h (working copy)
@@ -80,7 +80,7 @@ bool type_known_to_have_no_deriavations_
bool contains_polymorphic_type_p (const_tree);
void register_odr_type (tree);
bool types_must_be_same_for_odr (tree, tree);
-bool types_odr_comparable (tree, tree);
+bool types_odr_comparable (tree, tree, bool strict = false);
cgraph_node *try_speculative_devirtualization (tree, HOST_WIDE_INT,
ipa_polymorphic_call_context);
Index: testsuite/g++.dg/lto/pr65316_0.C
===
--- testsuite/g++.dg/lto/pr65316_0.C(revision 0)
+++ testsuite/g++.dg/lto/pr65316_0.C(revision 0)
@@ -0,0 +1,142 @@
+// { dg-lto-do link }
+// { dg-lto-options { { -flto -std=c++11 -g2 -fno-lto-odr-type-merging -O2 } }
}
+// { dg-extra-ld-options "-r -nostdlib -O2 -fno-lto-odr-type-merging" }
+namespace std
+{
+ typedef long unsigned int size_t;
+}
+extern "C"
+{
+ typedef struct
+ {
+ } __mbstate_t;
+}
+namespace std __attribute__ ((__visibility__ ("default")))
+{
+ template < class _CharT > struct char_traits;
+}
+
+typedef __mbstate_t mbstate_t;
+namespace std __attribute__ ((__visibility__ ("default")))
+{
+ template < typename _CharT, typename _Traits =
+char_traits < _CharT > >class basic_ostream;
+ typedef basic_ostream < char >ostream;
+}
+
+using namespace std;
+class Cstring
+{
+public:
+ Cstring (const char *str, int l = 0);
+};
+extern ostream & operator << (ostream & os, const Cstring & string);
+class Foo_Log_Handler
+{
+ virtual int write_message (const char *msg, size_t msg_len, int channel,
+int level) = 0;
+};
+class Foo_Log_Handler_Stream:public Foo_Log_Handler
+{
+ virtual int write_message (const char *msg, size_t msg_len, int channel,
+int level) override;
+ Cstring m_filename;
+};
+namespace std __attribute__ ((__visibility__ ("default")))
+{
+ template <> struct char_traits
+ {
+typedef mbstate_t state_type;
+ };
+ enum _Ios_Fmtflags
+ {
+ };
+ enum _Ios_Iostate
+ {
+ };
+ class ios_base
+ {
+ public:
+typedef _Ios_Iostate iostate;
+ };
+}
+
+namespace std __attribute__ ((__visibility__ ("default")))
+{
+ template < typename _CharT > class __ctype_abstract_base
+ {
+ };
+ template < typename _CharT > class ctype
+ {
+ public:
+typedef char char_type;
+mutable char _M_widen_ok;
+char_type widen (char __c) const
+{
+ if (_M_widen_ok)
+ return this->do_widen (__c);
+}
+virtual char_type do_widen (char __c) const
+{
+}
+ };
+ template < typename _Facet >
+inline const _Facet & __check_facet (const _Facet * __f)
+ {
+ }
+template < typename _CharT, typename _Traits > class basic_ios:public
+ios_base
+ {
+typedef _CharT char_type;
+typedef ctype < _CharT > __ctype_type;
+const __ctype_type *_M_ctype
[patch, doc] don't document old gcc behavior in current manual
In general, the GCC manual documents the version of the compiler that it
goes with. New features are being added all the time, and it's not
terribly useful to users to document that such-and-such a feature isn't
supported in ancient GCC versions, or to suggest workarounds for old GCC
versions that lack the feature, or to write the documentation for a new
feature in terms of what has changed from some previous behavior of GCC
instead of what the current behavior is, or to describe a change using
words like "recently" or "newer" or "previous version" that are
guaranteed to become bit-rotten over time.
This patch deletes a bunch of such material from the manual; it's
probably not exhaustive, but it's a step in the right direction, at
least. One such "recently" reference I found referred to a change that
was made in 2002, another place described behavior that was removed in
version 2.6, etc.
I'll commit this in a few days unless I hear complaints that I'm
throwing away useful information. OTOH, I note that the GCC web site
has manuals online going back to GCC 2.95.3, if people really need
documentation for old compiler versions
-Sandra
2015-03-08 Sandra Loosemore
gcc/
* doc/extend.texi (-fgnu89-inline): Remove discussion about
old GCC versions.
(-fabi-compat-version): Likewise.
(-ffriend-injection): Likewise.
(-Wdeclaration-after-statement): Likewise.
(-fomit-frame-pointer): Likewise.
(-ftree-coalesce-inlined-vars): Likewise.
(-fvisibility=): Likewise.
* doc/extend.texi (Typeof): Likewise.
(Zero Length): Likewise.
(Escaped Newlines): Likewise.
(Compound Literals): Likewise.
(Function Attributes): Likewise.
(Label Attributes): Likewise.
(Type Attributes): Likewise.
(Function Names): Likewise.
(Other Builtins): Likewise.
(Function Specific Option Pragmas): Likewise.
(C++ Interface): Likewise.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 221261)
+++ gcc/doc/invoke.texi (working copy)
@@ -1767,17 +1767,15 @@ releases.
@opindex fgnu89-inline
The option @option{-fgnu89-inline} tells GCC to use the traditional
GNU semantics for @code{inline} functions when in C99 mode.
-@xref{Inline,,An Inline Function is As Fast As a Macro}. This option
-is accepted and ignored by GCC versions 4.1.3 up to but not including
-4.3. In GCC versions 4.3 and later it changes the behavior of GCC in
-C99 mode. Using this option is roughly equivalent to adding the
+@xref{Inline,,An Inline Function is As Fast As a Macro}.
+Using this option is roughly equivalent to adding the
@code{gnu_inline} function attribute to all inline functions
(@pxref{Function Attributes}).
The option @option{-fno-gnu89-inline} explicitly tells GCC to use the
C99 semantics for @code{inline} when in C99 or gnu99 mode (i.e., it
-specifies the default behavior). This option was first supported in
-GCC 4.3. This option is not supported in @option{-std=c90} or
+specifies the default behavior).
+This option is not supported in @option{-std=c90} or
@option{-std=gnu90} mode.
The preprocessor macros @code{__GNUC_GNU_INLINE__} and
@@ -2112,7 +2110,7 @@ See also @option{-Wabi}.
@item -fabi-compat-version=@var{n}
@opindex fabi-compat-version
-Starting with GCC 4.5, on targets that support strong aliases, G++
+On targets that support strong aliases, G++
works around mangling changes by creating an alias with the correct
mangled name when defining a symbol with an incorrect mangled name.
This switch specifies which ABI version to use for the alias.
@@ -2173,11 +2171,10 @@ deprecated, and may be removed in a futu
Inject friend functions into the enclosing namespace, so that they are
visible outside the scope of the class in which they are declared.
Friend functions were documented to work this way in the old Annotated
-C++ Reference Manual, and versions of G++ before 4.1 always worked
-that way. However, in ISO C++ a friend function that is not declared
+C++ Reference Manual.
+However, in ISO C++ a friend function that is not declared
in an enclosing scope can only be found using argument dependent
-lookup. This option causes friends to be injected as they were in
-earlier releases.
+lookup. GCC defaults to the standard behavior.
This option is for compatibility, and may be removed in a future
release of G++.
@@ -4536,8 +4533,7 @@ except when the same as the default prom
@opindex Wno-declaration-after-statement
Warn when a declaration is found after a statement in a block. This
construct, known from C++, was introduced with ISO C99 and is by default
-allowed in GCC@. It is not supported by ISO C90 and was not supported by
-GCC versions before GCC 3.0. @xref{Mixed Declarations}.
+allowed in GCC@. It is not supported by ISO C90. @xref{Mixed Declarations}.
@item -Wundef
@opindex Wundef
@@ -7455,11 +7451,10 @@ machine-description macro @code{FRAME_PO
whether a target machine supports this flag. @x
Re: [patch, fortran] Bug 64432 - [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
On 03/08/2015 04:58 PM, Steve Kargl wrote: On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote: So I would prefer if we just hardcode the error values in the frontend (-HUGE, 0, 0), in case somebody tries to use the kind=1,2 versions, thus also removing the need for the new library functions, keeping the existing simpler ones instead. AFAICT this would be standards conforming. Any other opinions on this? +1 No problem, will do. It was a learning exercise for me regardless. Jerry
Fix vectorizer alignment update wrt section anchors
Hi,
this patch avoids notice_global_symbol to create DECL_RTL prior IPA
optimization. Consequently symtab_node::can_increase_alignment_p can check for
presence of DECL_RTL with section anchor. This makes it possible to bump up
alignment in tree-vect-data-refs.c in some cases (when DECL_RTL is not computed
yet).
I suppose vectorizer can also be updated to just bump up alingmnet of the
section and then use the known offset within the section.
Bootstrapped/regtested x86_64-linux and ppc64-linux, will commit it tomorrow
if there are no better ideas for fix.
PR tree-optimization/65355
* varasm.c (notice_global_symbol): Do not produce RTL.
* symtab.c (symtab_node::can_increase_alignment_p): Check for section
anchor.
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Do not
check for section anchors.
* gcc.dg/vect/section-anchors-vect-69.c: Update template.
Index: testsuite/gcc.dg/vect/section-anchors-vect-69.c
===
--- testsuite/gcc.dg/vect/section-anchors-vect-69.c (revision 221274)
+++ testsuite/gcc.dg/vect/section-anchors-vect-69.c (working copy)
@@ -115,6 +115,6 @@ int main (void)
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0
"vect" } } */
/* Alignment forced using versioning until the pass that increases alignment
is extended to handle structs. */
-/* { dg-final { scan-tree-dump-times "Alignment of access forced using
peeling" 4 "vect" { target {vect_int && vector_alignment_reachable } } } } */
+/* { dg-final { scan-tree-dump-times "Alignment of access forced using
peeling" 2 "vect" { target {vect_int && vector_alignment_reachable } } } } */
/* { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning" 4 "vect" { target {vect_int && {! vector_alignment_reachable} } } }
} */
/* { dg-final { cleanup-tree-dump "vect" } } */
Index: varasm.c
===
--- varasm.c(revision 221269)
+++ varasm.c(working copy)
@@ -1630,35 +1630,30 @@ default_ctor_section_asm_out_constructor
void
notice_global_symbol (tree decl)
{
- const char **type = &first_global_object_name;
+ const char **t = &first_global_object_name;
if (first_global_object_name
|| !TREE_PUBLIC (decl)
|| DECL_EXTERNAL (decl)
|| !DECL_NAME (decl)
+ || (TREE_CODE (decl) == VAR_DECL && DECL_HARD_REGISTER (decl))
|| (TREE_CODE (decl) != FUNCTION_DECL
&& (TREE_CODE (decl) != VAR_DECL
|| (DECL_COMMON (decl)
&& (DECL_INITIAL (decl) == 0
- || DECL_INITIAL (decl) == error_mark_node
- || !MEM_P (DECL_RTL (decl)))
+ || DECL_INITIAL (decl) == error_mark_node)
return;
/* We win when global object is found, but it is useful to know about weak
symbol as well so we can produce nicer unique names. */
if (DECL_WEAK (decl) || DECL_ONE_ONLY (decl) || flag_shlib)
-type = &weak_global_object_name;
+t = &weak_global_object_name;
- if (!*type)
+ if (!*t)
{
- const char *p;
- const char *name;
- rtx decl_rtl = DECL_RTL (decl);
-
- p = targetm.strip_name_encoding (XSTR (XEXP (decl_rtl, 0), 0));
- name = ggc_strdup (p);
-
- *type = name;
+ tree id = DECL_ASSEMBLER_NAME (decl);
+ ultimate_transparent_alias_target (&id);
+ *t = ggc_strdup (targetm.strip_name_encoding (IDENTIFIER_POINTER (id)));
}
}
Index: symtab.c
===
--- symtab.c(revision 221268)
+++ symtab.c(working copy)
@@ -1924,6 +1924,13 @@ symtab_node::can_increase_alignment_p (v
if (TREE_ASM_WRITTEN (target->decl))
return false;
+ /* If target is already placed in an anchor, we can not touch its
+ alignment. */
+ if (DECL_RTL_SET_P (target->decl)
+ && MEM_P (DECL_RTL (target->decl))
+ && SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (DECL_RTL (target->decl), 0)))
+return false;
+
/* Constant pool entries may be shared. */
if (DECL_IN_CONSTANT_POOL (target->decl))
return false;
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 221268)
+++ tree-vect-data-refs.c (working copy)
@@ -758,12 +758,7 @@ vect_compute_data_ref_alignment (struct
&& TREE_CODE (TREE_OPERAND (base, 0)) == ADDR_EXPR)
base = TREE_OPERAND (TREE_OPERAND (base, 0), 0);
- /* Do not change the alignment of global variables here if
-flag_section_anchors is enabled as we already generated
-RTL for other functions. Most global variables should
-have been aligned during the IPA increase_alignment pass. */
- if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype))
- || (TREE_STATIC (base) && flag_section_anchors))
+ if
Speedup inliner on Chromium
Hi,
compiling Chromium, ipa-icf introduces thousdands of aliases of one function
from iostream traits (because it is duplicated so many times due to ipa-sra
privatizing it to every compile unit).
This triggers non-linear behaviour in
will_be_removed_from_program_if_no_direct_calls_p. This patch makes inliner to
not call it that often. I also noticed that the function is not quite corect
about inlining and fixed it.
Bootstrapped/regtested x86_64-linux, will commit it later today.
Honza
* ipa-inline-analysis.c (check_callers): Check
node->can_remove_if_no_direct_calls_and_refs_p.
(growth_likely_positive): Reorganize to call
can_remove_if_no_direct_calls_p later.
* cgraph.h (will_be_removed_from_program_if_no_direct_calls_p,
will_be_removed_from_program_if_no_direct_calls_p): Add
will_inline parameter.
* cgraph.c (cgraph_node::can_remove_if_no_direct_calls_p,
cgraph_node::will_be_removed_from_program_if_no_direct_calls_p):
Handle inliner case correctly.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 221267)
+++ ipa-inline-analysis.c (working copy)
@@ -3978,6 +3978,9 @@ check_callers (cgraph_node *node, int *m
{
ipa_ref *ref;
+ if (!node->can_remove_if_no_direct_calls_and_refs_p ())
+return true;
+
for (cgraph_edge *e = node->callers; e; e = e->next_caller)
{
(*max_callers)--;
@@ -4007,23 +4010,13 @@ growth_likely_positive (struct cgraph_no
struct cgraph_edge *e;
gcc_checking_assert (edge_growth > 0);
+ /* First quickly check if NODE is removable at all. */
if (DECL_EXTERNAL (node->decl))
return true;
- /* Unlike for functions called once, we play unsafe with
- COMDATs. We can allow that since we know functions
- in consideration are small (and thus risk is small) and
- moreover grow estimates already accounts that COMDAT
- functions may or may not disappear when eliminated from
- current unit. With good probability making aggressive
- choice in all units is going to make overall program
- smaller. */
- if (DECL_COMDAT (node->decl))
-{
- if (!node->can_remove_if_no_direct_calls_p ())
- return true;
-}
- else if (!node->will_be_removed_from_program_if_no_direct_calls_p ())
+ if (!node->can_remove_if_no_direct_calls_and_refs_p ()
+ || node->address_taken)
return true;
+
max_callers = inline_summaries->get (node)->size * 4 / edge_growth + 2;
for (e = node->callers; e; e = e->next_caller)
@@ -4039,6 +4032,22 @@ growth_likely_positive (struct cgraph_no
if (check_callers (dyn_cast (ref->referring),
&max_callers))
return true;
+ /* Unlike for functions called once, we play unsafe with
+ COMDATs. We can allow that since we know functions
+ in consideration are small (and thus risk is small) and
+ moreover grow estimates already accounts that COMDAT
+ functions may or may not disappear when eliminated from
+ current unit. With good probability making aggressive
+ choice in all units is going to make overall program
+ smaller. */
+ if (DECL_COMDAT (node->decl))
+{
+ if (!node->can_remove_if_no_direct_calls_p ())
+ return true;
+}
+ else if (!node->will_be_removed_from_program_if_no_direct_calls_p ())
+return true;
+
return estimate_growth (node) > 0;
}
Index: cgraph.h
===
--- cgraph.h(revision 221268)
+++ cgraph.h(working copy)
@@ -1110,16 +1110,23 @@ public:
all uses of COMDAT function does not make it necessarily disappear from
the program unless we are compiling whole program or we do LTO. In this
case we know we win since dynamic linking will not really discard the
- linkonce section. */
- bool will_be_removed_from_program_if_no_direct_calls_p (void);
+ linkonce section.
+
+ If WILL_INLINE is true, assume that function will be inlined into all the
+ direct calls. */
+ bool will_be_removed_from_program_if_no_direct_calls_p
+(bool will_inline = false);
/* Return true when function can be removed from callgraph
- if all direct calls are eliminated. */
+ if all direct calls and references are eliminated. The function does
+ not take into account comdat groups. */
bool can_remove_if_no_direct_calls_and_refs_p (void);
/* Return true when function cgraph_node and its aliases can be removed from
- callgraph if all direct calls are eliminated. */
- bool can_remove_if_no_direct_calls_p (void);
+ callgraph if all direct calls are eliminated.
+ If WILL_INLINE is true, assume that function will be inlined into all the
+ direct calls. */
+ bool can_remove_if_no_direct_calls_p (bool will_inline = false);
/* Return true when callgraph node is a function with Gimple body defined
in curr
