Re: parallel check output changes?
On Oct 4, 2014, at 3:32 AM, Richard Sandiford wrote: > we should just fix those tests so that the name is unique. Yes. This is good in all sorts of ways.
[Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
Hi
I just committed this trivial bug fix.
Shall I go ahead and apply it to 4.9 branch too ?
2014-10-05 François Dumont
PR libstdc++/63456
* include/bits/hashtable.h (_M_uses_single_bucket(__bucket_type*)):
Test
the parameter.
* testsuite/23_containers/unordered_set/63456.cc: New.
François
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h (revision 215902)
+++ include/bits/hashtable.h (working copy)
@@ -326,7 +326,7 @@
bool
_M_uses_single_bucket(__bucket_type* __bkts) const
- { return __builtin_expect(_M_buckets == &_M_single_bucket, false); }
+ { return __builtin_expect(__bkts == &_M_single_bucket, false); }
bool
_M_uses_single_bucket() const
Index: testsuite/23_containers/unordered_set/63456.cc
===
--- testsuite/23_containers/unordered_set/63456.cc (revision 0)
+++ testsuite/23_containers/unordered_set/63456.cc (working copy)
@@ -0,0 +1,36 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
On 5 October 2014 19:50, François Dumont wrote: > Hi > > I just committed this trivial bug fix. > > Shall I go ahead and apply it to 4.9 branch too ? Yes please.
Re: [Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
Hi, On 10/05/2014 08:50 PM, François Dumont wrote: +#include Seems redundant. Thanks! Paolo.
Re: [Bug libstdc++/63456] unordered_map incorrectly frees _M_single_bucket. Patch Included
On 05/10/2014 21:37, Paolo Carlini wrote: Hi, On 10/05/2014 08:50 PM, François Dumont wrote: +#include Seems redundant. Thanks! Paolo. Yes it is and in fact I had remove it before the real commit, I should have update the patch. François
[patch, libgfortran] PR63460 namelist read from STDIN
Committed as obvious. Missed it on my earlier patch. 2014-10-05 Jerry DeLisle PR libgfortran/63460 * io/unit.c (init_units): Initialize the DELIM flag to UNSPECIFIED for the STDIN unit so that the flag is correctly set later. r215908 Index: unit.c === --- unit.c (revision 215870) +++ unit.c (working copy) @@ -580,6 +580,7 @@ init_units (void) u->flags.position = POSITION_ASIS; u->flags.sign = SIGN_SUPPRESS; u->flags.decimal = DECIMAL_POINT; + u->flags.delim = DECIMAL_UNSPECIFIED; u->flags.encoding = ENCODING_DEFAULT; u->flags.async = ASYNC_NO; u->flags.round = ROUND_UNSPECIFIED;
Allow [[deprecated]] even for C++11 (with pedwarn)
Greetings,
There was some feeling that not allowing [[deprecated]] for C++ was a
little extreme.
This patch builds and tests clean on x86_64-linux. OK?
Ed
gcc/c-family:
2014-10-06 Edward Smith-Rowland <3dw...@verizon.net>
* c-family/c-cppbuiltin.c: Move __cpp_attribute_deprecated to the
C++11 section.
gcc/cp:
2014-10-06 Edward Smith-Rowland <3dw...@verizon.net>
* cp/parser.c: Allow [[deprecated]] for C++11. Issue a pedwarn.
gcc/testsuite:
2014-10-06 Edward Smith-Rowland <3dw...@verizon.net>
* g++.dg/cpp1y/attr-deprecated-neg.C: Attribute no longer ignored.
* g++.dg/cpp1y/feat-cxx11-neg.C: Comment out __cpp_attribute_deprecated
test.
* g++.dg/cpp1y/feat-cxx11.C: Add __cpp_attribute_deprecated test.
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 215826)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -828,6 +828,7 @@
cpp_define (pfile, "__cpp_rvalue_reference=200610");
cpp_define (pfile, "__cpp_variadic_templates=200704");
cpp_define (pfile, "__cpp_alias_templates=200704");
+ cpp_define (pfile, "__cpp_attribute_deprecated=201309");
}
if (cxx_dialect > cxx11)
{
@@ -841,7 +842,6 @@
//cpp_define (pfile, "__cpp_aggregate_nsdmi=201304");
cpp_define (pfile, "__cpp_variable_templates=201304");
cpp_define (pfile, "__cpp_digit_separators=201309");
- cpp_define (pfile, "__cpp_attribute_deprecated=201309");
//cpp_define (pfile, "__cpp_sized_deallocation=201309");
/* We'll have to see where runtime arrays wind up.
Let's put it in C++14 for now. */
Index: cp/parser.c
===
--- cp/parser.c (revision 215826)
+++ cp/parser.c (working copy)
@@ -22211,8 +22211,14 @@
if (is_attribute_p ("noreturn", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
/* C++14 deprecated attribute is equivalent to GNU's. */
- else if (cxx_dialect >= cxx14 && is_attribute_p ("deprecated", attr_id))
- TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+ else if (cxx_dialect >= cxx11 && is_attribute_p ("deprecated", attr_id))
+ {
+ if (cxx_dialect == cxx11)
+ pedwarn (token->location, OPT_Wpedantic,
+"% is a C++14 feature;"
+" use %");
+ TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
+ }
}
/* Now parse the optional argument clause of the attribute. */
Index: testsuite/g++.dg/cpp1y/attr-deprecated-neg.C
===
--- testsuite/g++.dg/cpp1y/attr-deprecated-neg.C(revision 215826)
+++ testsuite/g++.dg/cpp1y/attr-deprecated-neg.C(working copy)
@@ -1,23 +1,24 @@
// { dg-do compile { target c++11_only } }
+// { dg-options "-pedantic" }
-class [[deprecated]] A // { dg-warning "attribute directive ignored" }
+class [[deprecated]] A // { dg-warning "'deprecated' is a C..14 feature" }
{
};
-[[deprecated]]
+[[deprecated]] // { dg-warning "'deprecated' is a C..14 feature" }
int
-foo(int n) // { dg-warning "attribute directive ignored" }
+foo(int n)
{
return 42 + n;
}
-class [[deprecated("B has been superceded by C")]] B // { dg-warning
"attribute directive ignored" }
+class [[deprecated("B has been superceded by C")]] B // { dg-warning
"'deprecated' is a C..14 feature" }
{
};
-[[deprecated("bar is unsafe; use foobar instead")]]
+[[deprecated("bar is unsafe; use foobar instead")]] // { dg-warning
"'deprecated' is a C..14 feature" }
int
-bar(int n) // { dg-warning "attribute directive ignored" }
+bar(int n)
{
return 42 + n - 1;
}
@@ -47,12 +48,12 @@
int
main()
{
- A aaa;
- int n = foo(12);
+ A aaa; // { dg-warning "is deprecated" }
+ int n = foo(12); // { dg-warning "is deprecated" }
- B bbb;
- int m = bar(666);
+ B bbb; // { dg-warning "is deprecated" }
+ int m = bar(666); // { dg-warning "is deprecated" }
- C ccc;
- int l = foobar(8);
+ C ccc; // { dg-warning "is deprecated" "" { target { c++14 } } }
+ int l = foobar(8); // { dg-warning "is deprecated" "" { target { c++14 } } }
}
Index: testsuite/g++.dg/cpp1y/feat-cxx11-neg.C
===
--- testsuite/g++.dg/cpp1y/feat-cxx11-neg.C (revision 215826)
+++ testsuite/g++.dg/cpp1y/feat-cxx11-neg.C (working copy)
@@ -31,9 +31,10 @@
# error "__cpp_digit_separators" // { dg-error "error" }
#endif
-#ifndef __cpp_attribute_deprecated
-# error "__cpp_attribute_deprecated" // { dg-error "error" }
-#endif
+// Attribute [[deprecated]] is allowed in C++11 as an extension (with
pedwarn).
+//#ifndef __cpp_attribute_deprecated
+//# error "__cpp_attribute_deprecated"
+//#endif
#ifndef __cpp_run
[PATCH, rs6000] Document issues with permutes for analyze_swaps
Hi,
I spent some time thinking about handling vperm instructions in the
analyze_swaps pass, and convinced myself that it isn't necessarily wise
to do so. At the least it will require adding a cost model to the pass
to determine whether a computation involving permutes should be
optimized.
At this time I don't intend to implement this, but I want to record the
information about how it could be done should it be deemed necessary.
So this patch just adds a few paragraphs of documentation about the
issue. No change in behavior intended.
I've ensured that rs6000.c still compiles successfully on
powerpc64le-unknown-linux-gnu. Is this ok for trunk?
Thanks,
Bill
2014-10-05 Bill Schmidt
* config/rs6000/rs6000.c (analyze_swaps commentary): Add
discussion of permutes and why we don't handle them.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 215907)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -33431,6 +33431,53 @@ emit_fusion_gpr_load (rtx target, rtx mem)
than deleting a swap, we convert the load/store into a permuting
load/store (which effectively removes the swap). */
+/* Notes on Permutes
+
+ We do not currently handle computations that contain permutes. There
+ is a general transformation that can be performed correctly, but it
+ may introduce more expensive code than it replaces. To handle these
+ would require a cost model to determine when to perform the optimization.
+ This commentary records how this could be done if desired.
+
+ The most general permute is something like this (example for V16QI):
+
+ (vec_select:V16QI (vec_concat:V32QI (op1:V16QI) (op2:V16QI))
+ (parallel [(const_int a0) (const_int a1)
+ ...
+(const_int a14) (const_int a15)]))
+
+ where a0,...,a15 are in [0,31] and select elements from op1 and op2
+ to produce in the result.
+
+ Regardless of mode, we can convert the PARALLEL to a mask of 16
+ byte-element selectors. Let's call this M, with M[i] representing
+ the ith byte-element selector value. Then if we swap doublewords
+ throughout the computation, we can get correct behavior by replacing
+ M with M' as follows:
+
+{ M[i+8]+8 : i < 8, M[i+8] in [0,7] U [16,23]
+M'[i] = { M[i+8]-8 : i < 8, M[i+8] in [8,15] U [24,31]
+{ M[i-8]+8 : i >= 8, M[i-8] in [0,7] U [16,23]
+{ M[i-8]-8 : i >= 8, M[i-8] in [8,15] U [24,31]
+
+ This seems promising at first, since we are just replacing one mask
+ with another. But certain masks are preferable to others. If M
+ is a mask that matches a vmrghh pattern, for example, M' certainly
+ will not. Instead of a single vmrghh, we would generate a load of
+ M' and a vperm. So we would need to know how many xxswapd's we can
+ remove as a result of this transformation to determine if it's
+ profitable; and preferably the logic would need to be aware of all
+ the special preferable masks.
+
+ Another form of permute is an UNSPEC_VPERM, in which the mask is
+ already in a register. In some cases, this mask may be a constant
+ that we can discover with ud-chains, in which case the above
+ transformation is ok. However, the common usage here is for the
+ mask to be produced by an UNSPEC_LVSL, in which case the mask
+ cannot be known at compile time. In such a case we would have to
+ generate several instructions to compute M' as above at run time,
+ and a cost model is needed again. */
+
/* This is based on the union-find logic in web.c. web_entry_base is
defined in df.h. */
class swap_web_entry : public web_entry_base
Re: Allow [[deprecated]] even for C++11 (with pedwarn)
OK, thanks. Jason
Re: [PATCH, rs6000] Remove splat calls with out-of-range arguments from gcc.dg/vmx/ops.c
By the way, just to follow up on a conversation we had offline: I did a little poking, and found that the assembler objects if any of these out-of-range arguments to vspltb, etc., survive the compiler: /tmp/cctyppYZ.s: Assembler messages: /tmp/cctyppYZ.s:25: Error: operand out of range (-1 is not between 0 and 3) So if the test had been written with dg-do assemble instead of dg-do compile, we would have found the issue long ago. Anyway, I was looking into adding error checking for this in the compiler, but now that seems redundant. Thanks, Bill On Mon, 2014-09-29 at 13:44 -0400, David Edelsohn wrote: > On Mon, Sep 29, 2014 at 1:27 PM, Bill Schmidt > wrote: > > Hi, > > > > While working on another patch, I observed that the test case > > gcc.dg/vmx/ops.c contains numerous calls to vec_splat and friends for > > which the second argument (the element selector) is out of range. At > > best these calls are invalid; as it is, we generate insns that can cause > > trouble during optimization. (In the case I saw, simplify-rtx tried to > > reduce the splat of its input at compile time, but the out-of-range > > element selector caused it to report a bad insn and abort.) This patch > > removes all of the calls with out-of-range element selectors from the > > test case. > > > > Tested on powerpc64le-unknown-linux-gnu. Ok to commit? > > > > Thanks, > > Bill > > > > > > 2014-09-29 Bill Schmidt > > > > * gcc.dg/vmx/ops.c: Remove calls to vec_splat, vec_vsplth, > > vec_vspltw, and vec_vspltb for which the second argument is out of > > range. > > Okay. > > Thanks, David >
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/5/14 11:32, Chen Gang wrote: > On 10/5/14 11:15, Chen Gang wrote: >> On 9/25/14 8:12, Chen Gang wrote: >>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on >>> Qemu, and try to make patches for it). >>> >>> And, I also need finish the testsuite under Darwin x86_64, next month for >>> gcc. >> >> I finish tried testsuit under Darwin x86_64, originally, I incorrectly >> installed mpc: need "brew install libmpc", not "brew install mpc", and >> also need "brew link libmpc" which I missed. >> >> At present, except for libjave Throw_2.exe test, I guess all others are >> OK, please help check the result below, thanks. >> > > Oh, sorry, I forgot to mention 2 things: > > - config with "--disable-multilibs", and I shall try normal configiure >again (although I guess, it will also be OK), hope I can finish >within 2 days. > > - And during test libjava, it will quit with error because of Throw_2, >so I modified the related Makefile to skip it. > After try normal configure, get almost the same result, I guess, our testsuite under Darwin x86_64 is OK. If no any additional reply within a week, I shall continue to try to analyze the libjava Throw_2 issue. Thanks. > >> If it passes checking, next, I shall try to fix libjava Throw_2 issue >> within this month (others, include Throw_1 and Throw_3 are all OK). >> >> === g++ Summary === >> >> # of expected passes 82961 >> # of unexpected failures 891 >> # of expected failures 255 >> # of unresolved testcases272 >> # of unsupported tests 3421 >> >> === gcc Summary === >> >> # of expected passes 85011 >> # of unexpected failures 30 >> # of expected failures 182 >> # of unresolved testcases10 >> # of unsupported tests 2796 >> >> === gfortran Summary === >> >> # of expected passes 46354 >> # of unexpected failures 1 >> # of expected failures 38 >> # of unsupported tests 74 >> >> === gnat Summary === >> >> # of expected passes 799 >> # of unexpected failures 67 >> # of unexpected successes18 >> # of unresolved testcases382 >> # of unsupported tests 8 >> >> === objc Summary === >> >> # of expected passes 5828 >> # of unexpected failures 4 >> # of expected failures 6 >> # of unsupported tests 77 >> >> === boehm-gc Summary === >> >> # of expected passes 12 >> # of unsupported tests 1 >> >> === libatomic Summary === >> >> # of expected passes 54 >> >> === libffi Summary === >> >> # of expected passes 1819 >> # of unsupported tests 55 >> >> === libgomp Summary === >> >> # of expected passes 3194 >> # of unsupported tests 38 >> >> === libitm Summary === >> >> # of expected passes 26 >> # of expected failures 3 >> # of unsupported tests 1 >> >> === libjava Summary === >> >> # of expected passes 2574 >> # of unexpected failures 4 /* The 4 issues are all related with >> Throw_2.exe */ >> # of expected failures 4 >> # of untested testcases 4 >> >> === libstdc++ Summary === >> >> # of expected passes 8956 >> # of unexpected failures 159 >> # of expected failures 69 >> # of unresolved testcases38 >> # of unsupported tests 670 >> >> >> Thanks. >> > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [gofrontend-dev] [PATCH 4/9] Gccgo port to s390[x] -- part I
On Fri, Oct 03, 2014 at 06:19:46PM -0700, Ian Lance Taylor wrote: > On Tue, Sep 9, 2014 at 5:53 AM, Dominik Vogt wrote: > > This patch fixes the compiler flags in libgo/mksysinfo.sh. In one > > place, some compiler flags were missing that are consistently used > > elswhere, resulting in an error message. > > > > ChangeLog > > 2014-09-05 Dominik Vogt > > > > * libgo/mksysinfo.sh (OUT): > > Add the same compile flags that configure uses to detect whether > > off64_t > > is present or not when generating the go structures for the C types. > > Otherwise the go type for off64_t may not be generated. > > I don't understand why this patch is necessary. The invocation of > mksysinfo in libgo/Makefile.am sets the CC environment variable to > include $(OSCFLAGS), and OSCFLAGS should include those three options. > > Trying to list the flags separately in mksysinfo.sh is going to be > incomplete on some systems--see OSCFLAGS in libgo/configure.ac. With gcc-4.8 compilation failed on s390 (i.e. 31 bit) without it. It seems that this patch is no longer necessary with gcc-5.0, so it can be dropped. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c
Alan Lawrence writes:
> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> new file mode 100644
> index
> ..90e64fd10dc358f10ad03a90041605bc3ccb7011
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile {target sparc64*-*-* aarch64*-*-* x86_64-*-*
> powerpc64*-*-*} } */
You should check for lp64 instead of matching 64 in target names, to
reject -m32.
> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> b/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> new file mode 100644
> index
> ..fd6827caed230ea5dd2d6ec4431b11bf826531ea
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile {target arm*-*-* i?86-*-* powerpc-*-* sparc-*-*} } */
Likewise, using ilp32 to reject -m64.
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."
Re: [RFC] costs and it's use in assign_reg_parm
Ramana Radhakrishnan writes:
> Hi,
>
> I've been digging into why on AArch64 we generate pretty bad code
> for the following testcase.
>
> void g2(float, float, float, float, float, float, float, float);
>
> void f2a(void)
> {
> float x0 = 1.0, x1 = 2.0, x2 = 3.0, x3 = 4.0, x4 = 5.0, x5 = 6.0, x6
> = 7.0, x7 = 8.0;
> float x8 = 0.5, x9 = 1.5, x10 = 2.5, x11 = 0.25, x12 = 0.125, x13 =
> 3.5, x14 = 0.75, x15 = 1.25;
>
> g2(x0, x1, x2, x3, x4, x5, x6, x7);
> g2(x8, x9, x10, x11, x12, x13, x14, x15);
> g2(x0, x1, x2, x3, x4, x5, x6, x7);
> g2(x8, x9, x10, x11, x12, x13, x14, x15);
> }
>
> And a couple of items caught my attention.
>
> For one the backend doesn't set the costs of a reg-reg move to be the
> same as a reg-const move. In the AArch64 backend the approach appears to
> be in line with the documentation which is to set the costs of various
> instructions relative to a fast integer instruction. The hack to
> aarch64.c in the attached patch is for setting the cost properly for a
> reg-reg move of the appropriate mode and is only for demonstration
> purposes. I expect this to be replaced by an equivalent bit of code in
> the backend to achieve the same thing.
>
> However the code in precompute_register_parameters assumes that the
> value is forced into a register if the set_src_cost of a constant is >
> COSTS_N_INSNS(1). Now this appears to be checking the cost of a set of
> an FP immediate constant to a register and the backend not unreasonably
> sets it to an appropriate cost. Now to assume that this number should
> always be less than 1 is really not appropriate.
>
> The same can be achieved with removing the fpconst case in
> aarch64.c:rtx_costs but ...
>
> Instead of putting in what's effectively a lie in the backend, should we
> just be moving the midend to a world where all such numbers are compared
> to costs from the backend rather than relying on magic numbers.
Just to throw out what I said in a private conversation in case anyone
else feels the same way...
I think this is really a bug in the backend. The backend is assigning a
cost of COSTS_N_INSNS (3) to a floating-point constant not because the
constant itself is expensive -- it's actually as cheap as a register
in this context -- but because the backend considers floating-point
moves to be 3 times more expensive than cheap integer moves.
The calls.c code is written the way it is because of:
switch (code)
{
case REG:
return 0;
in rtx_costs. This cannot be overridden “by design” (not saying that
it's a good design). So the backend is creating a situation where
the cost of an SFmode CONST_DOUBLE SET_SRC is COSTS_N_INSNS (3) more
expensive than an SFmode REG SET_SRC, whereas they actually have the
same cost. And in Ramana's case we want them to have the same cost.
So I think the backend is just providing misleading information here.
That's what's leading calls.c to think that the constant is a lot
more expensive than a register. It's not asking for the cost of
an operation. It's asking for the cost of one rvalue object compared
to the cost of a register. And when the cost of a register is pegged
at zero, it's reasonable to assume that a constant that comes back as
COSTS_N_INSNS (3) is much more espensive than a register.
lower-subreg.c uses the cost of (set ...) rtxes to calculate the cost
of a single move in a wide mode vs. the cost of multiple moves in
smaller modes. IMO this is consistent with counting the cost of an
addition against the (plus ...) rtx, rather than against the operands
of the plus. So the backend can use the SET costs to say that an SFmode
move is 3 times more expensive than an SImode move. But once it's done
that, it shouldn't also say that a CONST_DOUBLE with outer code SET
is COSTS_N_INSNS (3), since that would be double-counting. It can still
use COSTS_N_INSNS (3) in situations that don't allow constants, such as
outer code DIV (or probably just outer code != SET) since in that case
we are calculating the cost of a division plus a separate move.
I agree it would good in principle to completely overhaul the way
costs are calculated, but that discussion has been had several times
and it's not likely anyone will find time to do it. But while we
keep the scheme that a REG has cost 0, anything that is as cheap
as a register in a given context (decided by outer code) should
have cost 0 too.
FWIW, this is what the MIPS backend does. It seemed to work well
in practice and I think it's consistent with the current cost model
(although I know others disagree :-))
Thanks,
Richard
Re: [patch] Add -static-libquadmath option
Hi FX,
On 4 Oct 2014, at 14:51, FX wrote:
> We have a -static-libgfortran option, but on targets where we support
> quad-prec math through libquadmath, we didn’t have an equivalent
> -static-libquadmath so far. This patch adds it, in what I think is a rather
> straightforward manner.
>
> The only minor complication comes from the fact that previously, linking
> libquadmath was conditionally through libgfortran.spec. So the spec was
> modified: when we use -static-libquadmath, the driver itself includes the
> -lquadmath (surrounded by the necessary static linking directives), so that
> libgfortran.spec shouldn’t do it again.
>
> Bootstrapped and regtested on x86_64 linux. OK to commit?
If one gives -static-libquadmath on darwin (or presumably any other platform
that doesn't support Bstatic/dynamic) then this now breaks linking because the
libgfortran.spec then suppresses the addition of "-lquadmath".
Two possible solutions:
1. don't use -static-libquadmath on darwin ;) ..
2. make it work for darwin and other platforms without Bstatic/dynamic by
using spec substitution (as we do with other -static- cases).
To do this the library to be substituted needs to appear in "outfiles" (I
wonder if one day someone will find time to write a driver substitution method
for libraries, the need for them to appear in "outfiles" is odd and
inconvenient).
* Patch modifications to achieve this below
* You might also want to double-check for trailing spaces on a couple of lines.
* If you want the (relevant parts of the) test-suite to work with
"-static-libquadmath" and spec substitution, then the driver .exp files need to
append a -B path/to/libquadmath - if they don't do this already.
---
I tested that the patch mods below DTRT on x86-64-apple-darwin12 (10.8.5) with
otool -Lv showing that the referenced lib is no longer present with
-static-libquadmath.
NOTE: on darwin I think it is wise to force static runtimes *any* time that
-static-libgcc is given. Otherwise, you can have a situation where part of the
executable is refering to state in libgcc (static) but the runtimes are
refering to state in libgcc_s. This can really mess up TLS emulation and/or
unwinding (on earlier darwin versions).
cheers
Iain
Part 1 - does the spec substitution.
Part 2 - We note the -static-libquadmath for all platforms.
- for Bstatic/dysnamic, we use this
- for others we push "-lquadmath" so that it will be found by the
%replace-outfile() spec substitution.
the rest as per your patch.
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 059da35..205afad 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -229,6 +229,7 @@ extern GTY(()) int darwin_ms_struct;
%:replace-outfile(-lobjc libobjc-gnu.a%s); \
:%:replace-outfile(-lobjc -lobjc-gnu ) } }\
%{static|static-libgcc|static-libgfortran:%:replace-outfile(-lgfortran
libgfortran.a%s)}\
+ %{static|static-libgcc|static-libquadmath:%:replace-outfile(-lquadmath
libquadmath.a%s)}\
%{static|static-libgcc|static-libstdc++|static-libgfortran:%:replace-outfile(-lgomp
libgomp.a%s)}\
%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++
libstdc++.a%s)}\
%{!Zdynamiclib: \
===
diff --git a/gcc/fortran/gfortranspec.c b/gcc/fortran/gfortranspec.c
index 9d27698..8b9db22 100644
--- a/gcc/fortran/gfortranspec.c
+++ b/gcc/fortran/gfortranspec.c
@@ -61,6 +61,10 @@ along with GCC; see the file COPYING3. If not see
#define FORTRAN_LIBRARY "gfortran"
#endif
+#ifndef QUADMATH_LIBRARY
+#define QUADMATH_LIBRARY "quadmath"
+#endif
+
/* Name of the spec file. */
#define SPEC_FILE "libgfortran.spec"
@@ -160,19 +164,28 @@ append_option (size_t opt_index, const char *arg, int
value)
}
/* Append a libgfortran argument to the list being built. If
- FORCE_STATIC, ensure the library is linked statically. */
+ FORCE_STATIC, ensure the library is linked statically. If
+ FORCE_STATIC_LIBQUADMATH, also link the quadmath library statically. */
static void
-add_arg_libgfortran (bool force_static ATTRIBUTE_UNUSED)
+add_arg_libgfortran (bool force_static ATTRIBUTE_UNUSED,
+bool force_static_libquadmath ATTRIBUTE_UNUSED)
{
#ifdef HAVE_LD_STATIC_DYNAMIC
if (force_static)
append_option (OPT_Wl_, LD_STATIC_OPTION, 1);
#endif
+
append_option (OPT_l, FORTRAN_LIBRARY, 1);
+
#ifdef HAVE_LD_STATIC_DYNAMIC
+ if (force_static_libquadmath)
+append_option (OPT_l, QUADMATH_LIBRARY, 1);
if (force_static)
append_option (OPT_Wl_, LD_DYNAMIC_OPTION, 1);
+#else
+ if (force_static_libquadmath)
+append_option (OPT_l, QUADMATH_LIBRARY, 1);
#endif
}
@@ -198,8 +211,9 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
/* By default, we throw on the math library if we have one. */
int need_math = (MATH_LIBRARY[0] != '\0');
- /* Whether we should link a static libgfortran. */
- int static_lib = 0;
+
[C PATCH] Use error_operand_p more
It occured to me that we should probably use error_operand_p
in the C FE where appropriate. Following change is meant only
as a little cleanup.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-10-04 Marek Polacek
* c-convert.c (convert): Use error_operand_p.
* c-typeck.c (require_complete_type): Likewise.
(really_atomic_lvalue): Likewise.
(digest_init): Likewise.
(handle_omp_array_sections_1): Likewise.
diff --git gcc/c/c-convert.c gcc/c/c-convert.c
index 38bacda..95be453 100644
--- gcc/c/c-convert.c
+++ gcc/c/c-convert.c
@@ -72,8 +72,7 @@ convert (tree type, tree expr)
location_t loc = EXPR_LOCATION (expr);
if (type == error_mark_node
- || expr == error_mark_node
- || TREE_TYPE (expr) == error_mark_node)
+ || error_operand_p (expr))
return error_mark_node;
if ((invalid_conv_diag
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index f69c28b..b3b82bb 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -192,7 +192,7 @@ require_complete_type (tree value)
{
tree type = TREE_TYPE (value);
- if (value == error_mark_node || type == error_mark_node)
+ if (error_operand_p (value))
return error_mark_node;
/* First, detect a valid value with a complete type. */
@@ -1950,7 +1950,7 @@ default_function_array_read_conversion (location_t loc,
struct c_expr exp)
static bool
really_atomic_lvalue (tree expr)
{
- if (expr == error_mark_node || TREE_TYPE (expr) == error_mark_node)
+ if (error_operand_p (expr))
return false;
if (!TYPE_ATOMIC (TREE_TYPE (expr)))
return false;
@@ -6492,8 +6492,7 @@ digest_init (location_t init_loc, tree type, tree init,
tree origtype,
if (type == error_mark_node
|| !init
- || init == error_mark_node
- || TREE_TYPE (init) == error_mark_node)
+ || error_operand_p (init))
return error_mark_node;
STRIP_TYPE_NOPS (inside_init);
@@ -11365,7 +11364,7 @@ handle_omp_array_sections_1 (tree c, tree t, vec
&types,
tree ret, low_bound, length, type;
if (TREE_CODE (t) != TREE_LIST)
{
- if (t == error_mark_node || TREE_TYPE (t) == error_mark_node)
+ if (error_operand_p (t))
return error_mark_node;
if (TREE_CODE (t) != VAR_DECL && TREE_CODE (t) != PARM_DECL)
{
Marek
Kushi Aole
You have been approved by Kushi Aole-UK the sum of 85.00 GBP with draw number:22330KHO577345 and Serial number 1509/14. Reply for more details
Track dynamic type changes
Hi,
this patch makes ipa_polymorphic_call_context::get_dynamic_type to
track if vptr has changed in between function entry and polymorphic
call.
The patch also add logic skipping if (a==0) checks in multiple
inheritance so I can construct testcase more easily.
I got my SVN tree into an inconsistent state yesterday by stopping in
middle of commit. The patch went in in two parts, so i am attaching
both changes. Quite few of devirt-4*.C was broken overnight, I apologize
for that.
Honza
* ipa-polymorphic-call.c (walk_ssa_copies): Recognize
NULL pointer checks.
(ipa_polymorphic_call_context::get_dynamic_type): Return true
if type doesn't change.
* cgraph.h (cgraph_indirect_call_info): New flag.
* cgraph.c (cgraph_node::create_indirect_edge): Initialize it.
(cgraph_node::dump): Dump it.
* ipa-prop.c (ipa_analyze_call_uses): Ignore return valud
of context.get_dynamic_type.
(ipa_make_edge_direct_to_target): Do not speculate
edge that is already speuclative.
(try_make_edge_direct_virtual_call): Use VPTR_CHANGED; Do not
speculate to __builtin_unreachable
(ipa_write_indirect_edge_info, ipa_read_indirect_edge_info): Stream
vptr_changed.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Use vptr_changed.
* g++.dg/ipa/devirt-47.C: New testcase.
* ipa-polymorphic-call.c (possible_placement_new): Fix condition
on size.
(ipa_polymorphic_call_context::restrict_to_inner_type): Do not walk
into vptr pointer.
(ipa_polymorphic_call_context::dump): Fix formating.
* ipa-prop.c (ipa_analyze_call_uses): Compute vptr_changed.
* g++.dg/ipa/devirt-42.C: Update template.
* g++.dg/ipa/devirt-44.C: Update template.
* g++.dg/ipa/devirt-45.C: Update template.
* g++.dg/ipa/devirt-46.C: Update template.
* g++.dg/ipa/devirt-47.C: Update template.
* g++.dg/ipa/devirt-48.C: New testcase.
Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c (revision 215890)
+++ ipa-polymorphic-call.c (working copy)
@@ -760,11 +760,37 @@ walk_ssa_copies (tree op)
while (TREE_CODE (op) == SSA_NAME&& !SSA_NAME_IS_DEFAULT_DEF (op)
&& SSA_NAME_DEF_STMT (op)
-&& gimple_assign_single_p (SSA_NAME_DEF_STMT (op)))
+&& (gimple_assign_single_p (SSA_NAME_DEF_STMT (op))
+|| gimple_code (SSA_NAME_DEF_STMT (op)) == GIMPLE_PHI))
{
- if (gimple_assign_load_p (SSA_NAME_DEF_STMT (op)))
- return op;
- op = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (op));
+ /* Special case
+if (ptr == 0)
+ ptr = 0;
+else
+ ptr = ptr.foo;
+This pattern is implicitly produced for casts to non-primary
+bases. When doing context analysis, we do not really care
+about the case pointer is NULL, becuase the call will be
+undefined anyway. */
+ if (gimple_code (SSA_NAME_DEF_STMT (op)) == GIMPLE_PHI)
+ {
+ gimple phi = SSA_NAME_DEF_STMT (op);
+
+ if (gimple_phi_num_args (phi) != 2)
+ return op;
+ if (integer_zerop (gimple_phi_arg_def (phi, 0)))
+ op = gimple_phi_arg_def (phi, 1);
+ else if (integer_zerop (gimple_phi_arg_def (phi, 1)))
+ op = gimple_phi_arg_def (phi, 0);
+ else
+ return op;
+ }
+ else
+ {
+ if (gimple_assign_load_p (SSA_NAME_DEF_STMT (op)))
+ return op;
+ op = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (op));
+ }
STRIP_NOPS (op);
}
return op;
@@ -1371,6 +1397,8 @@ check_stmt_for_type_change (ao_ref *ao A
is set), try to walk memory writes and find the actual construction of the
instance.
+ Return true if memory is unchanged from function entry.
+
We do not include this analysis in the context analysis itself, because
it needs memory SSA to be fully built and the walk may be expensive.
So it is not suitable for use withing fold_stmt and similar uses. */
@@ -1615,7 +1643,7 @@ ipa_polymorphic_call_context::get_dynami
function_entry_reached ? " (multiple types encountered)" : "");
}
- return true;
+ return false;
}
/* See if speculation given by SPEC_OUTER_TYPE, SPEC_OFFSET and
SPEC_MAYBE_DERIVED_TYPE
Index: cgraph.h
===
--- cgraph.h(revision 215890)
+++ cgraph.h(working copy)
@@ -1393,6 +1393,9 @@ struct GTY(()) cgraph_indirect_call_info
/* When the previous bit is set, this one determines whether the destination
is loaded from a parameter passed by reference. */
unsigned by_ref : 1;
+ /* For polymorphic calls this specify whether the virtual table pointer
+ may have changed in between function entry and the call. */
+ unsigned vptr_changed : 1;
};
struct GTY((ch
