Re: libsanitizer merge from upstream r175042
On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
>> The patch seems to work on a simple test. Let me digest it.
>> I am trying to understand if there are problems with it other than the
>> added complexity (which is what I don't like the most).
>
> Yes, it is some added complexity, but not too much, and something that can
> be tested regularly that it works.
The complexity I am afraid of is not only in the code, but also at the
time of execution.
We and our users sometimes have to stare at the /proc/self/maps.
A mapping with 1 (ZeroBase) or 3 (default) asan sections is ok, but
6 extra asan sections becomes nearly incomprehensible, at least for me.
So, how about having kMidMemBeg as a variable, set as __asan_init.
Only if something is mapped around 0x003X we set it to non-zero.
http://llvm-reviews.chandlerc.com/D411 (still needs some cleanup)
Unfortunately, the test does not work if gold is the system linker.
Any suggestion on how to make the test work with either linker?
Thanks,
--kcc
>
>> -Wl,-Ttext-segment=0x36 does not work with binutils-gold.
>> gold understands -Wl,-Ttext=0x36, but bfd ld doesn't.
>> Do you know any flag supported by both?
>
> -Wl,-Ttext is unfortunately something different, at least for
> the bfd linker. -Ttext-segment aligns the base of the whole shared library,
> if you look at start of the linker script for -shared:
> /* Read-only sections, merged into text segment: */
> . = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
> .note.gnu.build-id : { *(.note.gnu.build-id) }
> .hash : { *(.hash) }
> .gnu.hash : { *(.gnu.hash) }
> .dynsym : { *(.dynsym) }
> .dynstr : { *(.dynstr) }
> .gnu.version: { *(.gnu.version) }
> .gnu.version_d : { *(.gnu.version_d) }
> .gnu.version_r : { *(.gnu.version_r) }
> ...
> .rela.plt :
> {
> *(.rela.plt)
> *(.rela.iplt)
> }
> .init :
> {
> KEEP (*(.init))
> }
> .plt: { *(.plt) *(.iplt) }
> .text :
> {
> *(.text.unlikely .text.*_unlikely)
> *(.text.exit .text.exit.*)
> -Ttext-segment chooses the base at which ELF headers will reside.
> -Ttext aligns the .text section's start to that, so most likely the shared
> library won't even link, because .init section will be many GBs appart from
> .text section.
>
> CCing Ian, if gold has any way to do something similar.
> As I said, the alternative is to link the library normally, and run
> prelink -r 0x36 libtest.so on the shared library afterwards if
> prelink is
> installed, and make sure you install it on your linux/x86-64 test boxes.
>
> Jakub
C++ PATCH for c++/52026 (use of enclosing constant var in lambda)
In this testcase, we see a use of a constant variable in a lambda
(though the same thing can happen with a local class member function).
We try to pull out the constant value in finish_id_expression, but
because the initializer isn't a reduced constant yet, that fails and we
end up just returning the variable. At instantiation time tsubst
instantiates the use of the variable by creating a new one in the lambda
context, which is obviously broken. A better solution is to defer
deciding how to handle the variable until instantiation time, at which
point we will know. Since the logic for this is in
finish_id_expression, it's easy to just return the name and look it up
again at that point.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 38e1d69672c4028124637e3b78430f4c45dff6a8
Author: Jason Merrill
Date: Thu Feb 14 22:11:56 2013 -0500
PR c++/52026
* semantics.c (finish_id_expression): In a template, return
the identifier for a constant variable.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 28b4b79..0e09d04 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3015,7 +3015,14 @@ finish_id_expression (tree id_expression,
FIXME update for final resolution of core issue 696. */
if (decl_constant_var_p (decl))
- return integral_constant_value (decl);
+ {
+ if (processing_template_decl)
+ /* In a template, the constant value may not be in a usable
+ form, so look it up again at instantiation time. */
+ return id_expression;
+ else
+ return integral_constant_value (decl);
+ }
/* If we are in a lambda function, we can move out until we hit
1. the context,
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const2.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const2.C
new file mode 100644
index 000..d2457d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const2.C
@@ -0,0 +1,15 @@
+// PR c++/52026
+// { dg-options "-std=c++11 -O" }
+// { dg-do run }
+
+template
+int func() {
+ const int constVal1 = B ? 100 : -100;
+ const int constVal = constVal1;
+ return [] { return constVal; }();
+}
+
+int main() {
+ if (func() != 100)
+__builtin_abort ();
+}
Fix target/55941
During subreg1, we fail to split
(insn 4 3 5 2 (set (reg:TI 63 [ x ])
(const_int 0 [0])) pr55941.c:2 85 {*movti_internal_rex64}
(nil))
which leads to all the rest of the problems described in the PR.
This happens because we read the mode from the CONST_INT, and
unsurprisingly VOIDmode does not match SCALAR_INT_MODE_P. Given that
src and dest mode must match, it's just easier to take the mode from there.
This leads to all of the subregs being split during subreg1, and the
rest of rtl passes clean things up exactly as we like.
r~
PR target/55941
* lower-subreg.c (simple_move): Check dest mode instead of src mode.
diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
index 5bf6cc1..228d3a2 100644
--- a/gcc/lower-subreg.c
+++ b/gcc/lower-subreg.c
@@ -343,7 +343,7 @@ simple_move (rtx insn, bool speed_p)
registers. That means that we can't decompose if this is a
non-integer mode for which there is no integer mode of the same
size. */
- mode = GET_MODE (SET_SRC (set));
+ mode = GET_MODE (SET_DEST (set));
if (!SCALAR_INT_MODE_P (mode)
&& (mode_for_size (GET_MODE_SIZE (mode) * BITS_PER_UNIT, MODE_INT, 0)
== BLKmode))
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
On 02/14/2013 02:16 PM, Paolo Carlini wrote:
... or the below, just in case an interesting system provides the
*quick_exit functions but doesn't define _GLIBCXX_USE_C99.
It seems rather unlikely that the system would provide some C11
functions without the corresponding C99 ones. I'm just going to #if out
the whole test if the relevant functions aren't available:
commit e203f2dcdf077fcf61b4d6b3f8e399c25cc44dfb
Author: Jason Merrill
Date: Thu Feb 14 11:15:28 2013 -0500
* testsuite/18_support/quick_exit/quick_exit.cc: #if out the whole
test if unsupported.
diff --git a/libstdc++-v3/testsuite/18_support/quick_exit/quick_exit.cc b/libstdc++-v3/testsuite/18_support/quick_exit/quick_exit.cc
index 8e55890..b91cbe2 100644
--- a/libstdc++-v3/testsuite/18_support/quick_exit/quick_exit.cc
+++ b/libstdc++-v3/testsuite/18_support/quick_exit/quick_exit.cc
@@ -21,6 +21,7 @@
// 18.5 - Start and termination
+#if defined(_GLIBCXX_HAVE_AT_QUICK_EXIT) && defined(_GLIBCXX_HAVE_QUICK_EXIT)
#include
void handler()
@@ -35,9 +36,10 @@ void wrong_handler()
int main()
{
-#if defined(_GLIBCXX_HAVE_AT_QUICK_EXIT) && defined(_GLIBCXX_HAVE_QUICK_EXIT)
std::at_quick_exit (handler);
std::atexit (wrong_handler);
std::quick_exit (1);
+}
+#else
+int main() {}
#endif
-}
Re: RFC: [MIPS] Add an option to disable ldc1/sdc1
On Thu, Feb 14, 2013 at 5:23 PM, Maciej W. Rozycki wrote: > On Thu, 14 Feb 2013, Richard Sandiford wrote: > >> What about 64-bit targets? We can sometimes access doubles using GPRs, >> so on 64-bit targets we could end up using LD and SD to access a double >> even when this option disables LDC1 and SDC1. I think we'd need to >> patch the move patterns as well. > > As far as Linux is concerned -- which from the context of this > consideration I infer is the case -- there is no issue, because unless an > app has explicitly requested this feature to be disabled, with the use of > the sysmips(2) FIXADE API (which of course hardly any does), all address > error exceptions triggered by an unaligned memory access made with a CPU > instruction are trapped by the kernel and the access emulated. > > However no such accesses are emulated when made with a coprocessor > instruction, whether the FPU or CP2 or the legacy CP1 and CP3 units as > supported by earlier processors. There was once a proposal to emulate FPU > instructions as well, posted on the linux-mips mailing list here: > > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20120615234641.6938B58FE7C%40mail.viric.name > > -- but the MIPS/Linux maintainer rejected the idea. I have cc-ed Ralf on > this reply in case he wanted to add something. I would reject it also. I say just fix the webkit code and forget about these patches to both the GCC and the kernel. Webkit is breaking C/C++ alignment rules anyways so the code is undefined. Just go and fix webkit. There is no reason why webkit can't just be fixed and we can forget about these broken patches to work around broken code. Thanks, Andrew Pinski > > Of course an option to GCC to disable any such instructions may have some > value to some people -- for bare-iron targets if nothing else -- but I > fear this is going to end up with a lot of hassle with 64-bit ABIs or even > just 64-bit FPU (-mabi=32 -mfp64) as individual halves of 64-bit registers > are not addressable in the MIPS architecture (e.g. there's no LWHC1 > instruction), so you'll need to use scratch registers. > > Which is why I think any resources put into this effort would better be > used to clean up such broken code and, perhaps more importantly, to > educate people to write their programs properly in the first place. > Writing portable code is really not a big deal, you just need to remember > all the world is not x86 and apply a few simple rules. > > Maciej
Re: RFC: [MIPS] Add an option to disable ldc1/sdc1
On Thu, 14 Feb 2013, Richard Sandiford wrote: > What about 64-bit targets? We can sometimes access doubles using GPRs, > so on 64-bit targets we could end up using LD and SD to access a double > even when this option disables LDC1 and SDC1. I think we'd need to > patch the move patterns as well. As far as Linux is concerned -- which from the context of this consideration I infer is the case -- there is no issue, because unless an app has explicitly requested this feature to be disabled, with the use of the sysmips(2) FIXADE API (which of course hardly any does), all address error exceptions triggered by an unaligned memory access made with a CPU instruction are trapped by the kernel and the access emulated. However no such accesses are emulated when made with a coprocessor instruction, whether the FPU or CP2 or the legacy CP1 and CP3 units as supported by earlier processors. There was once a proposal to emulate FPU instructions as well, posted on the linux-mips mailing list here: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20120615234641.6938B58FE7C%40mail.viric.name -- but the MIPS/Linux maintainer rejected the idea. I have cc-ed Ralf on this reply in case he wanted to add something. Of course an option to GCC to disable any such instructions may have some value to some people -- for bare-iron targets if nothing else -- but I fear this is going to end up with a lot of hassle with 64-bit ABIs or even just 64-bit FPU (-mabi=32 -mfp64) as individual halves of 64-bit registers are not addressable in the MIPS architecture (e.g. there's no LWHC1 instruction), so you'll need to use scratch registers. Which is why I think any resources put into this effort would better be used to clean up such broken code and, perhaps more importantly, to educate people to write their programs properly in the first place. Writing portable code is really not a big deal, you just need to remember all the world is not x86 and apply a few simple rules. Maciej
C++ PATCH for c++/54922 (constexpr and anonymous union)
When we're building up a CONSTRUCTOR to represent the initialization
done by a constexpr constructor, initialization of a member of an
anonymous union shows up as an assignment to a COMPONENT_REF of the main
class object. We need to turn this into a CONSTRUCTOR for the anonymous
union object itself. This is complicated by the possibility of
arbitrarily nested anonymous unions, and also by anonymous structures
which are not part of C++, but are supported by G++ for C compatibility.
This is a moderately large chunk of code, but it is only hit in cases
that were previously completely broken.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0d4d1658d66493525f78d8cc67a295219ac6925d
Author: paolo
Date: Tue Oct 23 23:43:21 2012 +
PR c++/54922
* semantics.c (build_anon_member_initialization): New.
(build_data_member_initialization): Use it.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 95158a5..28b4b79 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5815,6 +5815,59 @@ is_valid_constexpr_fn (tree fun, bool complain)
return ret;
}
+/* Subroutine of build_data_member_initialization. MEMBER is a COMPONENT_REF
+ for a member of an anonymous aggregate, INIT is the initializer for that
+ member, and VEC_OUTER is the vector of constructor elements for the class
+ whose constructor we are processing. Add the initializer to the vector
+ and return true to indicate success. */
+
+static bool
+build_anon_member_initialization (tree member, tree init,
+ vec **vec_outer)
+{
+ /* MEMBER presents the relevant fields from the inside out, but we need
+ to build up the initializer from the outside in so that we can reuse
+ previously built CONSTRUCTORs if this is, say, the second field in an
+ anonymous struct. So we use a vec as a stack. */
+ vec fields;
+ fields.create (2);
+ do
+{
+ fields.safe_push (TREE_OPERAND (member, 1));
+ member = TREE_OPERAND (member, 0);
+}
+ while (ANON_AGGR_TYPE_P (TREE_TYPE (member)));
+
+ /* VEC has the constructor elements vector for the context of FIELD.
+ If FIELD is an anonymous aggregate, we will push inside it. */
+ vec **vec = vec_outer;
+ tree field;
+ while (field = fields.pop(),
+ ANON_AGGR_TYPE_P (TREE_TYPE (field)))
+{
+ tree ctor;
+ /* If there is already an outer constructor entry for the anonymous
+ aggregate FIELD, use it; otherwise, insert one. */
+ if (vec_safe_is_empty (*vec)
+ || (*vec)->last().index != field)
+ {
+ ctor = build_constructor (TREE_TYPE (field), NULL);
+ CONSTRUCTOR_APPEND_ELT (*vec, field, ctor);
+ }
+ else
+ ctor = (*vec)->last().value;
+ vec = &CONSTRUCTOR_ELTS (ctor);
+}
+
+ /* Now we're at the innermost field, the one that isn't an anonymous
+ aggregate. Add its initializer to the CONSTRUCTOR and we're done. */
+ gcc_assert (fields.is_empty());
+ fields.release ();
+ CONSTRUCTOR_APPEND_ELT (*vec, field, init);
+
+ return true;
+}
+
/* Subroutine of build_constexpr_constructor_member_initializers.
The expression tree T represents a data member initialization
in a (constexpr) constructor definition. Build a pairing of
@@ -5901,12 +5954,21 @@ build_data_member_initialization (tree t, vec **vec)
}
if (TREE_CODE (member) == ADDR_EXPR)
member = TREE_OPERAND (member, 0);
- if (TREE_CODE (member) == COMPONENT_REF
- /* If we're initializing a member of a subaggregate, it's a vtable
- pointer. Leave it as COMPONENT_REF so we remember the path to get
- to the vfield. */
- && TREE_CODE (TREE_OPERAND (member, 0)) != COMPONENT_REF)
-member = TREE_OPERAND (member, 1);
+ if (TREE_CODE (member) == COMPONENT_REF)
+{
+ tree aggr = TREE_OPERAND (member, 0);
+ if (TREE_CODE (aggr) != COMPONENT_REF)
+ /* Normal member initialization. */
+ member = TREE_OPERAND (member, 1);
+ else if (ANON_AGGR_TYPE_P (TREE_TYPE (aggr)))
+ /* Initializing a member of an anonymous union. */
+ return build_anon_member_initialization (member, init, vec);
+ else
+ /* We're initializing a vtable pointer in a base. Leave it as
+ COMPONENT_REF so we remember the path to get to the vfield. */
+ gcc_assert (TREE_TYPE (member) == vtbl_ptr_type_node);
+}
+
CONSTRUCTOR_APPEND_ELT (*vec, member, init);
return true;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-union4.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-union4.C
new file mode 100644
index 000..a8d6b8d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-union4.C
@@ -0,0 +1,18 @@
+// PR c++/54922
+// { dg-do compile { target c++11 } }
+
+struct nullable_int
+{
+ bool init_;
+ union {
+unsigned char for_value_init;
+int value_;
+ };
+
+ constexpr nullable_int() : init_(false), for_value_init() {}
+};
+
+#define SA(X) static_assert(X,#X)
+
+constexpr nullable_int n;
+SA((n.for_value_init == 0));
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-union5.C b/gcc/testsui
C++ PATCH for c++/55003 (wrong error with auto template static data member)
Normally we defer instantiation of the initializer of a static data
member of a template class until it is actually needed. If we need it
for deducing the type of the variable, we can go ahead and instantiate
it at that point.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fe74d7110cbaf9ccf153e2950eee04fe0907a988
Author: Jason Merrill
Date: Thu Feb 14 12:39:19 2013 -0500
PR c++/55003
* decl.c (cp_finish_decl): Force instantiation of an
auto static data member.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index eb6c490..3d63389 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6111,6 +6111,15 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
tree d_init;
if (init == NULL_TREE)
{
+ if (DECL_TEMPLATE_INSTANTIATION (decl)
+ && !DECL_TEMPLATE_INSTANTIATED (decl))
+ {
+ /* init is null because we're deferring instantiating the
+ initializer until we need it. Well, we need it now. */
+ instantiate_decl (decl, /*defer_ok*/true, /*expl*/false);
+ return;
+ }
+
error ("declaration of %q#D has no initializer", decl);
TREE_TYPE (decl) = error_mark_node;
return;
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto37.C b/gcc/testsuite/g++.dg/cpp0x/auto37.C
new file mode 100644
index 000..f4b2904
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto37.C
@@ -0,0 +1,14 @@
+// PR c++/55003
+// { dg-do compile { target c++11 } }
+
+template
+struct A {
+ static const auto t
+= (typename T::type)42;
+};
+
+struct X {
+ typedef int type;
+};
+
+A a;
Re: [RS6000] PR55341 linux unwind fixes
On Thu, Feb 14, 2013 at 5:33 PM, Alan Modra wrote: > PR55341 has two complaints, that powerpc gcc references a non-ABI > symbol exported by glibc, and that the scheme used to find the aux > vector can be broken by someone writing *environ = 0. Both true, but > since this code is only exercised when running Linux kernels prior to > 2.6.15 (7 years old!), I was inclined to "fix" the first problem by > making __libc_stack_end weak and ignore the second problem entirely. > > However, since I first looked at this bug, I've been delving into > unwinding code due to thinking we had a problem in the kernel vdso > with VSX registers. We didn't, but the exercise taught me that my > concern about blindly setting up locations for altivec registers is > unfounded. If the kernel doesn't support altivec and those locations > point well past the kernel sigcontext, perhaps even to unmapped > memory, we still don't have a problem since the normal course of > unwinding won't reference those locations. The unwinder only looks at > few regs like cfa and ra during unwinding, and the rest of the regs > when copying into _Unwind_* callee save locations using > uw_install_context. That means you'll only reference the altivec save > locations if you're using a libgcc with altivec support. Running such > a libgcc on a kernel without altivec support is crazy, and will cause > all sorts of problems before you even consider exception handling, > eg. sigill if the hardware doesn't support altivec, no process context > swapping of altivec regs etc. > > So we can do without the AT_HWCAP tests. There is also no need to > set up locations for call used regs. > > Bootstrapped and regression tested powerpc64-linux using a ld.so hack > to prevent registration of the kernel vdso. OK to apply? > > PR target/55431 > * config/rs6000/linux-unwind.h (ppc_linux_aux_vector): Delete. > (ppc_fallback_frame_state): Always set up save locations for fp > and altivec. Don't bother with non-callee-saved regs, r0-r13 > except for r2 on ppc64, fr0-fr13, v0-v19, vscr. Okay. Thanks, David
RE: RFC: [MIPS] Add an option to disable ldc1/sdc1
Richard Sandiford wrote: > Chao-Ying Fu writes: > > Hello All, > > > > Once in a while we got reports about programs (ex: > WebKit, FireFox) > > crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root > > cause is that programmers neglect the alignment issue and cast > > arbitrary pointers to point to double variables. > > > > Although the correct solution is to fix application source code to > > fulfill alignment requirements, we want to add a GCC option > to disable > > ldc1 and sdc1 (for the testing purpose or for workaround). > On 32-bit > > MIPS targets, GCC generates lwc1 and swc1 when > -mno-ldc1-sdc1 is used, > > so that the memory address can be just 4-byte aligned to avoid > > ldc1/sdc1 address exceptions. > > Sounds OK to me, given that the impact of the option is so low. Thanks a lot for OK! > Bikeshed time, but I'd prefer the option to be named after the thing > that we're guaranteeing, rather than an instruction. E.g. if the > problem is that doubles might only be 32-bit aligned, we could have > -mmisaligned-double (better suggestions welcome). > What about 64-bit targets? We can sometimes access doubles > using GPRs, > so on 64-bit targets we could end up using LD and SD to > access a double > even when this option disables LDC1 and SDC1. I think we'd need to > patch the move patterns as well. > > If you only see the problem on 32-bit targets, then maybe it would be > better to have an option that prevents instructions that > require greater > than word alignment. Say (for sake of argument) -mno-superword-align. > Then it would be: > > #define ISA_HAS_LDC1_SDC1 \ > (!ISA_MIPS1 && !TARGET_MIPS16 && (TARGET_64BIT || > TARGET_SUPERWORD_ALIGN)) We only got reports about 32-bit MIPS targets. But similar issues may happen on 64-bit MIPS targets. Note that these problematic programs can run fine on other architectures that allow 8-byte load/store instructions from 4-byte aligned addresses. For a short-term goal, we can use -mon-superword-align (or other option names) to disable ldc1 and sdc1 on 32-bit MIPS targets where only ldc1 and sdc1 have this 8-byte alignment rule. Later, we can extend this option to cover 64-bit MIPS targets. Thanks! Regards, Chao-ying
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
> >> AFAICT, for gcc+gas it should already work with binutils that include
> >> the AdaCore patch for DWARF support. But this has apparently not been
> >> tested with AIX ld, and there are AdaCore local patches pending.
> >> http://sourceware.org/ml/binutils/2011-04/msg00250.html
> >> http://www.sourceware.org/ml/gdb/2013-01/msg00030.html
>
> What is the status of merging Adacore's patches for DWARF support on AIX?
Sorry, David. I have been meaning to work on that ever since
we talked about it...
I spent some time today isolating the patches. I am currently
testing the patches we wrote for support on AIX 5.3. I then see
a few more patches to extend support to AIX 7.1 - section alignment
constraints, and stuff related to TLS.
Just for anyone who is curious, this is what I am testing.
It is missing the pieces for the other tools such as objdump,
for instance. But I think those can be submitted separately.
It might not apply to HEAD just yet, because I'm going at it
step by step. For those who use git, I applied it on top of:
commit 889f73fdb5bec852e083f47703f31592ef3ee77b
Author: Alan Modra
Date: Thu Oct 18 23:00:04 2012 +
daily update
--
Joel
>From dc928a0dbd0e762577c51204b043d6b6f066940d Mon Sep 17 00:00:00 2001
From: Joel Brobecker
Date: Thu, 14 Feb 2013 23:53:25 +0100
Subject: [PATCH] AIX: add DWARF support
* bfd/coff-rs6000.c (xcoff_dwsect_names): Add .dwframe,
.dwloc, .dwmacif and .dwmacro.
* bfd/libxcoff.h (XCOFF_DWSECT_NBR_NAMES): Set to 12.
* xcofflink.c (xcoff_mark): Mark all debugging symbols.
(bfd_xcoff_size_dynamic_sections): Mark all debugging sections.
(xcoff_link_input_bfd): Gah???
* gas/config/tc-ppc.c (ppc_named_section): Add handling
of DWARF sections.
---
bfd/coff-rs6000.c |6 -
bfd/libxcoff.h |2 +-
bfd/xcofflink.c | 65 +-
gas/config/tc-ppc.c | 29 ++-
4 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/bfd/coff-rs6000.c b/bfd/coff-rs6000.c
index 0945aca..9388ce3 100644
--- a/bfd/coff-rs6000.c
+++ b/bfd/coff-rs6000.c
@@ -3916,7 +3916,11 @@ const struct xcoff_dwsect_name xcoff_dwsect_names[] = {
{ SSUBTYP_DWARNGE, ".dwarnge", TRUE },
{ SSUBTYP_DWABREV, ".dwabrev", FALSE },
{ SSUBTYP_DWSTR, ".dwstr",TRUE },
- { SSUBTYP_DWRNGES, ".dwrnges", TRUE }
+ { SSUBTYP_DWRNGES, ".dwrnges", TRUE },
+ { 0x4700, ".dwframe", TRUE },
+ { 0x4701, ".dwloc",TRUE },
+ { 0x4702, ".dwmacif", FALSE },
+ { 0x4703, ".dwmacro", FALSE }
};
static const struct xcoff_backend_data_rec bfd_xcoff_backend_data =
diff --git a/bfd/libxcoff.h b/bfd/libxcoff.h
index 53a5e72..7583d5c 100644
--- a/bfd/libxcoff.h
+++ b/bfd/libxcoff.h
@@ -251,7 +251,7 @@ struct xcoff_dwsect_name {
/* Number of entries in the array. The number is known and public so that user
can 'extend' this array by index. */
-#define XCOFF_DWSECT_NBR_NAMES 8
+#define XCOFF_DWSECT_NBR_NAMES 12
/* The dwarf sections array. */
extern const struct xcoff_dwsect_name
diff --git a/bfd/xcofflink.c b/bfd/xcofflink.c
index 4adfb17..ad31643 100644
--- a/bfd/xcofflink.c
+++ b/bfd/xcofflink.c
@@ -2902,8 +2902,7 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
sec->flags |= SEC_MARK;
if (sec->owner->xvec == info->output_bfd->xvec
- && coff_section_data (sec->owner, sec) != NULL
- && xcoff_section_data (sec->owner, sec) != NULL)
+ && coff_section_data (sec->owner, sec) != NULL)
{
struct xcoff_link_hash_entry **syms;
struct internal_reloc *rel, *relend;
@@ -2911,18 +2910,21 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
unsigned long i, first, last;
/* Mark all the symbols in this section. */
- syms = obj_xcoff_sym_hashes (sec->owner);
- csects = xcoff_data (sec->owner)->csects;
- first = xcoff_section_data (sec->owner, sec)->first_symndx;
- last = xcoff_section_data (sec->owner, sec)->last_symndx;
- for (i = first; i <= last; i++)
- if (csects[i] == sec
- && syms[i] != NULL
- && (syms[i]->flags & XCOFF_MARK) == 0)
- {
- if (!xcoff_mark_symbol (info, syms[i]))
- return FALSE;
- }
+ if (xcoff_section_data (sec->owner, sec) != NULL)
+{
+ syms = obj_xcoff_sym_hashes (sec->owner);
+ csects = xcoff_data (sec->owner)->csects;
+ first = xcoff_section_data (sec->owner, sec)->first_symndx;
+ last = xcoff_section_data (sec->owner, sec)->last_symndx;
+ for (i = first; i <= last; i++)
+if (csects[i] == sec
+&& syms[i] != NULL
+&& (syms[i]->flags & XCOFF_MARK) == 0)
+ {
+if (!xcoff_mark_symbol (info, syms[i]))
+ return FALSE;
+ }
+}
/* Look through the section relocs. */
if ((sec->flags & S
[patch] give graphs from graph dump a name
Hello,
A user sent me a request to give names to the digraph in a graph dump.
This name can be used as a key for the dump, for a tool that can
generate graph metrics to see GCC transforms code as it passes through
the pipeline. Another user requested the same thing for a hacked xdot
that can plot multiple digraphs.
The dumpfile base name seemed like a good name for the digraph. This
patch prints it as the digraph label.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. Tested the graph
dump by dumping the .pre dump for my cc1-i files and plotting them
(*).
OK for trunk?
Ciao!
Steven
(*) note to self: manually tail-merge mark_stmt_necessary calls in
mark_stmt_if_obviously_necessary, or make mark_stmt_necessary
non-inline -- the graphs nicely show terrible code duplication :-)
* graph.c (start_graph_dump): Print dumpfile base name as digraph label.
(clean_graph_dump_file): Pass base to start_graph_dump.
Index: graph.c
===
--- graph.c (revision 196059)
+++ graph.c (working copy)
@@ -308,11 +308,16 @@ print_graph_cfg (const char *base, struct function
/* Start the dump of a graph. */
static void
-start_graph_dump (FILE *fp)
+start_graph_dump (FILE *fp, const char *base)
{
- fputs ("digraph \"\" {\n"
-"overlap=false;\n",
-fp);
+ pretty_printer *pp = init_graph_slim_pretty_print (fp);
+ pp_string (pp, "digraph \"");
+ pp_write_text_to_stream (pp);
+ pp_string (pp, base);
+ pp_write_text_as_dot_label_to_stream (pp, /*for_record=*/false);
+ pp_string (pp, "\" {\n");
+ pp_string (pp, "overlap=false;\n");
+ pp_flush (pp);
}
/* End the dump of a graph. */
@@ -327,7 +332,7 @@ void
clean_graph_dump_file (const char *base)
{
FILE *fp = open_graph_file (base, "w");
- start_graph_dump (fp);
+ start_graph_dump (fp, base);
fclose (fp);
}
Re: [Patch] Cleanup gcc.target/arm/interrupt-*.c for thumb mode
On 02/13/2013 06:39 AM, Greta Yorsh wrote: > The tests gcc.target/arm/interrupt-*.c are for ARM mode only. > This patch uses effective target arm_notthumb instead of __thumb_ predefine, > removes unreachable code, and fixes typos. > > Ok for trunk? > OK Janis > Thanks, > Greta > > ChangeLog > > gcc/testsuite/ > > 2012-02-13 Greta Yorsh > > * gcc.target/arm/interrupt-1.c: Fix for thumb mode. > * gcc.target/arm/interrupt-2.c: Likewise. >
C++ PATCH for c++/55220 (ICE with non-deducible parameter pack)
This testcase is well-formed, even though it doesn't do what the user
was trying to accomplish. In Tuple the use of a pack
expansion not at the end of the list makes the whole argument list a
non-deduced context, so we should get out early before it confuses us.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 48b50b5ac0b2f36d6b2f00c51862fe5461119eca
Author: Jason Merrill
Date: Thu Feb 14 12:00:30 2013 -0500
PR c++/55220
* pt.c (unify): A pack expansion that is not the last template
argument makes the entire template argument list non-deduced.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e88ea85..440df1e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16548,6 +16548,14 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict,
&& PACK_EXPANSION_P (TREE_VEC_ELT (parmvec, len - 1)))
parm_variadic_p = 1;
+ for (i = 0; i < len - parm_variadic_p; ++i)
+ /* If the template argument list of P contains a pack
+ expansion that is not the last template argument, the
+ entire template argument list is a non-deduced
+ context. */
+ if (PACK_EXPANSION_P (TREE_VEC_ELT (parmvec, i)))
+ return unify_success (explain_p);
+
if (TREE_VEC_LENGTH (argvec) < len - parm_variadic_p)
return unify_too_few_arguments (explain_p,
TREE_VEC_LENGTH (argvec), len);
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-nondeduce2.C b/gcc/testsuite/g++.dg/cpp0x/variadic-nondeduce2.C
new file mode 100644
index 000..a82a098
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-nondeduce2.C
@@ -0,0 +1,25 @@
+// PR c++/55220
+// { dg-do compile { target c++11 } }
+
+template struct something_like_tuple
+{
+
+};
+
+template struct is_last
+{
+ static const bool value = false;
+};
+
+// Head is non-deducible, so this can't work as the user intended
+template class Tuple, typename ... Head>
+struct is_last>
+{
+ static const bool value = true;
+};
+
+#define SA(X) static_assert (X, #X)
+
+typedef something_like_tuple something_like_tuple_t;
+SA ((is_last::value == false));
+SA ((is_last::value == false));
C++ PATCH for c++/56323 (rejects valid inheriting constructors)
The standard says that using X::X always means inheriting constructors,
even if X is a typedef. In templates, we also need to support this
usage for template template parameters, not just type parameters.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2b5203157486e00788228c2fe8572b5bbf4b555a
Author: Jason Merrill
Date: Thu Feb 14 11:40:28 2013 -0500
PR c++/56323
* name-lookup.c (do_class_using_decl): Handle typedefs with
inheriting constructors.
(push_class_level_binding_1): Allow inheriting from template
template parameter, too.
* pt.c (tsubst_decl) [USING_DECL]: Likewise.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 074dcf3..1f3c042 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -3028,11 +3028,10 @@ push_class_level_binding_1 (tree name, tree x)
decl = TREE_VALUE (decl);
if (TREE_CODE (decl) == USING_DECL
- && TREE_CODE (USING_DECL_SCOPE (decl)) == TEMPLATE_TYPE_PARM
+ && TYPE_NAME (USING_DECL_SCOPE (decl))
&& DECL_NAME (decl) == TYPE_IDENTIFIER (USING_DECL_SCOPE (decl)))
-/* This using-declaration declares constructors that inherit from the
- constructors for the template parameter. It does not redeclare the
- name of the template parameter. */
+/* This using-declaration declares inheriting constructors; it does not
+ redeclare the name of a template parameter. */
return true;
if (!check_template_shadow (decl))
@@ -3226,6 +3225,10 @@ do_class_using_decl (tree scope, tree name)
error ("%<%T::%D%> names destructor", scope, name);
return NULL_TREE;
}
+ if (TYPE_NAME (scope) && name == TYPE_IDENTIFIER (scope))
+/* 3.4.3.1 says that using B::B always names the constructor even if B
+ is a typedef; now replace the second B with the real name. */
+name = TYPE_IDENTIFIER (TYPE_MAIN_VARIANT (scope));
if (MAYBE_CLASS_TYPE_P (scope) && constructor_name_p (name, scope))
maybe_warn_cpp0x (CPP0X_INHERITING_CTORS);
if (constructor_name_p (name, current_class_type))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index aa868a4..e88ea85 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10492,7 +10492,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
tree inst_scope = tsubst_copy (USING_DECL_SCOPE (t), args,
complain, in_decl);
tree name = tsubst_copy (DECL_NAME (t), args, complain, in_decl);
- if (TREE_CODE (scope) == TEMPLATE_TYPE_PARM
+ /* Handle 'using T::T'. */
+ if (TYPE_NAME (scope)
&& name == TYPE_IDENTIFIER (scope))
name = TYPE_IDENTIFIER (inst_scope);
r = do_class_using_decl (inst_scope, name);
diff --git a/gcc/testsuite/g++.dg/cpp0x/inh-ctor17.C b/gcc/testsuite/g++.dg/cpp0x/inh-ctor17.C
new file mode 100644
index 000..22eda3a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/inh-ctor17.C
@@ -0,0 +1,45 @@
+// PR c++/56323
+// { dg-do compile { target c++11 } }
+
+struct A {
+ A(int i);
+};
+
+typedef A B;
+
+struct C : B {
+ using B::B;
+};
+
+struct D : B {
+ using B::A;
+};
+
+C c(0);
+D d(0);
+
+template
+struct E {
+ typedef T type;
+};
+
+template
+struct F : E::type {
+ using E::type::type; // error: E::type is a typedef
+};
+
+F f(0);
+
+template
+struct AT
+{
+ AT(T);
+};
+
+template class T>
+struct G : T
+{
+ using T::T;
+};
+
+G g(0);
Re: [PATCH,testsuite] Added test for PR 55987
On 02/14/2013 10:02 AM, Tilman Sauerbeck wrote:
> Hi,
> here's a patch that adds a testcase for PR 55987.
> Is xfail the right thing to use here? I went with that since I guess the
> PR won't be fixed anytime soon ;)
>
> I haven't assigned copyright to the FSF -- is this patch small enough to
> go in without it?
>
> Thanks,
> Tilman
I would prefer to add the test after the bug has been fixed.
Tests for unfixed bugs clutter up the test suite.
Janis
> 2013-02-14 Tilman Sauerbeck
>
> PR target/55987
> * gcc.target/arm/pr55987.c: New.
>
> diff --git a/gcc/testsuite/gcc.target/arm/pr55987.c
> b/gcc/testsuite/gcc.target/arm/pr55987.c
> new file mode 100644
> index 000..7dd9de0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr55987.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +/* { dg-final { scan-assembler-times ".word" 1 { xfail *-*-* } } } */
> +/* { dg-final { scan-assembler "bic" { xfail *-*-* } } } */
> +
> +unsigned f(unsigned x, unsigned y)
> +{
> + unsigned c = 0x7f7f7f7f;
> +
> + return (x & c) ^ (y & ~c);
> +}
>
>
C++ PATCH for c++/55223 (ICE with lambda in default argument scope)
In this PR, when we go to substitute into LAMBDA_EXPR_EXTRA_SCOPE, we
look for a local specialization of the parameter 'f', but there isn't
one because we aren't in a function body. For this case, unlike uses in
a trailing-return-type, we really need to look up the parameter in the
function parameter list in order to get the right mangling.
While I was looking at this I noticed that the names weren't demangling,
which turned out to be bugs in both the mangler and demangler, which
I've also fixed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 687e8c127536a8c208431d1786319ea6efda8637
Author: Jason Merrill
Date: Thu Feb 14 10:31:38 2013 -0500
PR c++/55223
gcc/cp/
* pt.c (tsubst_copy_and_build) [LAMBDA_EXPR]: Fix handling of
default argument scope.
* mangle.c (write_name): Likewise.
libiberty/
* cp-demangle.c (d_dump): Handle DEMANGLE_COMPONENT_DEFAULT_ARG.
(d_print_comp): Likewise.
diff --git a/gcc/common.opt b/gcc/common.opt
index b6592e0..3c7b415 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -785,7 +785,8 @@ Driver Undocumented
;argument.
;First selectable in G++ 4.7.
;
-; 7: The version of the ABI that treats nullptr_t as a builtin type.
+; 7: The version of the ABI that treats nullptr_t as a builtin type and
+;corrects the mangling of lambdas in default argument scope.
;First selectable in G++ 4.8.
; Additional positive integers will be assigned as new versions of
; the ABI become the default version of the ABI.
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index f6b3443..a48d476 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -802,7 +802,10 @@ write_name (tree decl, const int ignore_local_scope)
if (context == NULL
|| context == global_namespace
|| DECL_NAMESPACE_STD_P (context)
- || (ignore_local_scope && TREE_CODE (context) == FUNCTION_DECL))
+ || (ignore_local_scope
+ && (TREE_CODE (context) == FUNCTION_DECL
+ || (abi_version_at_least (7)
+ && TREE_CODE (context) == PARM_DECL
{
tree template_info;
/* Is this a template instance? */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bd44fde..aa868a4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1,8 +1,20 @@ tsubst_copy_and_build (tree t,
than build a new one. */
tree scope = LAMBDA_EXPR_EXTRA_SCOPE (t);
if (scope && TREE_CODE (scope) == FUNCTION_DECL)
- scope = tsubst (LAMBDA_EXPR_EXTRA_SCOPE (t), args,
- complain, in_decl);
+ scope = tsubst (scope, args, complain, in_decl);
+ else if (scope && TREE_CODE (scope) == PARM_DECL)
+ {
+ /* Look up the parameter we want directly, as tsubst_copy
+ doesn't do what we need. */
+ tree fn = tsubst (DECL_CONTEXT (scope), args, complain, in_decl);
+ tree parm = FUNCTION_FIRST_USER_PARM (fn);
+ while (DECL_PARM_INDEX (parm) != DECL_PARM_INDEX (scope))
+ parm = DECL_CHAIN (parm);
+ scope = parm;
+ /* FIXME Work around the parm not having DECL_CONTEXT set. */
+ if (DECL_CONTEXT (scope) == NULL_TREE)
+ DECL_CONTEXT (scope) = fn;
+ }
else
scope = RECUR (scope);
LAMBDA_EXPR_EXTRA_SCOPE (r) = scope;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg3.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg3.C
new file mode 100644
index 000..f02fb29
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg3.C
@@ -0,0 +1,18 @@
+// PR c++/55223
+// { dg-options "-std=c++11 -fabi-version=0" }
+// { dg-final { scan-assembler "_ZN8functionC1IZN1CIiE4testES_Ed_UliE_EET_" } }
+
+struct function
+{
+ template function(U u) { }
+};
+
+template struct C
+{
+ static T test(function f = [](int i){return i;}) { }
+};
+
+int main()
+{
+ C::test();
+}
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 913d4bf..39be031 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -707,6 +707,14 @@ d_dump (struct demangle_component *dc, int indent)
case DEMANGLE_COMPONENT_TLS_WRAPPER:
printf ("tls wrapper function\n");
break;
+case DEMANGLE_COMPONENT_DEFAULT_ARG:
+ printf ("default argument %d\n", dc->u.s_unary_num.num);
+ d_dump (dc->u.s_unary_num.sub, indent+2);
+ return;
+case DEMANGLE_COMPONENT_LAMBDA:
+ printf ("lambda %d\n", dc->u.s_unary_num.num);
+ d_dump (dc->u.s_unary_num.sub, indent+2);
+ return;
}
d_dump (d_left (dc), indent + 2);
@@ -3168,6 +3176,7 @@ d_expr_primary (struct d_info *di)
/* ::= Z <(function) encoding> E <(entity) name> []
::= Z <(function) encoding> E s []
+::= Z <(function) encoding> E d [ number>] _
*/
static struct demangle_component *
@@ -3869,7 +3878,17 @@ d_print_comp (struct d_print_info *dpi, int options,
d_append_string (dpi, "::");
else
d_append_char (dpi, '.');
- d_print_comp (dpi, options, d_right (dc));
+ {
+ struct demangle_component *local_name = d_right (dc);
+ if (local_name->type =
[RS6000] PR55341 linux unwind fixes
PR55341 has two complaints, that powerpc gcc references a non-ABI
symbol exported by glibc, and that the scheme used to find the aux
vector can be broken by someone writing *environ = 0. Both true, but
since this code is only exercised when running Linux kernels prior to
2.6.15 (7 years old!), I was inclined to "fix" the first problem by
making __libc_stack_end weak and ignore the second problem entirely.
However, since I first looked at this bug, I've been delving into
unwinding code due to thinking we had a problem in the kernel vdso
with VSX registers. We didn't, but the exercise taught me that my
concern about blindly setting up locations for altivec registers is
unfounded. If the kernel doesn't support altivec and those locations
point well past the kernel sigcontext, perhaps even to unmapped
memory, we still don't have a problem since the normal course of
unwinding won't reference those locations. The unwinder only looks at
few regs like cfa and ra during unwinding, and the rest of the regs
when copying into _Unwind_* callee save locations using
uw_install_context. That means you'll only reference the altivec save
locations if you're using a libgcc with altivec support. Running such
a libgcc on a kernel without altivec support is crazy, and will cause
all sorts of problems before you even consider exception handling,
eg. sigill if the hardware doesn't support altivec, no process context
swapping of altivec regs etc.
So we can do without the AT_HWCAP tests. There is also no need to
set up locations for call used regs.
Bootstrapped and regression tested powerpc64-linux using a ld.so hack
to prevent registration of the kernel vdso. OK to apply?
PR target/55431
* config/rs6000/linux-unwind.h (ppc_linux_aux_vector): Delete.
(ppc_fallback_frame_state): Always set up save locations for fp
and altivec. Don't bother with non-callee-saved regs, r0-r13
except for r2 on ppc64, fr0-fr13, v0-v19, vscr.
Index: libgcc/config/rs6000/linux-unwind.h
===
--- libgcc/config/rs6000/linux-unwind.h (revision 195836)
+++ libgcc/config/rs6000/linux-unwind.h (working copy)
@@ -26,7 +26,6 @@
#define R_CR2 70
#define R_VR0 77
#define R_VRSAVE 109
-#define R_VSCR 110
struct gcc_vregs
{
@@ -175,38 +174,6 @@
}
#endif
-/* Find an entry in the process auxiliary vector. The canonical way to
- test for VMX is to look at AT_HWCAP. */
-
-static long
-ppc_linux_aux_vector (long which)
-{
- /* __libc_stack_end holds the original stack passed to a process. */
- extern long *__libc_stack_end;
- long argc;
- char **argv;
- char **envp;
- struct auxv
- {
-long a_type;
-long a_val;
- } *auxp;
-
- /* The Linux kernel puts argc first on the stack. */
- argc = __libc_stack_end[0];
- /* Followed by argv, NULL terminated. */
- argv = (char **) __libc_stack_end + 1;
- /* Followed by environment string pointers, NULL terminated. */
- envp = argv + argc + 1;
- while (*envp++)
-continue;
- /* Followed by the aux vector, zero terminated. */
- for (auxp = (struct auxv *) envp; auxp->a_type != 0; ++auxp)
-if (auxp->a_type == which)
- return auxp->a_val;
- return 0;
-}
-
/* Do code reading to identify a signal frame, and set the frame
state data appropriately. See unwind-dw2.c for the structs. */
@@ -216,8 +183,8 @@
ppc_fallback_frame_state (struct _Unwind_Context *context,
_Unwind_FrameState *fs)
{
- static long hwcap = 0;
struct gcc_regs *regs = get_regs (context);
+ struct gcc_vregs *vregs;
long new_cfa;
int i;
@@ -229,12 +196,15 @@
fs->regs.cfa_reg = STACK_POINTER_REGNUM;
fs->regs.cfa_offset = new_cfa - (long) context->cfa;
- for (i = 0; i < 32; i++)
-if (i != STACK_POINTER_REGNUM)
- {
- fs->regs.reg[i].how = REG_SAVED_OFFSET;
- fs->regs.reg[i].loc.offset = (long) ®s->gpr[i] - new_cfa;
- }
+#ifdef __powerpc64__
+ fs->regs.reg[2].how = REG_SAVED_OFFSET;
+ fs->regs.reg[2].loc.offset = (long) ®s->gpr[2] - new_cfa;
+#endif
+ for (i = 14; i < 32; i++)
+{
+ fs->regs.reg[i].how = REG_SAVED_OFFSET;
+ fs->regs.reg[i].loc.offset = (long) ®s->gpr[i] - new_cfa;
+}
fs->regs.reg[R_CR2].how = REG_SAVED_OFFSET;
/* CR? regs are always 32-bit and PPC is big-endian, so in 64-bit
@@ -250,57 +220,35 @@
fs->retaddr_column = ARG_POINTER_REGNUM;
fs->signal_frame = 1;
- if (hwcap == 0)
+ /* If we have a FPU... */
+ for (i = 14; i < 32; i++)
{
- hwcap = ppc_linux_aux_vector (16);
- /* These will already be set if we found AT_HWCAP. A nonzero
-value stops us looking again if for some reason we couldn't
-find AT_HWCAP. */
-#ifdef __powerpc64__
- hwcap |= 0xc000;
-#else
- hwcap |= 0x8000;
-#endif
+ fs->regs.reg[i + 32].how = REG_SAVED_OFFSET;
+ fs->regs.reg[i + 32].loc.offset = (long) ®s->fpr[i]
Re: [patch, Fortran] Fix PR 56224
Hi Tobias,
OK. Thanks for the patch after fixing the nit below.
Sorry for not noticing the review when you sent it.
Here is the patch as I committed it as Revision 196058.
2013-02-14 Thomas Koenig
PR fortran/56224
* gfortran.h (gfc_add_include_path): Add boolean argument
for warn.
* scanner.c (gfc_add_include_path): Pass along warn argument
to add_path_to_list.
* options.c (gfc_post_options): Add true warn argument to
gfc_add_include_path.
(gfc_handle_module_path_options): Likewise.
(gfc_handle_option): Also gfc_add_include_path for intrinsic
modules, without warning.
Thanks for the review!
Thomas
Index: gfortran.h
===
--- gfortran.h (Revision 195922)
+++ gfortran.h (Arbeitskopie)
@@ -2381,7 +2381,7 @@ match gfc_match_char_spec (gfc_typespec *);
void gfc_scanner_done_1 (void);
void gfc_scanner_init_1 (void);
-void gfc_add_include_path (const char *, bool, bool);
+void gfc_add_include_path (const char *, bool, bool, bool);
void gfc_add_intrinsic_modules_path (const char *);
void gfc_release_include_path (void);
FILE *gfc_open_included_file (const char *, bool, bool);
Index: options.c
===
--- options.c (Revision 195922)
+++ options.c (Arbeitskopie)
@@ -337,10 +337,10 @@ gfc_post_options (const char **pfilename)
source_path = (char *) alloca (i + 1);
memcpy (source_path, canon_source_file, i);
source_path[i] = 0;
- gfc_add_include_path (source_path, true, true);
+ gfc_add_include_path (source_path, true, true, true);
}
else
-gfc_add_include_path (".", true, true);
+gfc_add_include_path (".", true, true, true);
if (canon_source_file != gfc_source_file)
free (CONST_CAST (char *, canon_source_file));
@@ -498,7 +498,7 @@ gfc_handle_module_path_options (const char *arg)
gfc_option.module_dir = XCNEWVEC (char, strlen (arg) + 2);
strcpy (gfc_option.module_dir, arg);
- gfc_add_include_path (gfc_option.module_dir, true, false);
+ gfc_add_include_path (gfc_option.module_dir, true, false, true);
strcat (gfc_option.module_dir, "/");
}
@@ -844,6 +844,13 @@ gfc_handle_option (size_t scode, const char *arg,
case OPT_fintrinsic_modules_path:
case OPT_fintrinsic_modules_path_:
+
+ /* This is needed because omp_lib.h is in a directory together
+ with intrinsic modules. Do no warn because during testing
+ without an installed compiler, we would get lots of bogus
+ warnings for a missing include directory. */
+ gfc_add_include_path (arg, false, false, false);
+
gfc_add_intrinsic_modules_path (arg);
break;
@@ -978,7 +985,7 @@ gfc_handle_option (size_t scode, const char *arg,
break;
case OPT_I:
- gfc_add_include_path (arg, true, false);
+ gfc_add_include_path (arg, true, false, true);
break;
case OPT_J:
Index: scanner.c
===
--- scanner.c (Revision 195922)
+++ scanner.c (Arbeitskopie)
@@ -375,9 +375,10 @@ add_path_to_list (gfc_directorylist **list, const
void
-gfc_add_include_path (const char *path, bool use_for_modules, bool file_dir)
+gfc_add_include_path (const char *path, bool use_for_modules, bool file_dir,
+ bool warn)
{
- add_path_to_list (&include_dirs, path, use_for_modules, file_dir, true);
+ add_path_to_list (&include_dirs, path, use_for_modules, file_dir, warn);
/* For '#include "..."' these directories are automatically searched. */
if (!file_dir)
Re: [PING^3] Re: [PATCH 1/2] Document HLE / RTM intrinsics
Andi Kleen writes: PING^3 I'm about to give up on this, concluding that there is no interest in improving the gcc documentation. -Andi > Andi Kleen writes: > > PING^2!! > >> Andi Kleen writes: >> >>> From: Andi Kleen >>> >>> The TSX HLE/RTM intrinsics were missing documentation. Add this to the >>> manual. >>> >>> Ok for release / trunk? >> >> Could someone please review/approve this (documentation only) patch? > >> Thanks. >> >> -Andi >> >>> 2013-01-11 Andi Kleen >>> >>> * doc/extend.texi: Document __ATOMIC_HLE_ACQUIRE, >>> __ATOMIC_HLE_RELEASE. Document __builtin_ia32 TSX intrincs. >>> Document _x* TSX intrinsics. -- a...@linux.intel.com -- Speaking for myself only
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
> "Dave" == John David Anglin writes: Dave> I had looked at this a bit in the past. I don't think it's that Dave> difficult to add DWARF2 support Dave> to GCC on hppa. Although we don't support named sections, we can Dave> create named subspaces Dave> for the dwarf info. More of an issue in my mind is the changes needed Dave> to gdb to recognize Dave> this support. I don't think it should be a big problem. There are other gdb ports that use their own section names for DWARF sections. In one case I think this the mapping is handled in BFD, but in another case (XCOFF), it is done in gdb. Tom
Re:
On Thu, 14 Feb 2013, Xinliang David Li wrote: Ok for the google branch -- please provide the patch details in svn commit message (note that ChangeLog is not needed any more for the branch). I don't have commit access (yet). Should I email overse...@gcc.gnu.org as mentioned at http://gcc.gnu.org/svnwrite.html to get the ball rolling? On Thu, Feb 14, 2013 at 11:53 AM, Matt Hargett wrote: On Feb 14, 2013, at 10:40 AM, Xinliang David Li wrote: On Thu, Feb 14, 2013 at 10:18 AM, Matt wrote: The attached patches do two things: 1. Backports a fix from trunk that eliminates bogus warning traces. On my current codebase which links ~40MB of C++ with LTO, the bogus warning traces are literally hundreds of lines. What is the trunk revision? Richard's original patch was committed to trunk in r195884. I verified the backport fixed our issue by doing doing a profiledbootstrap using the bootstrap-lto.mk config with -O3 added. I used the resulting compiler on the proprietary codebase, C++Benchmark, scummvm, and a few other open source projects to validate. 2. Our primary development platform is RHEL6.1-based, and the recent autoconf requirement bump locked us out. I lowered the version, and saw no difference in ability to configure/bootstrap. Thanks! -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt
Re:
Ok for the google branch -- please provide the patch details in svn commit message (note that ChangeLog is not needed any more for the branch). David On Thu, Feb 14, 2013 at 11:53 AM, Matt Hargett wrote: > On Feb 14, 2013, at 10:40 AM, Xinliang David Li wrote: > >> On Thu, Feb 14, 2013 at 10:18 AM, Matt wrote: >>> The attached patches do two things: >>> 1. Backports a fix from trunk that eliminates bogus warning traces. On my >>> current codebase which links ~40MB of C++ with LTO, the bogus warning traces >>> are literally hundreds of lines. >> >> What is the trunk revision? > > Richard's original patch was committed to trunk in r195884. > > >>> I verified the backport fixed our issue by doing doing a profiledbootstrap >>> using the bootstrap-lto.mk config with -O3 added. I used the resulting >>> compiler on the proprietary codebase, C++Benchmark, scummvm, and a few other >>> open source projects to validate. >>> >>> 2. Our primary development platform is RHEL6.1-based, and the recent >>> autoconf requirement bump locked us out. I lowered the version, and saw no >>> difference in ability to configure/bootstrap. >>> >>> Thanks! >>> >>> >>> -- >>> tangled strands of DNA explain the way that I behave. >>> http://www.clock.org/~matt
C++ PATCH for c++/55232 (ICE on diagnostic in variadic template function)
We try to print typename types when dumping template bindings in order
to be helpful. But we can't do that for typenames in pack expansions
because we don't know which pack element we're interested in.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 91f6181cddda74ddfbae6e57454ab69659847928
Author: Jason Merrill
Date: Thu Feb 14 09:13:54 2013 -0500
PR c++/55232
* error.c (find_typenames_r): Don't walk into a pack expansion.
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index a4b3320..60119ec 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1283,7 +1283,7 @@ struct find_typenames_t
};
static tree
-find_typenames_r (tree *tp, int * /*walk_subtrees*/, void *data)
+find_typenames_r (tree *tp, int *walk_subtrees, void *data)
{
struct find_typenames_t *d = (struct find_typenames_t *)data;
tree mv = NULL_TREE;
@@ -1296,6 +1296,14 @@ find_typenames_r (tree *tp, int * /*walk_subtrees*/, void *data)
/* Add the typename without any cv-qualifiers. */
mv = TYPE_MAIN_VARIANT (*tp);
+ if (TREE_CODE (*tp) == TYPE_PACK_EXPANSION)
+{
+ /* Don't mess with parameter packs since we don't remember
+ the pack expansion context for a particular typename. */
+ *walk_subtrees = false;
+ return NULL_TREE;
+}
+
if (mv && (mv == *tp || !pointer_set_insert (d->p_set, mv)))
vec_safe_push (d->typenames, mv);
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-diag1.C b/gcc/testsuite/g++.dg/cpp0x/variadic-diag1.C
new file mode 100644
index 000..53182d3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-diag1.C
@@ -0,0 +1,22 @@
+// PR c++/55232
+// { dg-do compile { target c++11 } }
+
+struct vector
+{
+typedef int value_type;
+};
+
+template< class U, class... T >
+struct X
+{
+void push_back( typename T::value_type ... vals )
+{
+ U::asoeuth; // { dg-error "" }
+}
+};
+
+int main()
+{
+ X< int, vector > x;
+ x.push_back( 0 );
+}
Re:
On Feb 14, 2013, at 10:40 AM, Xinliang David Li wrote: > On Thu, Feb 14, 2013 at 10:18 AM, Matt wrote: >> The attached patches do two things: >> 1. Backports a fix from trunk that eliminates bogus warning traces. On my >> current codebase which links ~40MB of C++ with LTO, the bogus warning traces >> are literally hundreds of lines. > > What is the trunk revision? Richard's original patch was committed to trunk in r195884. >> I verified the backport fixed our issue by doing doing a profiledbootstrap >> using the bootstrap-lto.mk config with -O3 added. I used the resulting >> compiler on the proprietary codebase, C++Benchmark, scummvm, and a few other >> open source projects to validate. >> >> 2. Our primary development platform is RHEL6.1-based, and the recent >> autoconf requirement bump locked us out. I lowered the version, and saw no >> difference in ability to configure/bootstrap. >> >> Thanks! >> >> >> -- >> tangled strands of DNA explain the way that I behave. >> http://www.clock.org/~matt
Re: [cxx-conversion] Add Record Builder Class
On 2/14/13, Richard Biener wrote:
> On Tue, Feb 12, 2013 at 8:47 PM, Lawrence Crowl wrote:
> > Add class record_builder to ease construction of records and unions. Use
> > it
> > in some appropriate places.
> > tree
> > -default_emutls_var_fields (tree type, tree *name ATTRIBUTE_UNUSED)
> > +default_emutls_object_type (void)
> > {
> > - tree word_type_node, field, next_field;
> > -
> > - field = build_decl (UNKNOWN_LOCATION,
> > - FIELD_DECL, get_identifier ("__templ"),
> > ptr_type_node);
> > - DECL_CONTEXT (field) = type;
> > - next_field = field;
> > -
> > - field = build_decl (UNKNOWN_LOCATION,
> > - FIELD_DECL, get_identifier ("__offset"),
> > - ptr_type_node);
> > - DECL_CONTEXT (field) = type;
> > - DECL_CHAIN (field) = next_field;
> > - next_field = field;
> > -
> > - word_type_node = lang_hooks.types.type_for_mode (word_mode, 1);
> > - field = build_decl (UNKNOWN_LOCATION,
> > - FIELD_DECL, get_identifier ("__align"),
> > - word_type_node);
> > - DECL_CONTEXT (field) = type;
> > - DECL_CHAIN (field) = next_field;
> > - next_field = field;
> > -
> > - field = build_decl (UNKNOWN_LOCATION,
> > - FIELD_DECL, get_identifier ("__size"),
> > word_type_node);
> > - DECL_CONTEXT (field) = type;
> > - DECL_CHAIN (field) = next_field;
> > -
> > - return field;
> > + tree word_type_node = lang_hooks.types.type_for_mode (word_mode, 1);
> > + record_builder rec;
> > + rec.add_field ("__size", word_type_node);
> > + rec.add_field ("__align", word_type_node);
> > + rec.add_field ("__offset", ptr_type_node);
> > + rec.add_field ("__templ", ptr_type_node);
> > + rec.layout ();
>
> That's awkward - you want to hide the fact that layout has
> to happen and that it has to happen "last". Just make it a
> side-effect of .as_tree ().
Sometimes you want to construct recursive types, and for that you
need .as_tree to execute before layout. This feature is used in
the patch.
> Note that add_field want's to return the FIELD_DECL created,
> people may want to alter it.
Do you have a use case? Until we have one, I'm not convinced that
we should widen the interface.
> Note that tag_name does not allow the way C++ uses this (it can
> be a TYPE_DECL).
That is what the .decl_name member function does.
> Overall I'm not sure this is a good abstraction unless you manage
> to make the frontends use it.
The intent is for use by the middle/back ends constructing code.
As such, it should be using middle/back end types, not front-end
types.
--
Lawrence Crowl
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
... or the below, just in case an interesting system provides the
*quick_exit functions but doesn't define _GLIBCXX_USE_C99.
Paolo.
///
Index: testsuite/18_support/quick_exit/quick_exit.cc
===
--- testsuite/18_support/quick_exit/quick_exit.cc (revision 196056)
+++ testsuite/18_support/quick_exit/quick_exit.cc (working copy)
@@ -25,7 +25,9 @@
void handler()
{
+#if _GLIBCXX_USE_C99
std::_Exit(0);
+#endif
}
void wrong_handler()
@@ -35,9 +37,11 @@
int main()
{
+#if _GLIBCXX_USE_C99
#if defined(_GLIBCXX_HAVE_AT_QUICK_EXIT) && defined(_GLIBCXX_HAVE_QUICK_EXIT)
std::at_quick_exit (handler);
std::atexit (wrong_handler);
std::quick_exit (1);
#endif
+#endif
}
Re:
On Thu, Feb 14, 2013 at 10:18 AM, Matt wrote: > The attached patches do two things: > 1. Backports a fix from trunk that eliminates bogus warning traces. On my > current codebase which links ~40MB of C++ with LTO, the bogus warning traces > are literally hundreds of lines. > What is the trunk revision? David > I verified the backport fixed our issue by doing doing a profiledbootstrap > using the bootstrap-lto.mk config with -O3 added. I used the resulting > compiler on the proprietary codebase, C++Benchmark, scummvm, and a few other > open source projects to validate. > > 2. Our primary development platform is RHEL6.1-based, and the recent > autoconf requirement bump locked us out. I lowered the version, and saw no > difference in ability to configure/bootstrap. > > Thanks! > > > -- > tangled strands of DNA explain the way that I behave. > http://www.clock.org/~matt
[PATCH,testsuite] Added test for PR 55987
Hi,
here's a patch that adds a testcase for PR 55987.
Is xfail the right thing to use here? I went with that since I guess the
PR won't be fixed anytime soon ;)
I haven't assigned copyright to the FSF -- is this patch small enough to
go in without it?
Thanks,
Tilman
2013-02-14 Tilman Sauerbeck
PR target/55987
* gcc.target/arm/pr55987.c: New.
diff --git a/gcc/testsuite/gcc.target/arm/pr55987.c
b/gcc/testsuite/gcc.target/arm/pr55987.c
new file mode 100644
index 000..7dd9de0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr55987.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-times ".word" 1 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler "bic" { xfail *-*-* } } } */
+
+unsigned f(unsigned x, unsigned y)
+{
+ unsigned c = 0x7f7f7f7f;
+
+ return (x & c) ^ (y & ~c);
+}
Re: [Patch, AArch64] Set libgloss_dir for aarch64*-*-* targets
On 10/01/13 16:20, Yufeng Zhang wrote: Hi, This patch updates the top-level configuration files to explicitly set libgloss_dir to aarch64 for aarch64*-*-* targets. OK to commit? Thanks, Yufeng 2013-01-10 Yufeng Zhang * configure.ac: Set libgloss_dir for the aarch64*-*-* targets. * configure: Regenerated. OK. R.
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
Hi Rainer,
On 02/14/2013 04:45 PM, Rainer Orth wrote:
Jason Merrill writes:
While I was going over the C++11 status page, I noticed that quick_exit is
implemented by glibc, it just needed to be added to the libstdc++ cstdlib
header.
The test fails on Solaris 9:
FAIL: 18_support/quick_exit/quick_exit.cc (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/quick_exit/quick_e
xit.cc:28:3: error: '_Exit' is not a member of 'std'
WARNING: 18_support/quick_exit/quick_exit.cc compilation failed to produce execu
table
extra_tool_flags are:
-std=gnu++11
_Exit seems to be a C99 addition, only present since Solaris 10.
Indeed. Given the very simple nature of the testcase, I think something
like the below can do, at least for 4.8.0, if Jason has no objections.
Can you double check it on Solaris and in case commit it?
Thanks,
Paolo.
/
Index: testsuite/18_support/quick_exit/quick_exit.cc
===
--- testsuite/18_support/quick_exit/quick_exit.cc (revision 196056)
+++ testsuite/18_support/quick_exit/quick_exit.cc (working copy)
@@ -25,7 +25,9 @@
void handler()
{
+#if _GLIBCXX_USE_C99
std::_Exit(0);
+#endif
}
void wrong_handler()
Re: [Ping^2] [Patch, AArch64] Set libgloss_dir for aarch64*-*-* targets
Ping^2
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00554.html
Thanks,
Yufeng
On 01/28/13 15:04, Yufeng Zhang wrote:
Ping~
On 01/10/13 16:20, Yufeng Zhang wrote:
Hi,
This patch updates the top-level configuration files to explicitly set
libgloss_dir to aarch64 for aarch64*-*-* targets.
OK to commit?
Thanks,
Yufeng
2013-01-10 Yufeng Zhang
* configure.ac: Set libgloss_dir for the aarch64*-*-* targets.
* configure: Regenerated.
top-level-config.patch
diff --git a/configure.ac b/configure.ac
index 02720ee..5bdf1d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -759,6 +759,9 @@ case "${target}" in
sh*-*-pe|mips*-*-pe|*arm-wince-pe)
libgloss_dir=wince
;;
+ aarch64*-*-* )
+libgloss_dir=aarch64
+;;
arm*-*-*)
libgloss_dir=arm
;;
Re: [PATCH] GCC 4.9 powerpc, fix insn type attribute for load/store insns
On Mon, Feb 11, 2013 at 9:36 PM, Pat Haugen wrote: > The following patch fixes the assignment of the insn "type" attribute for > loads and stores. Specifically, it will now appropriately assign update form > and update-indexed form type attributes which allows for better instruction > scheduling by honoring group formation restrictions and (to a lesser extent) > insn latency for the updated address reg. The patch is based on Mike > Meissner's prior 4.9 submissions for move pattern combinations. > > Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for 4.9 > when it opens up? > > > 2013-02-12 Pat Haugen > * config/rs6000/predicates.md (indexed_address, update_address_mem > update_indexed_address_mem): New predicates. > * config/rs6000/vsx.md (vsx_extract__zero): Set correct "type" > attribute for load/store instructions. > * config/rs6000/dfp.md (movsd_store): Likewise. > (movsd_load): Likewise. > * config/rs6000/rs6000.md (zero_extenddi2_internal1): > Likewise. > (unnamed HI->DI extend define_insn): Likewise. > (unnamed SI->DI extend define_insn): Likewise. > (unnamed QI->SI extend define_insn): Likewise. > (unnamed QI->HI extend define_insn): Likewise. > (unnamed HI->SI extend define_insn): Likewise. > (unnamed HI->SI extend define_insn): Likewise. > (extendsfdf2_fpr): Likewise. > (movsi_internal1): Likewise. > (movsi_internal1_single): Likewise. > (movhi_internal): Likewise. > (movqi_internal): Likewise. > (movcc_internal1): Correct mnemonic for stw insn. Set correct "type" > attribute for load/store instructions. > (mov_hardfloat): Set correct "type" attribute for load/store > instructions. > (mov_softfloat): Likewise. > (mov_hardfloat32): Likewise. > (mov_hardfloat64): Likewise. > (mov_softfloat64): Likewise. > (movdi_internal32): Likewise. > (movdi_internal64): Likewise. > (probe_stack_): Likewise. This is okay for GCC 4.9, when it opens. Thanks, David
Re: PATCH: PR bootstrap/56327: [4.8 Regression] Revision 196009 breaks bootstrap on x3
On Thu, Feb 14, 2013 at 08:33:27AM -0800, H.J. Lu wrote: > 2013-02-14 H.J. Lu > > PR bootstrap/56327 > * interception/interception.h (OFF_T): Merged from upstream > r175140. Ok. > diff --git a/libsanitizer/interception/interception.h > b/libsanitizer/interception/interception.h > index b4c4137..c4c5026 100644 > --- a/libsanitizer/interception/interception.h > +++ b/libsanitizer/interception/interception.h > @@ -28,8 +28,8 @@ typedef __sanitizer::s64 INTMAX_T; > // WARNING: OFF_T may be different from OS type off_t, depending on > the value of > // _FILE_OFFSET_BITS. This definition of OFF_T matches the ABI of system > calls > // like pread and mmap, as opposed to pread64 and mmap64. > -// Mac is special. > -#ifdef __APPLE__ > +// Mac and Linux/x86-64 are special. > +#if defined(__APPLE__) || (defined(__linux__) && defined(__x86_64__)) > typedef __sanitizer::u64 OFF_T; > #else > typedef __sanitizer::uptr OFF_T; Jakub
PATCH: PR bootstrap/56327: [4.8 Regression] Revision 196009 breaks bootstrap on x3
On Thu, Feb 14, 2013 at 12:07 AM, Konstantin Serebryany
wrote:
> On Wed, Feb 13, 2013 at 10:29 PM, H.J. Lu wrote:
>> On Wed, Feb 13, 2013 at 1:19 AM, Konstantin Serebryany
>> wrote:
>>> Hi,
>>>
>>> The attached patch is the libsanitizer merge from upstream r175042.
>>>
>>> Lots of changes. Among other things:
>>> - x86_64 linux: change the shadow offset to 0x7fff8000 (~5% speedup)
>>> - the new asan allocator is enabled on Mac (was enabled on Linux before).
>>> - tsan finds races between atomic and plain accesses
>>> - better scanf interceptor, enabled by default
>>> - don't include linux/futex.h (fixes PR56128)
>>> - simple tests seem to work (again?) on PowerPC64 with 44-bit address
>>> space (46 AS not tested)
>>>
>>> Patch for libsanitizer is automatically generated by libsanitizer/merge.sh
>>> Tested with
>>> rm -rf */{*/,}libsanitizer \
>>> && make -j 50 \
>>> && make -C gcc check-g{cc,++}
>>> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
>>>
>>> Our internal LLVM bots (Linux, Mac and Android) are green.
>>>
>>> Ok to commit?
>>>
>>> --kcc
>>
>> This breaks build on Linux/x32 where off_t is 64bit:
>
> Sorry. I've committed your patch upstream as
> http://llvm.org/viewvc/llvm-project?rev=175140&view=rev
> Feel free to submit the same directly to gcc.
>
> Thanks!
>
> --kcc
>
>>
>> In file included from
>> /export/gnu/import/git/gcc/libsanitizer/interception/interception.h:20:0,
>> from
>> /export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:15:
>> /export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:221:72:
>> error: size of array ‘assertion_failed__34’ is negative
>> typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
>> ^
>> /export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:215:30:
>> note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
>> #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
>> ^
>> /export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:34:1:
>> note: in expansion of macro ‘COMPILER_CHECK’
>> COMPILER_CHECK(sizeof(OFF_T) == sizeof(off_t));
>> ^
>> make[7]: *** [interception_type_test.lo] Error 1
>>
>> This patch fixes it. OK to install?
>>
>> Thanks.
>>
>> --
>> H.J.
>> ---
>> diff --git a/libsanitizer/interception/interception.h
>> b/libsanitizer/interception/interception.h
>> index b4c4137..c4c5026 100644
>> --- a/libsanitizer/interception/interception.h
>> +++ b/libsanitizer/interception/interception.h
>> @@ -28,8 +28,8 @@ typedef __sanitizer::s64 INTMAX_T;
>> // WARNING: OFF_T may be different from OS type off_t, depending on
>> the value of
>> // _FILE_OFFSET_BITS. This definition of OFF_T matches the ABI of system
>> calls
>> // like pread and mmap, as opposed to pread64 and mmap64.
>> -// Mac is special.
>> -#ifdef __APPLE__
>> +// Mac and Linux/x86-64 are special.
>> +#if defined(__APPLE__) || (defined(__linux__) && defined(__x86_64__))
>> typedef __sanitizer::u64 OFF_T;
>> #else
>> typedef __sanitizer::uptr OFF_T;
Here is the patch. OK to install?
Thanks.
--
H.J.
---
2013-02-14 H.J. Lu
PR bootstrap/56327
* interception/interception.h (OFF_T): Merged from upstream
r175140.
diff --git a/libsanitizer/interception/interception.h
b/libsanitizer/interception/interception.h
index b4c4137..c4c5026 100644
--- a/libsanitizer/interception/interception.h
+++ b/libsanitizer/interception/interception.h
@@ -28,8 +28,8 @@ typedef __sanitizer::s64 INTMAX_T;
// WARNING: OFF_T may be different from OS type off_t, depending on
the value of
// _FILE_OFFSET_BITS. This definition of OFF_T matches the ABI of system calls
// like pread and mmap, as opposed to pread64 and mmap64.
-// Mac is special.
-#ifdef __APPLE__
+// Mac and Linux/x86-64 are special.
+#if defined(__APPLE__) || (defined(__linux__) && defined(__x86_64__))
typedef __sanitizer::u64 OFF_T;
#else
typedef __sanitizer::uptr OFF_T;
Re: [AArch64] __atomic_thread_fence and release memory model
Oops, I missed that the release semantics is not just store before store but also load before store, sorry for that :( Yvan On 14 February 2013 16:40, Yvan Roux wrote: > Hi, > > a call to the builtin __atomic_thread_fence with the memory model > __ATOMIC_RELEASE generates a data memory barrier with the option ish > whereas I think that the one which has the "release" semantic is ishst > (store before store). The attached patch implements my proposal. > > Thanks, > Yvan > > -- > gcc/ > > 2013-02-14 Yvan Roux > > * config/aarch64/atomics.md (dmb): Emit release mode barrier.
Re: [PATCH,ARM] Set attribute predicable
On 14/02/13 13:53, Greta Yorsh wrote: This patch sets attribute "predicable" to "yes" for patterns that handle add with carry and already use %? in their output statements. Ok for trunk? Thanks, Greta gcc/ 2013-02-14 Greta Yorsh * config/arm/arm.md (addsi3_carryin_): Set attribute "predicable" to yes. (addsi3_carryin_alt2_,addsi3_carryin_shift_): Likewise. OK when stage1 opens. R.
Re: RFA: v3 PATCH to add on_quick_exit/quick_exit to std
Jason Merrill writes: > While I was going over the C++11 status page, I noticed that quick_exit is > implemented by glibc, it just needed to be added to the libstdc++ cstdlib > header. The test fails on Solaris 9: FAIL: 18_support/quick_exit/quick_exit.cc (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/quick_exit/quick_e xit.cc:28:3: error: '_Exit' is not a member of 'std' WARNING: 18_support/quick_exit/quick_exit.cc compilation failed to produce execu table extra_tool_flags are: -std=gnu++11 _Exit seems to be a C99 addition, only present since Solaris 10. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[AArch64] __atomic_thread_fence and release memory model
Hi, a call to the builtin __atomic_thread_fence with the memory model __ATOMIC_RELEASE generates a data memory barrier with the option ish whereas I think that the one which has the "release" semantic is ishst (store before store). The attached patch implements my proposal. Thanks, Yvan -- gcc/ 2013-02-14 Yvan Roux * config/aarch64/atomics.md (dmb): Emit release mode barrier. 0001-AArch64-fix-data-memory-barrier-release-mode.patch Description: Binary data
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Feb 14, 2013, at 3:47 PM, Steven Bosscher wrote: > On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote: >>> Is there a description for what has to be done in GCC to enable DWARF >>> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >>> Is there already a plan from someone to make GCC produce DWARF on >>> AIX7? >> >> Yes, you need to support the .dwsect pseudo (which is basically a dedicated >> pseudo like .section, but also includes section length). > > AFAIU your binutils patches support DWARF sections with .section > instead of .dwsect, right? Right. > What is the difficulty with implementing .dwsect for GCC? Shouldn't be very hard, as it is mostly a matter of not emitting section length. Tristan.
Re: [Patch, Fortran] PR56318 - Fix MATMUL regression
On Thu, Feb 14, 2013 at 3:50 PM, Tobias Burnus wrote: > This patch fixes the matmul bug, which was reported this morning. Seemingly, > the code never worked correctly. > > Regarding the result patch: Mikael and I came independently to the same > result thus it must be right (or not?); additionally, I tested and found out > that matrix-scalar/scalar-matrix was mishandled. > > Build and regtested on x86-64-gnu-linux. > OK for the trunk and the 4.6 and 4.7 branches? (I think we can ignore 4.5, > can we?) The 4.5 branch is closed. Richard. > Tobias > > PS: There is another bug, which prevents the simplification in some cases > (see PR), as it only results in a missed optimization (or reject valid in > constant expressions), I defer this to another patch.
[Patch, Fortran] PR56318 - Fix MATMUL regression
This patch fixes the matmul bug, which was reported this morning.
Seemingly, the code never worked correctly.
Regarding the result patch: Mikael and I came independently to the same
result thus it must be right (or not?); additionally, I tested and found
out that matrix-scalar/scalar-matrix was mishandled.
Build and regtested on x86-64-gnu-linux.
OK for the trunk and the 4.6 and 4.7 branches? (I think we can ignore
4.5, can we?)
Tobias
PS: There is another bug, which prevents the simplification in some
cases (see PR), as it only results in a missed optimization (or reject
valid in constant expressions), I defer this to another patch.
2013-02-14 Tobias Burnus
Mikael Morin
PR fortran/56318
* simplify.c (gfc_simplify_matmul): Fix result shape
and matmul result.
2013-02-14 Tobias Burnus
PR fortran/56318
* gcc/testsuite/gfortran.dg/matmul_9.f90: New.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index f7401e9..a0909a3 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -3850,7 +3850,7 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b)
if (matrix_a->rank == 1 && matrix_b->rank == 2)
{
result_rows = 1;
- result_columns = mpz_get_si (matrix_b->shape[0]);
+ result_columns = mpz_get_si (matrix_b->shape[1]);
stride_a = 1;
stride_b = mpz_get_si (matrix_b->shape[0]);
@@ -3860,7 +3860,7 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b)
}
else if (matrix_a->rank == 2 && matrix_b->rank == 1)
{
- result_rows = mpz_get_si (matrix_b->shape[0]);
+ result_rows = mpz_get_si (matrix_a->shape[0]);
result_columns = 1;
stride_a = mpz_get_si (matrix_a->shape[0]);
stride_b = 1;
@@ -3873,7 +3873,7 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b)
{
result_rows = mpz_get_si (matrix_a->shape[0]);
result_columns = mpz_get_si (matrix_b->shape[1]);
- stride_a = mpz_get_si (matrix_a->shape[1]);
+ stride_a = mpz_get_si (matrix_a->shape[0]);
stride_b = mpz_get_si (matrix_b->shape[0]);
result->rank = 2;
diff --git a/gcc/testsuite/gfortran.dg/matmul_9.f90 b/gcc/testsuite/gfortran.dg/matmul_9.f90
new file mode 100644
index 000..bf2a299
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/matmul_9.f90
@@ -0,0 +1,47 @@
+! { dg-do run }
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/56318
+!
+! Contributed by Alberto Luaces
+!
+SUBROUTINE mass_matrix
+ DOUBLE PRECISION,PARAMETER::m1=1.d0
+ DOUBLE PRECISION,DIMENSION(3,2),PARAMETER::A1=reshape([1.d0,0.d0, 0.d0, &
+ 0.d0,1.d0, 0.d0],[3,2])
+ DOUBLE PRECISION,DIMENSION(2,2),PARAMETER::Mel=reshape([1.d0/3.d0, 0.d0, &
+ 0.d0, 1.d0/3.d0],[2,2])
+
+ DOUBLE PRECISION,DIMENSION(3,3)::MM1
+
+ MM1=m1*matmul(A1,matmul(Mel,transpose(A1)))
+ !print '(3f8.3)', MM1
+ if (any (abs (MM1 &
+- reshape ([1.d0/3.d0, 0.d0, 0.d0, &
+0.d0, 1.d0/3.d0, 0.d0, &
+0.d0, 0.d0, 0.d0], &
+ [3,3])) > epsilon(1.0d0))) &
+call abort ()
+END SUBROUTINE mass_matrix
+
+program name
+ implicit none
+ integer, parameter :: A(3,2) = reshape([1,2,3,4,5,6],[3,2])
+ integer, parameter :: B(2,3) = reshape([3,17,23,31,43,71],[2,3])
+ integer, parameter :: C(3) = [-5,-7,-21]
+ integer, parameter :: m1 = 1
+
+! print *, matmul(B,C)
+ if (any (matmul(B,C) /= [-1079, -1793])) call abort()
+! print *, matmul(C,A)
+ if (any (matmul(C,A) /= [-82, -181])) call abort()
+! print '(3i5)', m1*matmul(A,B)
+ if (any (m1*matmul(A,B) /= reshape([71,91,111, 147,201,255, 327,441,555],&
+ [3,3]))) &
+ call abort()
+ call mass_matrix
+end program name
+
+! { dg-final { scan-tree-dump-times "matmul" 0 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
+
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote: >> Is there a description for what has to be done in GCC to enable DWARF >> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >> Is there already a plan from someone to make GCC produce DWARF on >> AIX7? > > Yes, you need to support the .dwsect pseudo (which is basically a dedicated > pseudo like .section, but also includes section length). AFAIU your binutils patches support DWARF sections with .section instead of .dwsect, right? What is the difficulty with implementing .dwsect for GCC? Ciao! Steven
C++ PATCH for c++/55680 (wrong error for lambda initializing data member specialization)
When we have a lambda-expression in the initializer for a specialization
of a class template static data member, we end up in
maybe_process_partial_specialization, which sees that
processing_specialization is set and concludes that we're trying to
specialize the lambda. But we aren't.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1631ee6dca428836c7733e5d78e8644af2058ae7
Author: Jason Merrill
Date: Wed Feb 13 13:25:20 2013 -0500
PR c++/55680
* pt.c (maybe_process_partial_specialization): A lambda
isn't what's being specialized.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2aadd4d..bd44fde 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -802,6 +802,11 @@ maybe_process_partial_specialization (tree type)
if (type == error_mark_node)
return error_mark_node;
+ /* A lambda that appears in specialization context is not itself a
+ specialization. */
+ if (CLASS_TYPE_P (type) && CLASSTYPE_LAMBDA_EXPR (type))
+return type;
+
if (TREE_CODE (type) == BOUND_TEMPLATE_TEMPLATE_PARM)
{
error ("name of class shadows template template parameter %qD",
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C
new file mode 100644
index 000..720941d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C
@@ -0,0 +1,7 @@
+// PR c++/55680
+// { dg-do compile { target c++11 } }
+
+template struct X {
+static void (* code ) ();
+};
+template <> void (* X::code ) () = [](){};
[PATCH,ARM] Set attribute predicable
This patch sets attribute "predicable" to "yes" for patterns that handle add with carry and already use %? in their output statements. Ok for trunk? Thanks, Greta gcc/ 2013-02-14 Greta Yorsh * config/arm/arm.md (addsi3_carryin_): Set attribute "predicable" to yes. (addsi3_carryin_alt2_,addsi3_carryin_shift_): Likewise.diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 1cb1515b1fa57c6052b68eb8701616c1b80e7416..35294dd6560ac63279d95eca6cf774257e06bd93 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -974,7 +974,8 @@ (define_insn "*addsi3_carryin_" "@ adc%?\\t%0, %1, %2 sbc%?\\t%0, %1, #%B2" - [(set_attr "conds" "use")] + [(set_attr "conds" "use") + (set_attr "predicable" "yes")] ) (define_insn "*addsi3_carryin_alt2_" @@ -986,7 +987,8 @@ (define_insn "*addsi3_carryin_alt2_" @@ -1000,6 +1002,7 @@ (define_insn "*addsi3_carryin_shift_
Re: [testsuite] Fix gcc.dg/debug/dwarf2/pr53948.c with Sun as
On Thu, Feb 14, 2013 at 12:48:01PM +0100, Rainer Orth wrote:
> Rainer Orth writes:
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
> @@ -1,7 +1,7 @@
> /* Test that we have line information for the line
> with local variable initializations. */
> /* { dg-options "-O0 -g -dA" } */
> -/* { dg-final { scan-assembler ".loc 1 8 0|\[#/!\] line 8" } } */
> +/* { dg-final { scan-assembler ".loc 1 8 0|\[#/!\]\[ \t\]+line 8" } } */
Given dwarf-char*.c regexps, perhaps that should be
\[#@;!/|\]+\[ \t\]+
instead of
\[#/!\]\[ \t\]+
Quick grep reveals m68k uses | and arm uses @.
Jakub
Re: [cxx-conversion] Add Record Builder Class
On Thu, Feb 14, 2013 at 8:06 AM, Richard Biener wrote: > On Thu, Feb 14, 2013 at 2:01 PM, Diego Novillo wrote: >> On Thu, Feb 14, 2013 at 7:52 AM, Richard Biener >> wrote: >> >>> Because it's otherwise almost unused. No "usual" gimple pass builds >>> up record types. What's the point in introducing the abstraction if >>> most of the users cannot use it? >> >> There may be few users on the gimple side, but you are mixing two >> orthogonal issues. Having a similar facility for FEs may be >> desirable, but not *this* one. >> >> Perhaps we could have a parent class provide a more generalized set of >> services. Each front end could use it or derive from it for its own >> use. The gimple version could do the same. Could that work? > > They all share layout_type so they should be able to share the record > builder. That's why I was proposing a hierarchy. It's true that there is shared behaviour we want, but I'm sure that there will be services needed by FEs that are not required in gimple. Diego.
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 8:21 AM, Tristan Gingold wrote: > > On Feb 14, 2013, at 12:26 PM, Steven Bosscher wrote: > >> On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: >>> The AIX system supports DWARF debugging, but GCC does not generate it >>> on AIX and GDB does not consume it on AIX. >> >> Is there a description for what has to be done in GCC to enable DWARF >> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >> Is there already a plan from someone to make GCC produce DWARF on >> AIX7? > > Yes, you need to support the .dwsect pseudo (which is basically a dedicated > pseudo like .section, but also includes section length). > > But note that .dwsect only allows a subset of all dwarf sections. AIX 6 and maybe even AIX 5.3 support DWARF. Because AIX uses XCOFF file format, not ELF, it had to fit DWARF support into the XCOFF design. >> AFAICT, for gcc+gas it should already work with binutils that include >> the AdaCore patch for DWARF support. But this has apparently not been >> tested with AIX ld, and there are AdaCore local patches pending. >> http://sourceware.org/ml/binutils/2011-04/msg00250.html >> http://www.sourceware.org/ml/gdb/2013-01/msg00030.html > > Yes. What is the status of merging Adacore's patches for DWARF support on AIX? Thanks, David
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Feb 14, 2013, at 12:26 PM, Steven Bosscher wrote: > On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: >> The AIX system supports DWARF debugging, but GCC does not generate it >> on AIX and GDB does not consume it on AIX. > > Is there a description for what has to be done in GCC to enable DWARF > with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? > Is there already a plan from someone to make GCC produce DWARF on > AIX7? Yes, you need to support the .dwsect pseudo (which is basically a dedicated pseudo like .section, but also includes section length). But note that .dwsect only allows a subset of all dwarf sections. > AFAICT, for gcc+gas it should already work with binutils that include > the AdaCore patch for DWARF support. But this has apparently not been > tested with AIX ld, and there are AdaCore local patches pending. > http://sourceware.org/ml/binutils/2011-04/msg00250.html > http://www.sourceware.org/ml/gdb/2013-01/msg00030.html Yes. Tristan.
Re: [patch] fix build of cross-compiler to AIX
On Thu, Feb 14, 2013 at 7:16 AM, Steven Bosscher wrote: > Hello, > > Building a cross-compiler from powerpc-linux to powerpc-aix fails with: > > ../../combined/gcc/collect2.c: In function 'void scan_prog_file(const > char*, scanpass, scanfilter)': > ../../combined/gcc/collect2.c:2860:8: error: 'F_LOADONLY' was not > declared in this scope > > This is due to: > 2013-02-03 David Edelsohn <> > Andrew Dixie <> > > * collect2.c (GCC_CHECK_HDR): Do not scan objects with F_LOADONLY > flag set. > > > Attached patch adds the definition, taken from the AIX 7.1 Information Center > (http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/XCOFF.htm) > > OK for trunk? > > Ciao! > Steven > > > > * collect2-aix.h: Define F_LOADONLY. Okay. Thanks, David
Re: [cxx-conversion] Add Record Builder Class
On Thu, Feb 14, 2013 at 2:01 PM, Diego Novillo wrote: > On Thu, Feb 14, 2013 at 7:52 AM, Richard Biener > wrote: > >> Because it's otherwise almost unused. No "usual" gimple pass builds >> up record types. What's the point in introducing the abstraction if >> most of the users cannot use it? > > There may be few users on the gimple side, but you are mixing two > orthogonal issues. Having a similar facility for FEs may be > desirable, but not *this* one. > > Perhaps we could have a parent class provide a more generalized set of > services. Each front end could use it or derive from it for its own > use. The gimple version could do the same. Could that work? They all share layout_type so they should be able to share the record builder. Richard. > > Diego.
Re: [cxx-conversion] Add Record Builder Class
On Thu, Feb 14, 2013 at 7:52 AM, Richard Biener wrote: > Because it's otherwise almost unused. No "usual" gimple pass builds > up record types. What's the point in introducing the abstraction if > most of the users cannot use it? There may be few users on the gimple side, but you are mixing two orthogonal issues. Having a similar facility for FEs may be desirable, but not *this* one. Perhaps we could have a parent class provide a more generalized set of services. Each front end could use it or derive from it for its own use. The gimple version could do the same. Could that work? Diego.
Re: libsanitizer merge from upstream r175042
On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
>> The patch seems to work on a simple test. Let me digest it.
>> I am trying to understand if there are problems with it other than the
>> added complexity (which is what I don't like the most).
>
> Yes, it is some added complexity, but not too much, and something that can
> be tested regularly that it works.
>
>> -Wl,-Ttext-segment=0x36 does not work with binutils-gold.
>> gold understands -Wl,-Ttext=0x36, but bfd ld doesn't.
>> Do you know any flag supported by both?
>
> -Wl,-Ttext is unfortunately something different, at least for
> the bfd linker. -Ttext-segment aligns the base of the whole shared library,
> if you look at start of the linker script for -shared:
> /* Read-only sections, merged into text segment: */
> . = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
> .note.gnu.build-id : { *(.note.gnu.build-id) }
> .hash : { *(.hash) }
> .gnu.hash : { *(.gnu.hash) }
> .dynsym : { *(.dynsym) }
> .dynstr : { *(.dynstr) }
> .gnu.version: { *(.gnu.version) }
> .gnu.version_d : { *(.gnu.version_d) }
> .gnu.version_r : { *(.gnu.version_r) }
> ...
> .rela.plt :
> {
> *(.rela.plt)
> *(.rela.iplt)
> }
> .init :
> {
> KEEP (*(.init))
> }
> .plt: { *(.plt) *(.iplt) }
> .text :
> {
> *(.text.unlikely .text.*_unlikely)
> *(.text.exit .text.exit.*)
> -Ttext-segment chooses the base at which ELF headers will reside.
> -Ttext aligns the .text section's start to that, so most likely the shared
> library won't even link, because .init section will be many GBs appart from
> .text section.
>
> CCing Ian, if gold has any way to do something similar.
> As I said, the alternative is to link the library normally, and run
> prelink -r 0x36 libtest.so on the shared library afterwards if
> prelink is
> installed, and make sure you install it on your linux/x86-64 test boxes.
Another way is to simply force using the bfd linker (on ubuntu, when
gold is the default linker, there is still bfd linker under
/usr/bin/ld.bfd).
Still, better to have something that works for both linkers.
--kcc
>
> Jakub
Re: [patch] fix build of cross-compiler to AIX
On Thu, Feb 14, 2013 at 1:16 PM, Steven Bosscher wrote: > Hello, > > Building a cross-compiler from powerpc-linux to powerpc-aix fails with: > > ../../combined/gcc/collect2.c: In function 'void scan_prog_file(const > char*, scanpass, scanfilter)': > ../../combined/gcc/collect2.c:2860:8: error: 'F_LOADONLY' was not > declared in this scope > > This is due to: > 2013-02-03 David Edelsohn <> > Andrew Dixie <> > > * collect2.c (GCC_CHECK_HDR): Do not scan objects with F_LOADONLY > flag set. > > > Attached patch adds the definition, taken from the AIX 7.1 Information Center > (http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/XCOFF.htm) > > OK for trunk? Ok. Thanks, Richard. > Ciao! > Steven > > > > * collect2-aix.h: Define F_LOADONLY. > > Index: collect2-aix.h > === > --- collect2-aix.h (revision 196048) > +++ collect2-aix.h (working copy) > @@ -229,7 +229,8 @@ > /* Definitions required by collect2. */ > #define C_EXT 2 > > -#define F_SHROBJ 0x2000 > +#define F_SHROBJ0x2000 > +#define F_LOADONLY 0x4000 > > #define N_UNDEF ((short) 0) > #define N_TMASK 060
Re: [cxx-conversion] Add Record Builder Class
On Thu, Feb 14, 2013 at 12:56 PM, Diego Novillo wrote: > On Thu, Feb 14, 2013 at 4:26 AM, Richard Biener > wrote: > >> Note that tag_name does not allow the way C++ uses this (it can be >> a TYPE_DECL). >> >> Overall I'm not sure this is a good abstraction unless you manage to >> make the frontends use it. > > I think that is a mistake. This is a pure gimple facility. The fact > that it now looks somewhat similar to what front ends do is a > consequence of the state of the gimple type system. > > We very specifically do not want to cater to front ends here. Why do > you think that should be a feature of this interface? Because it's otherwise almost unused. No "usual" gimple pass builds up record types. What's the point in introducing the abstraction if most of the users cannot use it? Richard. > > Diego.
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 02/14/13 03:52, Jakub Jelinek wrote: No, it prevents *reading* of PCH files with -gstabs, so whatever you write into the PCH file is uninteresting. The patch can surely be acompanied by a patch to warn that writing a PCH file is useless in that case, as in your patch, though the spot you chose for it is too early. Consider ./xgcc -B ./ -gstabs -o aa.h.gch aa.h -g0 [ ... ] It's a fairly minor point, but I see what you're saying. Supposedly not do any testing if -g (defaulting to non-dwarf) or -gstabs etc. are present in the default options (try to pre-compile some short header first, if that fails with the newly added warning, punt), drop all torture options using -g in it if such test fails with explicit -g added from the list of torture options for testing, and perhaps add some effective target if needed (valid-1.c test?). I think two tests should be sufficient. First, compile a simple program with -g and verify it generates dwarf2 debug records. Second verify that there aren't any -g options, unless is dwarf2. I'm actually on PTO today/tomorrow, so I won't be able to look further at this until Monday. If someone wants to run with it, my recommendation would be Steven's warning patch, moved to the location Jakub suggests so that users know stabs+PCH is going away plus a hack to the testsuite suite similar to what I outlined above plus something to either suppress creation of the pch or suppress reading the PCH in the presence of non-dwarf debug output. -- Jakub -- presumably the implicit include of stdc-predef.h is what is causing the testing differences we were seeing. Jeff
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On 02/13/13 16:17, John David Anglin wrote: On 2013-02-13 3:33 PM, David Edelsohn wrote: Perhaps Dave can explain what would have to be done to move this platform to DWARF2...? I had looked at this a bit in the past. I don't think it's that difficult to add DWARF2 support to GCC on hppa. Although we don't support named sections, we can create named subspaces for the dwarf info. More of an issue in my mind is the changes needed to gdb to recognize this support. Given that we can create a subspace for the dwarf bits just like we've got subspaces for stabs bits, it ought to be trivial. The GDB side shouldn't be hard either, just a matter of telling it what subspaces to look for. jeff
Re: libsanitizer merge from upstream r175042
On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
> The patch seems to work on a simple test. Let me digest it.
> I am trying to understand if there are problems with it other than the
> added complexity (which is what I don't like the most).
Yes, it is some added complexity, but not too much, and something that can
be tested regularly that it works.
> -Wl,-Ttext-segment=0x36 does not work with binutils-gold.
> gold understands -Wl,-Ttext=0x36, but bfd ld doesn't.
> Do you know any flag supported by both?
-Wl,-Ttext is unfortunately something different, at least for
the bfd linker. -Ttext-segment aligns the base of the whole shared library,
if you look at start of the linker script for -shared:
/* Read-only sections, merged into text segment: */
. = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version: { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
...
.rela.plt :
{
*(.rela.plt)
*(.rela.iplt)
}
.init :
{
KEEP (*(.init))
}
.plt: { *(.plt) *(.iplt) }
.text :
{
*(.text.unlikely .text.*_unlikely)
*(.text.exit .text.exit.*)
-Ttext-segment chooses the base at which ELF headers will reside.
-Ttext aligns the .text section's start to that, so most likely the shared
library won't even link, because .init section will be many GBs appart from
.text section.
CCing Ian, if gold has any way to do something similar.
As I said, the alternative is to link the library normally, and run
prelink -r 0x36 libtest.so on the shared library afterwards if prelink
is
installed, and make sure you install it on your linux/x86-64 test boxes.
Jakub
[patch] fix build of cross-compiler to AIX
Hello, Building a cross-compiler from powerpc-linux to powerpc-aix fails with: ../../combined/gcc/collect2.c: In function 'void scan_prog_file(const char*, scanpass, scanfilter)': ../../combined/gcc/collect2.c:2860:8: error: 'F_LOADONLY' was not declared in this scope This is due to: 2013-02-03 David Edelsohn <> Andrew Dixie <> * collect2.c (GCC_CHECK_HDR): Do not scan objects with F_LOADONLY flag set. Attached patch adds the definition, taken from the AIX 7.1 Information Center (http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/XCOFF.htm) OK for trunk? Ciao! Steven * collect2-aix.h: Define F_LOADONLY. Index: collect2-aix.h === --- collect2-aix.h (revision 196048) +++ collect2-aix.h (working copy) @@ -229,7 +229,8 @@ /* Definitions required by collect2. */ #define C_EXT 2 -#define F_SHROBJ 0x2000 +#define F_SHROBJ0x2000 +#define F_LOADONLY 0x4000 #define N_UNDEF ((short) 0) #define N_TMASK 060
Re: [PATCH] Fix PR50494
On Thu, Feb 14, 2013 at 12:53:47PM +0100, Richard Biener wrote: > > (completely untested). Because, if we force the constant to be aligned > > more than it would be by default, the RTL optimizers should be told about > > that too. > > At the moment the vectorizer refuses to bump alignment for anything > with TREE_ASM_WRITTEN set. I suppose that should rather be checking > DECL_RTL_SET_P. Btw, isn't the constants descriptor ->rtl always > that of DECL_RTL of the decl? But at that point the decls aren't TREE_ASM_WRITTEN, and don't have DECL_RTL (otherwise, it would be enough to bump alignment of DECL_RTL). The rtl is nevertheless already created at that point, by build_constant_desc (in this case called by tree_output_constant_def). Jakub
Re: C++ PATCH for c++/56135 (wrong 'this' capture)
Hi jason, The test g++.dg/cpp0x/lambda/lambda-this8.C fails on x86_64-apple-darwin10: FAIL: g++.dg/cpp0x/lambda/lambda-this8.C -std=c++11 (test for excess errors) Excess errors: /opt/gcc/work/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C:6:31: error: declaration of 'void abort() throw ()' has a different exception specifier /usr/include/stdlib.h:145:7: error: from previous declaration 'void abort()' UNRESOLVED: g++.dg/cpp0x/lambda/lambda-this8.C -std=c++11 compilation failed to produce executable TIA Dominique
Re: [cxx-conversion] Add Record Builder Class
On Thu, Feb 14, 2013 at 4:26 AM, Richard Biener wrote: > Note that tag_name does not allow the way C++ uses this (it can be > a TYPE_DECL). > > Overall I'm not sure this is a good abstraction unless you manage to > make the frontends use it. I think that is a mistake. This is a pure gimple facility. The fact that it now looks somewhat similar to what front ends do is a consequence of the state of the gimple type system. We very specifically do not want to cater to front ends here. Why do you think that should be a feature of this interface? Diego.
Re: libsanitizer merge from upstream r175042
The patch seems to work on a simple test. Let me digest it. I am trying to understand if there are problems with it other than the added complexity (which is what I don't like the most). -Wl,-Ttext-segment=0x36 does not work with binutils-gold. gold understands -Wl,-Ttext=0x36, but bfd ld doesn't. Do you know any flag supported by both? --kcc On Thu, Feb 14, 2013 at 12:48 PM, Jakub Jelinek wrote: > On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote: >> Here is the patch, works just fine for me here during asan.exp testing. >> You can very easily either install and enable prelink on one of your >> x86_64-linux testing boxes, or just install it and add test that >> will say prelink -r 0x36 some test shared library and then >> just use it in sanitized program (that will also verify that you can mmap >> libraries in that range), or even just write a test that will in a >> non-instrumented ctor with lower priority than asan's priority >> mmap a few pages at 0x30 and close to 0x3f >> and store some data into those buffers later on in sanitized code. > > I forgot you don't even need prelink -r 0x36 for the testing, you > can just link it as > $(CXX) -shared -Wl,-Ttext-segment=0x36 -fPIC -o testlib.so > -fsanitize=address testlib.C > So, put some asan tests into the executable, some tests into the shared > library and link the executable against the shared library placed in the > area where prelink allocates addresses to shared libraries. > Perhaps build 3 such libraries, one at 0x30, one somewhere middle > of that range and one close to the end of the range. > > Jakub
Re: [PATCH] Fix PR50494
On Thu, 14 Feb 2013, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 01:04:04PM +0100, Richard Biener wrote:
> > 2013-02-13 Richard Biener
> >
> > PR lto/50494
> > * varasm.c (output_constant_def_1): Get the decl representing
> > the constant as argument.
> > (output_constant_def): Wrap output_constant_def_1.
> > (make_decl_rtl): Use output_constant_def_1 with the decl
> > representing the constant.
> > (build_constant_desc): Optionally re-use a decl already
> > representing the constant.
> > (tree_output_constant_def): Adjust.
>
> Looks good to me, except formatting nit:
>
> > + /* Like output_constant_def but create a new decl representing the
> > +constant if necessary. */
> > +
> > + rtx
> > + output_constant_def (tree exp, int defer)
> > + {
> > + return output_constant_def_1 (exp, NULL_TREE, defer);
>
> Twice too many spaces.
>
> But I'd say we should also add some varasm.c function that
> increase_alignment should call for
> (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl))
> vars upon increasing alignment of the decl, which would do something like:
> void
> adjust_const_pool_alignment (tree decl)
> {
> struct constant_descriptor_tree *desc, key;
>
> gcc_assert (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl));
> key.value = DECL_INITIAL (decl);
> key.hash = const_hash_1 (DECL_INITIAL (decl));
> desc = (struct constant_descriptor_tree *)
>htab_find_with_hash (const_desc_htab, &key, key.hash);
> if (desc && MEM_P (desc) && MEM_ALIGN (desc->rtl) < DECL_ALIGN (decl))
> set_mem_align (desc->rtl, DECL_ALIGN (decl));
> }
> (completely untested). Because, if we force the constant to be aligned
> more than it would be by default, the RTL optimizers should be told about
> that too.
At the moment the vectorizer refuses to bump alignment for anything
with TREE_ASM_WRITTEN set. I suppose that should rather be checking
DECL_RTL_SET_P. Btw, isn't the constants descriptor ->rtl always
that of DECL_RTL of the decl?
But yes, we should have a proper abstraction for can_adjust_alignment
and adjust_alignment. But we should use that for all decls, not
just DECL_IN_CONSTANT_POOL.
Thanks,
Richard.
Re: [testsuite] Fix gcc.dg/debug/dwarf2/pr53948.c with Sun as
Rainer Orth writes:
> The new gcc.dg/debug/dwarf2/pr53948.c test was failing on Solaris with
> Sun as: i386 uses / as comment character, while sparc uses !. The
> following patch accounts for that.
>
> Tested on i386-pc-solaris2.10, sparc-sun-solaris2.11, and
> x86_64-unknown-linux-gnu, installed on mainline.
It turned out I need one further adjustment to make the test pass on
i386-pc-solaris2.9, which uses "/ " comments instead of just "/".
Tested with the appropriate runtest invocations on i386-pc-solaris2.9,
i386-pc-solaris2.10, sparc-sun-solaris2.11, and
x86_64-unknown-linux-gnu, installed on mainline.
Rainer
2013-02-14 Rainer Orth
* gcc.dg/debug/dwarf2/pr53948.c: Allow for more whitespace.
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
@@ -1,7 +1,7 @@
/* Test that we have line information for the line
with local variable initializations. */
/* { dg-options "-O0 -g -dA" } */
-/* { dg-final { scan-assembler ".loc 1 8 0|\[#/!\] line 8" } } */
+/* { dg-final { scan-assembler ".loc 1 8 0|\[#/!\]\[ \t\]+line 8" } } */
int f (register int a, register int b) {
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix PR50494
On Wed, Feb 13, 2013 at 01:04:04PM +0100, Richard Biener wrote:
> 2013-02-13 Richard Biener
>
> PR lto/50494
> * varasm.c (output_constant_def_1): Get the decl representing
> the constant as argument.
> (output_constant_def): Wrap output_constant_def_1.
> (make_decl_rtl): Use output_constant_def_1 with the decl
> representing the constant.
> (build_constant_desc): Optionally re-use a decl already
> representing the constant.
> (tree_output_constant_def): Adjust.
Looks good to me, except formatting nit:
> + /* Like output_constant_def but create a new decl representing the
> +constant if necessary. */
> +
> + rtx
> + output_constant_def (tree exp, int defer)
> + {
> + return output_constant_def_1 (exp, NULL_TREE, defer);
Twice too many spaces.
But I'd say we should also add some varasm.c function that
increase_alignment should call for
(TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl))
vars upon increasing alignment of the decl, which would do something like:
void
adjust_const_pool_alignment (tree decl)
{
struct constant_descriptor_tree *desc, key;
gcc_assert (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl));
key.value = DECL_INITIAL (decl);
key.hash = const_hash_1 (DECL_INITIAL (decl));
desc = (struct constant_descriptor_tree *)
htab_find_with_hash (const_desc_htab, &key, key.hash);
if (desc && MEM_P (desc) && MEM_ALIGN (desc->rtl) < DECL_ALIGN (decl))
set_mem_align (desc->rtl, DECL_ALIGN (decl));
}
(completely untested). Because, if we force the constant to be aligned
more than it would be by default, the RTL optimizers should be told about
that too.
Jakub
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: > The AIX system supports DWARF debugging, but GCC does not generate it > on AIX and GDB does not consume it on AIX. Is there a description for what has to be done in GCC to enable DWARF with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? Is there already a plan from someone to make GCC produce DWARF on AIX7? AFAICT, for gcc+gas it should already work with binutils that include the AdaCore patch for DWARF support. But this has apparently not been tested with AIX ld, and there are AdaCore local patches pending. http://sourceware.org/ml/binutils/2011-04/msg00250.html http://www.sourceware.org/ml/gdb/2013-01/msg00030.html > If you want to disable PCH on STABS systems on just AIX, that is fine. This is probably what we'll end up doing, one way or another. That's good enough for the goals I'm trying to achieve in the short term (which means up to 2 years in my case ;-). Ciao! Steven
RE: [patch][wwwdocs] gcc 4.8 changes - AMD new cores
Thank you Gerald! Committed with the changes. Regards Ganesh -Original Message- From: Gerald Pfeifer [mailto:ger...@pfeifer.com] Sent: Thursday, February 14, 2013 2:40 PM To: Gopalasubramanian, Ganesh Cc: gcc-patchesUros Bizjak Subject: RE: [patch][wwwdocs] gcc 4.8 changes - AMD new cores On Thu, 14 Feb 2013, Gopalasubramanian, Ganesh wrote: > Is it OK for wwdocs? Looks good to me if you say "...through the... options" (adding "the" in two cases) and breaking the lines to not exceed 76 columns. Thanks, Gerald
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 11:19:22AM +0100, Steven Bosscher wrote: > On Thu, Feb 14, 2013 at 12:48 AM, Jakub Jelinek wrote: > > On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote: > >> > I agree with David that it might be better to give up pch. > >> > >> That'd be a really a good start. > > > > You can do it with say following patch instead, PCH is just a compile time > > optimization, so for -gstabs IMHO it is just fine if we just give up. > > Does that also provent *writing* a PCH with -gstabs? No, it prevents *reading* of PCH files with -gstabs, so whatever you write into the PCH file is uninteresting. The patch can surely be acompanied by a patch to warn that writing a PCH file is useless in that case, as in your patch, though the spot you chose for it is too early. Consider ./xgcc -B ./ -gstabs -o aa.h.gch aa.h -g0 cc1: warning: the "stabs" debug format cannot be used with pre-compiled headers [-Wdeprecated] which warns even when the header is actually precompiled without debug info. If you try to use such PCH file with say ./xgcc -B ./ -gstabs aa.c it will fail to load PCH because of option mismatch (similarly for -g created PCH file and non-g user), but if you do ./xgcc -B ./ -gstabs aa.c -g0 there should be no reason why it wouldn't work right, so you shouldn't warn earlier. So, IMHO you want to warn at the spot which I've changed in my patch, add if (pch_file && (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)) warning... there. And, of course, pch.exp testsuite won't work if -gstabs etc. is in effect, because it does those hacks which ensure that if PCH isn't loaded, tests fail (the original header file isn't available when testing PCH load). That is not a problem for normal PCH uses, where the headers are available, but pch.exp would need to be tweaked for it somehow. Supposedly not do any testing if -g (defaulting to non-dwarf) or -gstabs etc. are present in the default options (try to pre-compile some short header first, if that fails with the newly added warning, punt), drop all torture options using -g in it if such test fails with explicit -g added from the list of torture options for testing, and perhaps add some effective target if needed (valid-1.c test?). Jakub
Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)
On Thu, Feb 14, 2013 at 12:48 AM, Jakub Jelinek wrote: > On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote: >> > I agree with David that it might be better to give up pch. >> >> That'd be a really a good start. > > You can do it with say following patch instead, PCH is just a compile time > optimization, so for -gstabs IMHO it is just fine if we just give up. Does that also provent *writing* a PCH with -gstabs? The point of making asm_out_file write-only and stop front ends from writing to it, is to postpone opening asm_out_file to some point as late as possible. For this to work, attempting to write a PCH must also be disabled (because of the early stabs output to asm_out_file). Ciao! Steven
[Patch, Fortran, committed] PR56138 - fix deferred-length character result
This patch undoes the patch
http://gcc.gnu.org/ml/fortran/2013-01/msg00219.html which doesn't fix
the original problem. (The ICE only occurs if the function is not an
internal or module procedure!)
As Paul's variant (cf. PR) fixes the issue, this patch now undoes my
patch and uses his. Additionally, it adds a modified test case (by
Dominique) which uses a bare, non-contained function.
Build and regtested on x86-64-gnu-linux.
Tobias
Index: gcc/testsuite/gfortran.dg/allocatable_function_7.f90
===
--- gcc/testsuite/gfortran.dg/allocatable_function_7.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/allocatable_function_7.f90 (Revision 196047)
@@ -0,0 +1,28 @@
+! { dg-do run }
+!
+! PR fortran/56138
+!
+! Contributed by Dominique d'Humieres and John Chludzinski,
+! using the code of John Reid
+!
+implicit none
+interface
+PURE FUNCTION s_to_c(string)
+ CHARACTER(LEN=*),INTENT(IN) :: string
+ CHARACTER(LEN=:),ALLOCATABLE :: s_to_c
+ENDFUNCTION s_to_c
+end interface
+CHARACTER(LEN=:),ALLOCATABLE :: str
+if (s_to_c("ABCdef") /= "ABCdef" .or. len(s_to_c("ABCdef")) /= 6) call abort()
+str = s_to_c("ABCdef")
+if (str /= "ABCdef" .or. len(str) /= 6) call abort()
+str(1:3) = s_to_c("123")
+if (str /= "123def" .or. len(str) /= 6) call abort()
+
+end
+
+PURE FUNCTION s_to_c(string)
+ CHARACTER(LEN=*),INTENT(IN) :: string
+ CHARACTER(LEN=:),ALLOCATABLE :: s_to_c
+ s_to_c = string
+END FUNCTION s_to_c
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 196046)
+++ gcc/testsuite/ChangeLog (Revision 196047)
@@ -1,3 +1,9 @@
+2013-02-14 Dominique d'Humieres
+ Tobias Burnus
+
+ PR testsuite/56138
+ * gfortran.dg/allocatable_function_7.f90: New.
+
2013-02-14 Jakub Jelinek
* g++.dg/asan/dejagnu-gtest.h: Add multiple inclusion guards.
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 196046)
+++ gcc/fortran/ChangeLog (Revision 196047)
@@ -1,3 +1,17 @@
+2013-02-14 Paul Thomas
+ Tobias Burnus
+
+ PR testsuite/56138
+ * trans-decl.c (gfc_get_symbol_decl): Fix deferred-length
+ results for functions without extra result variable.
+
+ Revert:
+ 2013-01-30 Tobias Burnus
+
+ PR fortran/56138
+ * trans-decl.c (gfc_trans_deferred_vars): Fix deferred-length
+ results for functions without extra result variable.
+
2013-02-12 Janus Weil
PR fortran/46952
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (Revision 196046)
+++ gcc/fortran/trans-decl.c (Revision 196047)
@@ -1205,6 +1205,7 @@
tree attributes;
int byref;
bool intrinsic_array_parameter = false;
+ bool fun_or_res;
gcc_assert (sym->attr.referenced
|| sym->attr.flavor == FL_PROCEDURE
@@ -1244,7 +1245,9 @@
length = gfc_create_string_length (sym);
}
- if ((sym->attr.dummy && ! sym->attr.function) || (sym->attr.result && byref))
+ fun_or_res = byref && (sym->attr.result
+ || (sym->attr.function && sym->ts.deferred));
+ if ((sym->attr.dummy && ! sym->attr.function) || fun_or_res)
{
/* Return via extra parameter. */
if (sym->attr.result && byref
@@ -1270,7 +1273,7 @@
(sym->ts.u.cl->passed_length == sym->ts.u.cl->backend_decl))
sym->ts.u.cl->backend_decl = NULL_TREE;
- if (sym->ts.deferred && sym->attr.result
+ if (sym->ts.deferred && fun_or_res
&& sym->ts.u.cl->passed_length == NULL
&& sym->ts.u.cl->backend_decl)
{
@@ -3775,7 +3778,7 @@
null_pointer_node));
}
- if ((sym->attr.dummy || sym->attr.result || sym->result == sym)
+ if ((sym->attr.dummy ||sym->attr.result)
&& sym->ts.type == BT_CHARACTER
&& sym->ts.deferred)
{
[testsuite] Fix gcc.dg/debug/dwarf2/pr53948.c with Sun as
The new gcc.dg/debug/dwarf2/pr53948.c test was failing on Solaris with
Sun as: i386 uses / as comment character, while sparc uses !. The
following patch accounts for that.
Tested on i386-pc-solaris2.10, sparc-sun-solaris2.11, and
x86_64-unknown-linux-gnu, installed on mainline.
Rainer
2013-02-13 Rainer Orth
* gcc.dg/debug/dwarf2/pr53948.c: Allow for / and ! as comment
characters.
# HG changeset patch
# Parent ed5415e505004fb993791f63f62bc9a6da314167
Fix gcc.dg/debug/dwarf2/pr53948.c with Sun as
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr53948.c
@@ -1,7 +1,7 @@
/* Test that we have line information for the line
with local variable initializations. */
/* { dg-options "-O0 -g -dA" } */
-/* { dg-final { scan-assembler ".loc 1 8 0|# line 8" } } */
+/* { dg-final { scan-assembler ".loc 1 8 0|\[#/!\] line 8" } } */
int f (register int a, register int b) {
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: RFC: [MIPS] Add an option to disable ldc1/sdc1
Chao-Ying Fu writes: > Hello All, > > Once in a while we got reports about programs (ex: WebKit, FireFox) > crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root > cause is that programmers neglect the alignment issue and cast > arbitrary pointers to point to double variables. > > Although the correct solution is to fix application source code to > fulfill alignment requirements, we want to add a GCC option to disable > ldc1 and sdc1 (for the testing purpose or for workaround). On 32-bit > MIPS targets, GCC generates lwc1 and swc1 when -mno-ldc1-sdc1 is used, > so that the memory address can be just 4-byte aligned to avoid > ldc1/sdc1 address exceptions. Sounds OK to me, given that the impact of the option is so low. Bikeshed time, but I'd prefer the option to be named after the thing that we're guaranteeing, rather than an instruction. E.g. if the problem is that doubles might only be 32-bit aligned, we could have -mmisaligned-double (better suggestions welcome). What about 64-bit targets? We can sometimes access doubles using GPRs, so on 64-bit targets we could end up using LD and SD to access a double even when this option disables LDC1 and SDC1. I think we'd need to patch the move patterns as well. If you only see the problem on 32-bit targets, then maybe it would be better to have an option that prevents instructions that require greater than word alignment. Say (for sake of argument) -mno-superword-align. Then it would be: #define ISA_HAS_LDC1_SDC1 \ (!ISA_MIPS1 && !TARGET_MIPS16 && (TARGET_64BIT || TARGET_SUPERWORD_ALIGN)) Thanks, Richard
Re: [PING^2] Allow widening multiplication in tree-ssa/slsr-*.c
On Thu, Feb 14, 2013 at 7:29 AM, Hurugalawadi, Naveen wrote: > Hi, > > Please consider this as a gentle reminder to review the patch > posted at following link:- > http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00823.html > > Please review the patch and let me know if its okay? Ok. Thanks, Richard. > Thanks & Regards, > Naveen.H.S >
Re: [cxx-conversion] Add Record Builder Class
On Tue, Feb 12, 2013 at 8:47 PM, Lawrence Crowl wrote:
> Add class record_builder to ease construction of records and unions. Use it
> in some appropriate places.
>
> Nathan please review the vxworks changes.
>
> tree.h
> New class record_builder.
>
> tree.c
> Implement record_builder member functions.
>
> asan.c
> Change asan_global_struct to use record_builder.
>
> coverage.c
> Change build_info_type() to use record_builder. It now takes a
> record_builder as a parameter and returns the tree representing
> the type.
>
> Change build_fn_info_type() to use record_builder. It now returns
> the tree representing the type.
>
> Modify coverage_obj_init() to call them appropriately.
>
> tree-mudflap.c
> Change mf_make_mf_cache_struct_type() to use record_builder.
>
> target.def
> Replace the emutls var_fields hook with object_type hook. The
> essential difference is that the hook is now responsible for full
> construction of the type, not just adding fields.
>
> targhooks.h
> Replace default_emutls_var_fields() with default_emutls_object_type().
>
> tree-emutls.c
> Replace default_emutls_var_fields() with default_emutls_object_type().
> Use record_builder within default_emutls_object_type().
>
> Change get_emutls_object_type to use the new target hook.
>
> doc/tm.texi.in
> Replace TARGET_EMUTLS_VAR_FIELDS with TARGET_EMUTLS_OBJECT_TYPE.
>
> doc/tm.texi
> Replace TARGET_EMUTLS_VAR_FIELDS with TARGET_EMUTLS_OBJECT_TYPE.
>
> config/vxworks.c
> Replace vxworks_emutls_var_fields() with vxworks_emutls_object_type().
> Use record_builder within vxworks_emutls_object_type().
>
> Tested on x86_64. Tested with config-list.mk on vxworks targets.
>
>
> Index: gcc/tree-emutls.c
> ===
> --- gcc/tree-emutls.c (revision 195904)
> +++ gcc/tree-emutls.c (working copy)
> @@ -103,41 +103,22 @@ get_emutls_object_name (tree name)
>return prefix_name (prefix, name);
> }
>
> -/* Create the fields of the type for the control variables. Ordinarily
> +/* Create the type for the control variables. Ordinarily
> this must match struct __emutls_object defined in emutls.c. However
> this is a target hook so that VxWorks can define its own layout. */
>
> tree
> -default_emutls_var_fields (tree type, tree *name ATTRIBUTE_UNUSED)
> +default_emutls_object_type (void)
> {
> - tree word_type_node, field, next_field;
> -
> - field = build_decl (UNKNOWN_LOCATION,
> - FIELD_DECL, get_identifier ("__templ"), ptr_type_node);
> - DECL_CONTEXT (field) = type;
> - next_field = field;
> -
> - field = build_decl (UNKNOWN_LOCATION,
> - FIELD_DECL, get_identifier ("__offset"),
> - ptr_type_node);
> - DECL_CONTEXT (field) = type;
> - DECL_CHAIN (field) = next_field;
> - next_field = field;
> -
> - word_type_node = lang_hooks.types.type_for_mode (word_mode, 1);
> - field = build_decl (UNKNOWN_LOCATION,
> - FIELD_DECL, get_identifier ("__align"),
> - word_type_node);
> - DECL_CONTEXT (field) = type;
> - DECL_CHAIN (field) = next_field;
> - next_field = field;
> -
> - field = build_decl (UNKNOWN_LOCATION,
> - FIELD_DECL, get_identifier ("__size"), word_type_node);
> - DECL_CONTEXT (field) = type;
> - DECL_CHAIN (field) = next_field;
> -
> - return field;
> + tree word_type_node = lang_hooks.types.type_for_mode (word_mode, 1);
> + record_builder rec;
> + rec.add_field ("__size", word_type_node);
> + rec.add_field ("__align", word_type_node);
> + rec.add_field ("__offset", ptr_type_node);
> + rec.add_field ("__templ", ptr_type_node);
> + rec.layout ();
That's awkward - you want to hide the fact that layout has to happen
and that it has to happen "last". Just make it a side-effect of
.as_tree (). Note that add_field want's to return the FIELD_DECL
created, people may want to alter it.
Note that tag_name does not allow the way C++ uses this (it can be
a TYPE_DECL).
Overall I'm not sure this is a good abstraction unless you manage to
make the frontends use it.
Richard.
> + rec.decl_name ("__emutls_object");
> + return rec.as_tree ();
> }
>
> /* Initialize emulated tls object TO, which refers to TLS variable DECL and
> @@ -182,24 +163,9 @@ default_emutls_var_init (tree to, tree d
> static tree
> get_emutls_object_type (void)
> {
> - tree type, type_name, field;
> -
> - type = emutls_object_type;
> - if (type)
> -return type;
> -
> - emutls_object_type = type = lang_hooks.types.make_type (RECORD_TYPE);
> - type_name = NULL;
> - field = targetm.emutls.var_fields (type, &type_name);
> - if (!type_name)
> -type_name = get_identifier ("__emutls_object");
> - type_name = build_decl (UNKNOWN_LOCATION,
> - TYPE_DECL, type_name
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote: > Here is the patch, works just fine for me here during asan.exp testing. > You can very easily either install and enable prelink on one of your > x86_64-linux testing boxes, or just install it and add test that > will say prelink -r 0x36 some test shared library and then > just use it in sanitized program (that will also verify that you can mmap > libraries in that range), or even just write a test that will in a > non-instrumented ctor with lower priority than asan's priority > mmap a few pages at 0x30 and close to 0x3f > and store some data into those buffers later on in sanitized code. I forgot you don't even need prelink -r 0x36 for the testing, you can just link it as $(CXX) -shared -Wl,-Ttext-segment=0x36 -fPIC -o testlib.so -fsanitize=address testlib.C So, put some asan tests into the executable, some tests into the shared library and link the executable against the shared library placed in the area where prelink allocates addresses to shared libraries. Perhaps build 3 such libraries, one at 0x30, one somewhere middle of that range and one close to the end of the range. Jakub
Re: [PATCH] Backport asan_test.cc changes from upstream
On Thu, Feb 14, 2013 at 12:41 PM, Jakub Jelinek wrote: > On Thu, Feb 14, 2013 at 12:17:27PM +0400, Konstantin Serebryany wrote: >> On Wed, Feb 13, 2013 at 8:03 PM, Jakub Jelinek wrote: >> > Hi! >> > >> > This patch backports the asan_test.cc changes since 2013-01-10 from >> > upstream. Unfortunately, it seems the tests can't really go standalone, >> > the 3 new tests actually use functions defined in asan_test.cc, so for now >> > asan_test.C just includes all the new tests. >> >> That's fine, although we may break it unwillingly in future. >> Btw, the reason for splitting this test was that it took too long (> >> 10s) to build it with debug (-O0) version of clang. > > So, how exactly are the tests linked with clang? Just separate object > files, linked into the same binary test, or somehow else? Not familiar with > cmake... Yes, these tests are linked into a single binary. The llvm test runner runs them in parallel relying on the gtest sharding feature. --kcc > >> Done: http://llvm.org/viewvc/llvm-project?rev=175142&view=rev > > Thanks, now the difference in the files between gcc/testsuite/g++.dg/asan/ > and compiler-rt/lib/asan/tests which have the same name is really just > the two lines in the boilerplates. > > Jakub
Re: [committed] Revert 0x7fff8000 shadow offset for now
Thanks!
This'll let us think about fixing 7fff8000+prelink w/o a rush.
Still, can we switch to using asan-rt in
ASAN_FLEXIBLE_MAPPING_AND_OFFSET=1 mode?
This way we will have fewer differences between gcc variant and upstream
and will be able to change the offset w/o changing the rt at all.
(and this will allow simpler experiments with zero base in gcc).
--kcc
On Wed, Feb 13, 2013 at 8:07 PM, Jakub Jelinek wrote:
> Hi!
>
> So that we don't keep GCC trunk in known broken state, I've
> bootstrapped/regtested this change and installed it.
>
> 2013-02-13 Jakub Jelinek
>
> * config/i386/i386.c (ix86_asan_shadow_offset): Revert last change.
>
> * asan/asan_mapping.h (SHADOW_OFFSET): Set to (1ULL << 44) on x86-64.
>
> --- gcc/config/i386/i386.c.jj 2013-02-13 11:53:42.0 +0100
> +++ gcc/config/i386/i386.c 2013-02-13 14:15:19.670007874 +0100
> @@ -5436,8 +5436,7 @@ ix86_legitimate_combined_insn (rtx insn)
> static unsigned HOST_WIDE_INT
> ix86_asan_shadow_offset (void)
> {
> - return TARGET_LP64 ? (TARGET_MACHO ? (HOST_WIDE_INT_1 << 44)
> -: HOST_WIDE_INT_C (0x7fff8000))
> + return TARGET_LP64 ? (HOST_WIDE_INT_1 << 44)
> : (HOST_WIDE_INT_1 << 29);
> }
>
> --- libsanitizer/asan/asan_mapping.h.jj 2013-02-13 11:53:43.0 +0100
> +++ libsanitizer/asan/asan_mapping.h2013-02-13 14:20:34.032179688 +0100
> @@ -36,11 +36,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE upt
> # if defined(__powerpc64__)
> #define SHADOW_OFFSET (1ULL << 41)
> # else
> -#if ASAN_MAC
> -# define SHADOW_OFFSET (1ULL << 44)
> -#else
> -# define SHADOW_OFFSET 0x7fff8000ULL
> -#endif
> +#define SHADOW_OFFSET (1ULL << 44)
> # endif
> # endif
> # endif
>
> Jakub
Re: [PATCH] Backport asan_test.cc changes from upstream
On Thu, Feb 14, 2013 at 12:17:27PM +0400, Konstantin Serebryany wrote: > On Wed, Feb 13, 2013 at 8:03 PM, Jakub Jelinek wrote: > > Hi! > > > > This patch backports the asan_test.cc changes since 2013-01-10 from > > upstream. Unfortunately, it seems the tests can't really go standalone, > > the 3 new tests actually use functions defined in asan_test.cc, so for now > > asan_test.C just includes all the new tests. > > That's fine, although we may break it unwillingly in future. > Btw, the reason for splitting this test was that it took too long (> > 10s) to build it with debug (-O0) version of clang. So, how exactly are the tests linked with clang? Just separate object files, linked into the same binary test, or somehow else? Not familiar with cmake... > Done: http://llvm.org/viewvc/llvm-project?rev=175142&view=rev Thanks, now the difference in the files between gcc/testsuite/g++.dg/asan/ and compiler-rt/lib/asan/tests which have the same name is really just the two lines in the boilerplates. Jakub
Re: libsanitizer merge from upstream r175042
On Wed, Feb 13, 2013 at 10:29 PM, H.J. Lu wrote:
> On Wed, Feb 13, 2013 at 1:19 AM, Konstantin Serebryany
> wrote:
>> Hi,
>>
>> The attached patch is the libsanitizer merge from upstream r175042.
>>
>> Lots of changes. Among other things:
>> - x86_64 linux: change the shadow offset to 0x7fff8000 (~5% speedup)
>> - the new asan allocator is enabled on Mac (was enabled on Linux before).
>> - tsan finds races between atomic and plain accesses
>> - better scanf interceptor, enabled by default
>> - don't include linux/futex.h (fixes PR56128)
>> - simple tests seem to work (again?) on PowerPC64 with 44-bit address
>> space (46 AS not tested)
>>
>> Patch for libsanitizer is automatically generated by libsanitizer/merge.sh
>> Tested with
>> rm -rf */{*/,}libsanitizer \
>> && make -j 50 \
>> && make -C gcc check-g{cc,++}
>> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
>>
>> Our internal LLVM bots (Linux, Mac and Android) are green.
>>
>> Ok to commit?
>>
>> --kcc
>
> This breaks build on Linux/x32 where off_t is 64bit:
Sorry. I've committed your patch upstream as
http://llvm.org/viewvc/llvm-project?rev=175140&view=rev
Feel free to submit the same directly to gcc.
Thanks!
--kcc
>
> In file included from
> /export/gnu/import/git/gcc/libsanitizer/interception/interception.h:20:0,
> from
> /export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:15:
> /export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:221:72:
> error: size of array ‘assertion_failed__34’ is negative
> typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
> ^
> /export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:215:30:
> note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
> #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
> ^
> /export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:34:1:
> note: in expansion of macro ‘COMPILER_CHECK’
> COMPILER_CHECK(sizeof(OFF_T) == sizeof(off_t));
> ^
> make[7]: *** [interception_type_test.lo] Error 1
>
> This patch fixes it. OK to install?
>
> Thanks.
>
> --
> H.J.
> ---
> diff --git a/libsanitizer/interception/interception.h
> b/libsanitizer/interception/interception.h
> index b4c4137..c4c5026 100644
> --- a/libsanitizer/interception/interception.h
> +++ b/libsanitizer/interception/interception.h
> @@ -28,8 +28,8 @@ typedef __sanitizer::s64 INTMAX_T;
> // WARNING: OFF_T may be different from OS type off_t, depending on
> the value of
> // _FILE_OFFSET_BITS. This definition of OFF_T matches the ABI of system
> calls
> // like pread and mmap, as opposed to pread64 and mmap64.
> -// Mac is special.
> -#ifdef __APPLE__
> +// Mac and Linux/x86-64 are special.
> +#if defined(__APPLE__) || (defined(__linux__) && defined(__x86_64__))
> typedef __sanitizer::u64 OFF_T;
> #else
> typedef __sanitizer::uptr OFF_T;
