[Obj-C++] Found a small paste-o in parser.c?
I found this suspicious looking line in cp/parser.c () while looking at
__thread and thread_local.
Look at the patterns of the if blocks above the line in question to verify.
Built and tested on x86_64-linux.
Ed
2012-11-11 Ed Smith-Rowland <3dw...@verizon.net>
* parser.c (cp_parser_objc_class_ivars):
Index declspecs.locations by ds_typedef rather than ds_thread.
Index: parser.c
===
--- parser.c(revision 193380)
+++ parser.c(working copy)
@@ -24650,7 +24650,7 @@
if (decl_spec_seq_has_spec_p (&declspecs, ds_typedef))
{
cp_parser_error (parser, "invalid type for instance variable");
- declspecs.locations[ds_thread] = 0;
+ declspecs.locations[ds_typedef] = 0;
}
prefix_attributes = declspecs.attributes;
[doc] extend.texi copy-editing, 4/N (bit-fields)
I've checked in this patch to consistently use "bit-field" in
extend.texi instead of "bitfield" or "bit field". "Bit-field" is listed
in the GCC Coding Conventions as the preferred terminology, for
consistency with the C and C++ standards.
-Sandra
2012-11-10 Sandra Loosemore
gcc/
* doc/extend.texi: Copy-edit to use "bit-field" consistently
instead of "bitfield" or "bit field".
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193402)
+++ gcc/doc/extend.texi (working copy)
@@ -5006,9 +5006,9 @@ Currently @option{-m[no-]ms-bitfields} i
compilers to match the native Microsoft compiler.
The Microsoft structure layout algorithm is fairly simple with the exception
-of the bitfield packing:
+of the bit-field packing:
-The padding and alignment of members of structures and whether a bit field
+The padding and alignment of members of structures and whether a bit-field
can straddle a storage-unit boundary
@enumerate
@@ -5025,19 +5025,19 @@ Every object is allocated an offset so t
offset % alignment-requirement == 0
-@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
-unit if the integral types are the same size and if the next bit field fits
+@item Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte allocation
+unit if the integral types are the same size and if the next bit-field fits
into the current allocation unit without crossing the boundary imposed by the
-common alignment requirements of the bit fields.
+common alignment requirements of the bit-fields.
@end enumerate
-Handling of zero-length bitfields:
+Handling of zero-length bit-fields:
-MSVC interprets zero-length bitfields in the following ways:
+MSVC interprets zero-length bit-fields in the following ways:
@enumerate
-@item If a zero-length bitfield is inserted between two bitfields that
-are normally coalesced, the bitfields are not coalesced.
+@item If a zero-length bit-field is inserted between two bit-fields that
+are normally coalesced, the bit-fields are not coalesced.
For example:
@@ -5050,12 +5050,12 @@ struct
@} t1;
@end smallexample
-The size of @code{t1} is 8 bytes with the zero-length bitfield. If the
-zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
+The size of @code{t1} is 8 bytes with the zero-length bit-field. If the
+zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
-@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
-alignment of the zero-length bitfield is greater than the member that follows it,
-@code{bar}, @code{bar} is aligned as the type of the zero-length bitfield.
+@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
+alignment of the zero-length bit-field is greater than the member that follows it,
+@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
For example:
@@ -5077,18 +5077,18 @@ struct
For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
Accordingly, the size of @code{t2} is 4. For @code{t3}, the zero-length
-bitfield does not affect the alignment of @code{bar} or, as a result, the size
+bit-field does not affect the alignment of @code{bar} or, as a result, the size
of the structure.
Taking this into account, it is important to note the following:
@enumerate
-@item If a zero-length bitfield follows a normal bitfield, the type of the
-zero-length bitfield may affect the alignment of the structure as whole. For
-example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
-normal bitfield, and is of type short.
+@item If a zero-length bit-field follows a normal bit-field, the type of the
+zero-length bit-field may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
+normal bit-field, and is of type short.
-@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
still affect the alignment of the structure:
@smallexample
@@ -5102,7 +5102,7 @@ struct
Here, @code{t4} takes up 4 bytes.
@end enumerate
-@item Zero-length bitfields following non-bitfield members are ignored:
+@item Zero-length bit-fields following non-bit-field members are ignored:
@smallexample
struct
@@ -5266,7 +5266,7 @@ alignment. See your linker documentatio
@item packed
This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bitfields)
+definition, specifies that each member (other than zero-width bit-fields)
of the structure or union is placed to minimize the memory required. When
attached to an @code{enum} definition, it indicates that the smallest
integral type should be used.
@@ -5782,11 +5782,1
[doc] extend.texi copy-editing, 3/N (hyphenated phrases)
I've checked in this patch to fix various problems with hyphenated
phrases in extend.texi. This exactly parallels similar copy edits I
made earlier this year to invoke.texi. To recap, in phrases like
"64-bit types", "64-bit" is a compound adjective phrase that immediately
precedes a noun and should be hyphenated. On the other hand, "64 bits"
is a noun phrase and shouldn't be hyphenated. Similar rules apply to
"floating-point" (adjective) versus "floating point" (noun), etc.
-Sandra
2012-11-10 Sandra Loosemore
gcc/
* doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
involving "bit", "byte", "word", "precision", and "floating"
modifiers.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193400)
+++ gcc/doc/extend.texi (working copy)
@@ -812,11 +812,11 @@ effects of recomputing it.
@cindex @code{__int128} data types
As an extension the integer scalar type @code{__int128} is supported for
-targets having an integer mode wide enough to hold 128-bit.
+targets having an integer mode wide enough to hold 128 bits.
Simply write @code{__int128} for a signed 128-bit integer, or
@code{unsigned __int128} for an unsigned 128-bit integer. There is no
support in GCC to express an integer constant of type @code{__int128}
-for targets having @code{long long} integer with less then 128 bit width.
+for targets having @code{long long} integer less than 128 bits wide.
@node Long Long
@section Double-Word Integers
@@ -917,8 +917,8 @@ examine and set these two fictitious var
@cindex @code{Q} floating point suffix
As an extension, the GNU C compiler supports additional floating
-types, @code{__float80} and @code{__float128} to support 80bit
-(@code{XFmode}) and 128 bit (@code{TFmode}) floating types.
+types, @code{__float80} and @code{__float128} to support 80-bit
+(@code{XFmode}) and 128-bit (@code{TFmode}) floating types.
Support for additional types includes the arithmetic operators:
add, subtract, multiply, divide; unary arithmetic operators;
relational operators; equality operators; and conversions to and from
@@ -933,7 +933,7 @@ typedef _Complex float __attribute__((mo
typedef _Complex float __attribute__((mode(XC))) _Complex80;
@end smallexample
-Not all targets support additional floating point types. @code{__float80}
+Not all targets support additional floating-point types. @code{__float80}
and @code{__float128} types are supported on i386, x86_64 and ia64 targets.
The @code{__float128} type is supported on hppa HP-UX targets.
@@ -2475,11 +2475,11 @@ referenced. On Microsoft Windows target
for functions by setting the @option{-mnop-fun-dllimport} flag.
@item eightbit_data
-@cindex eight bit data on the H8/300, H8/300H, and H8S
+@cindex eight-bit data on the H8/300, H8/300H, and H8S
Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
-variable should be placed into the eight bit data section.
+variable should be placed into the eight-bit data section.
The compiler generates more efficient code for certain operations
-on data in the eight bit data area. Note the eight bit data area is limited to
+on data in the eight-bit data area. Note the eight-bit data area is limited to
256 bytes of data.
You must use GAS and GLD from GNU binutils version 2.7 or later for
@@ -2710,8 +2710,8 @@ from the special page vector table which
bits of the subroutine's entry address. Each vector table has special
page number (18 to 255) that is used in @code{jsrs} instructions.
Jump addresses of the routines are generated by adding 0x0F (in
-case of M16C targets) or 0xFF (in case of M32C targets), to the 2
-byte addresses set in the vector table. Therefore you need to ensure
+case of M16C targets) or 0xFF (in case of M32C targets), to the
+2-byte addresses set in the vector table. Therefore you need to ensure
that all the special page vector routines should get mapped within the
address range 0x0F to 0x0F (for M16C) and 0xFF to 0xFF
(for M32C).
@@ -2811,7 +2811,7 @@ void f () __attribute__ ((interrupt ("IR
Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
On ARMv7-M the interrupt type is ignored, and the attribute means the function
-may be called with a word aligned stack pointer.
+may be called with a word-aligned stack pointer.
On Epiphany targets one or more optional parameters can be added like this:
@@ -3085,7 +3085,7 @@ caller pops the stack for hidden pointer
@item ms_hook_prologue
@cindex @code{ms_hook_prologue} attribute
-On 32 bit i[34567]86-*-* targets and 64 bit x86_64-*-* targets, you can use
+On 32-bit i[34567]86-*-* targets and 64-bit x86_64-*-* targets, you can use
this function attribute to make gcc generate the "hot-patching" function
prologue used in Win32 API functions in Microsoft Windows XP Service Pack 2
and newer.
@@ -3422,10 +3422,10 @@
libstdc++ PATCH to add abi tag to complex::real/imag
As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11
changes the return type of complex::real and imag, leading to a binary
incompatibility between C++98 and C++11 code if the functions are used
without inlining. This patch adds an ABI tag to the C++11 variants so
that they have different mangled names. This does not change the
exports from libstdc++.
For the map void->iterator change, I think it would make sense to just
unconditionally return an iterator; there's no binary compatibility
issue with older code that expects it to return void, the problem is
only with C++11 code calling a C++98 instantiation that returns void.
For the other cases mentioned on that page, I think either we want to
unify the two implementations (because we think they're compatible) or
add ABI tags to the C++11 implementations.
Is this patch OK for trunk? Does someone on the library team want to
look at the other cases?
commit be79353c10252bc99cac5f9d9ce045207e665238
Author: Jason Merrill
Date: Sat Nov 10 13:10:15 2012 -0500
* include/std/complex (real, imag): Add ABI tag in C++11 mode.
diff --git a/libstdc++-v3/include/std/complex b/libstdc++-v3/include/std/complex
index f9221a8..24fa414 100644
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -141,9 +141,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag ("cxx11")))
constexpr _Tp
real() { return _M_real; }
+ __attribute ((abi_tag ("cxx11")))
constexpr _Tp
imag() { return _M_imag; }
#else
@@ -1061,9 +1063,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag ("cxx11")))
constexpr float
real() { return __real__ _M_value; }
+ __attribute ((abi_tag ("cxx11")))
constexpr float
imag() { return __imag__ _M_value; }
#else
@@ -1210,9 +1214,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag ("cxx11")))
constexpr double
real() { return __real__ _M_value; }
+ __attribute ((abi_tag ("cxx11")))
constexpr double
imag() { return __imag__ _M_value; }
#else
@@ -1360,9 +1366,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag ("cxx11")))
constexpr long double
real() { return __real__ _M_value; }
+ __attribute ((abi_tag ("cxx11")))
constexpr long double
imag() { return __imag__ _M_value; }
#else
diff --git a/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc b/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
new file mode 100644
index 000..a845466
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
@@ -0,0 +1,25 @@
+// Test that the C++11 variants of real/imag have an ABI tag
+// { dg-do compile }
+// { dg-options -std=c++11 }
+
+#include
+
+// { dg-final { scan-assembler "_ZNKSt7complexIfE4realB5cxx11Ev" } }
+float (std::complex::*p1)() const = &std::complex::real;
+// { dg-final { scan-assembler "_ZNKSt7complexIdE4realB5cxx11Ev" } }
+double (std::complex::*p2)() const = &std::complex::real;
+// { dg-final { scan-assembler "_ZNKSt7complexIeE4realB5cxx11Ev" } }
+long double (std::complex::*p3)() const
+ = &std::complex::real;
+// { dg-final { scan-assembler "_ZNKSt7complexIiE4realB5cxx11Ev" } }
+int (std::complex::*p4)() const = &std::complex::real;
+
+// { dg-final { scan-assembler "_ZNKSt7complexIfE4imagB5cxx11Ev" } }
+float (std::complex::*p5)() const = &std::complex::imag;
+// { dg-final { scan-assembler "_ZNKSt7complexIdE4imagB5cxx11Ev" } }
+double (std::complex::*p6)() const = &std::complex::imag;
+// { dg-final { scan-assembler "_ZNKSt7complexIeE4imagB5cxx11Ev" } }
+long double (std::complex::*p7)() const
+ = &std::complex::imag;
+// { dg-final { scan-assembler "_ZNKSt7complexIiE4imagB5cxx11Ev" } }
+int (std::complex::*p8)() const = &std::complex::imag;
Re: RFC: PATCH to add abi_tag attribute
The demangler change was handling the tags in the wrong place; I'm
writing them out with unqualified names, so the demangler should expect
them in the same place.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 75eef303e5494f27a6d9bbef68aaf3200978a8f1
Author: Jason Merrill
Date: Sat Nov 10 13:10:24 2012 -0500
* cp-demangle.c (d_unqualified_name): Handle abi tags here.
(d_name): Not here.
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 86c7747..913d4bf 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -1246,17 +1246,14 @@ d_name (struct d_info *di)
switch (peek)
{
case 'N':
- dc = d_nested_name (di);
- break;
+ return d_nested_name (di);
case 'Z':
- dc = d_local_name (di);
- break;
+ return d_local_name (di);
case 'L':
case 'U':
- dc = d_unqualified_name (di);
- break;
+ return d_unqualified_name (di);
case 'S':
{
@@ -1298,7 +1295,7 @@ d_name (struct d_info *di)
d_template_args (di));
}
- break;
+ return dc;
}
default:
@@ -1313,12 +1310,8 @@ d_name (struct d_info *di)
dc = d_make_comp (di, DEMANGLE_COMPONENT_TEMPLATE, dc,
d_template_args (di));
}
- break;
+ return dc;
}
-
- if (d_peek_char (di) == 'B')
-dc = d_abi_tags (di, dc);
- return dc;
}
/* ::= N [] E
@@ -1446,15 +1439,14 @@ d_prefix (struct d_info *di)
static struct demangle_component *
d_unqualified_name (struct d_info *di)
{
+ struct demangle_component *ret;
char peek;
peek = d_peek_char (di);
if (IS_DIGIT (peek))
-return d_source_name (di);
+ret = d_source_name (di);
else if (IS_LOWER (peek))
{
- struct demangle_component *ret;
-
ret = d_operator_name (di);
if (ret != NULL && ret->type == DEMANGLE_COMPONENT_OPERATOR)
{
@@ -1463,14 +1455,11 @@ d_unqualified_name (struct d_info *di)
ret = d_make_comp (di, DEMANGLE_COMPONENT_UNARY, ret,
d_source_name (di));
}
- return ret;
}
else if (peek == 'C' || peek == 'D')
-return d_ctor_dtor_name (di);
+ret = d_ctor_dtor_name (di);
else if (peek == 'L')
{
- struct demangle_component * ret;
-
d_advance (di, 1);
ret = d_source_name (di);
@@ -1478,22 +1467,27 @@ d_unqualified_name (struct d_info *di)
return NULL;
if (! d_discriminator (di))
return NULL;
- return ret;
}
else if (peek == 'U')
{
switch (d_peek_next_char (di))
{
case 'l':
- return d_lambda (di);
+ ret = d_lambda (di);
+ break;
case 't':
- return d_unnamed_type (di);
+ ret = d_unnamed_type (di);
+ break;
default:
return NULL;
}
}
else
return NULL;
+
+ if (d_peek_char (di) == 'B')
+ret = d_abi_tags (di, ret);
+ return ret;
}
/* ::= <(positive length) number> */
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index 6b55d30..5b41b03 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -4084,6 +4084,9 @@ auto& f(int const&, int)
--format=gnu-v3
_Z1gILi1EEvR1AIXT_EER1BIXscbT_EE
void g<1>(A<1>&, B(1)>&)
+--format=gnu-v3
+_ZNKSt7complexIiE4realB5cxx11Ev
+std::complex::real[abi:cxx11]() const
#
# Ada (GNAT) tests.
#
[doc] extend.texi copy-editing, 2/N (which/that usage)
This patch continues my series of copy-edits to the GCC user
documentation. Here I've fixed a number of problems in extend.texi with
confusion between "which" and "that", as I previously did for invoke.texi.
Committed as obvious since there are no changes to content, just grammar.
-Sandra
2012-11-10 Sandra Loosemore
gcc/
* doc/extend.texi: Copy-edit to fix incorrect uses of "which"
and "that" throughout the file.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193399)
+++ gcc/doc/extend.texi (working copy)
@@ -463,7 +463,7 @@ C++ Conference Proceedings, October 17-2
A nested function can jump to a label inherited from a containing
function, provided the label is explicitly declared in the containing
function (@pxref{Local Labels}). Such a jump returns instantly to the
-containing function, exiting the nested function which did the
+containing function, exiting the nested function that did the
@code{goto} and any intermediate functions as well. Here is an example:
@smallexample
@@ -571,7 +571,7 @@ returned by @code{__builtin_apply}.
@deftypefn {Built-in Function} {} __builtin_va_arg_pack ()
This built-in function represents all anonymous arguments of an inline
-function. It can be used only in inline functions which are always
+function. It can be used only in inline functions that are always
inlined, never compiled as a separate function, such as those using
@code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
@@ -597,7 +597,7 @@ myprintf (FILE *f, const char *format, .
@deftypefn {Built-in Function} {size_t} __builtin_va_arg_pack_len ()
This built-in function returns the number of anonymous arguments of
-an inline function. It can be used only in inline functions which
+an inline function. It can be used only in inline functions that
are always inlined, never compiled as a separate function, such
as those using @code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
@@ -674,7 +674,7 @@ such a type.
@code{typeof} is often useful in conjunction with the
statements-within-expressions feature. Here is how the two together can
-be used to define a safe ``maximum'' macro that operates on any
+be used to define a safe ``maximum'' macro which operates on any
arithmetic type and evaluates each of its arguments exactly once:
@smallexample
@@ -750,7 +750,7 @@ pointers to @code{char}.
@end itemize
@emph{Compatibility Note:} In addition to @code{typeof}, GCC 2 supported
-a more limited extension which permitted one to write
+a more limited extension that permitted one to write
@smallexample
typedef @var{T} = @var{expr};
@@ -759,7 +759,7 @@ typedef @var{T} = @var{expr};
@noindent
with the effect of declaring @var{T} to have the type of the expression
@var{expr}. This extension does not work with GCC 3 (versions between
-3.0 and 3.2 crash; 3.2.1 and later give an error). Code which
+3.0 and 3.2 crash; 3.2.1 and later give an error). Code that
relies on it should be rewritten to use @code{typeof}:
@smallexample
@@ -1417,7 +1417,7 @@ space.
@cindex flexible array members
Zero-length arrays are allowed in GNU C@. They are very useful as the
-last element of a structure which is really a header for a variable-length
+last element of a structure that is really a header for a variable-length
object:
@smallexample
@@ -1877,7 +1877,7 @@ int a[6] = @{ 0, 0, 15, 0, 29, 0 @};
The index values must be constant expressions, even if the array being
initialized is automatic.
-An alternative syntax for this which has been obsolete since GCC 2.5 but
+An alternative syntax for this that has been obsolete since GCC 2.5 but
GCC still accepts is to write @samp{[@var{index}]} before the element
value, with no @samp{=}.
@@ -1919,7 +1919,7 @@ is equivalent to
struct point p = @{ xvalue, yvalue @};
@end smallexample
-Another syntax which has the same meaning, obsolete since GCC 2.5, is
+Another syntax that has the same meaning, obsolete since GCC 2.5, is
@samp{@var{fieldname}:}, as shown here:
@smallexample
@@ -2210,7 +2210,7 @@ if no optimization level is specified.
@item gnu_inline
@cindex @code{gnu_inline} function attribute
-This attribute should be used with a function which is also declared
+This attribute should be used with a function that is also declared
with the @code{inline} keyword. It directs GCC to treat the function
as if it were defined in gnu90 mode even when compiling in C99 or
gnu99 mode.
@@ -2248,7 +2248,7 @@ behavior.
@item artificial
@cindex @code{artificial} function attribute
-This attribute is useful for small inline wrappers which if possible
+This attribute is useful for small inline wrappers that if possible
should appear during debugging as a unit. Depending on the debug
info format it either mea
[patch] PR55263
Hello, This is another ICE in pre_and_rev_post_order_compute, called from alias.c after register allocation. The problem is that purge_all_dead_edges can make basic blocks unreachable. Before my patch of r190602, alias.c handled unreachable blocks (resulting in missed disambiguations). Now that alias.c walks instructions in topological order, unreachable blocks are a no-no. But postreload-cse was never really converted to properly use and maintain the CFG, and this PR is the second example of this problem (after PR54385, which I fixed earlier this week). Fixed by calling cleanup_cfg(0) if edges were purged. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. OK if it passes? Ciao! Steven gcc/ PR middle-end/55263 * postreload.c (rest_of_handle_postreload): With non-call exceptions, if edges are purged call cleanup_cfg to remove unreachable blocks. testsuite/ PR middle-end/55263 * g++.dg/pr55263.C: New test. PR55263.diff Description: Binary data
Re: *ping* [patch, fortran] PR 30146, errors for INTENT(OUT) and INTENT(INOUT) for DO loop variables
On Sat, Nov 10, 2012 at 3:00 PM, Thomas Koenig wrote:
> I wrote:
>
>> after the dicsussion on c.l.f, it become clear that passing a DO loop
>> variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
>> The attached patch throws an error for both cases.
But should we really isse an error for INTENT(INOUT)? IMHO a warning
suffices, with maybe an error only for strict (i.e. non-GNU) standard
settings.
>> I chose to issue the errors as a front-end pass because we cannot check
>> for formal arguments during parsing (where the other checks are
>> implemented).
>>
>> Regression-tested. OK for trunk?
>
>
> Ping ** 1.4285 ?
You don't have to list do_list twice in the ChangeLog, you probably
wanted one of those to be do_level ;-)
>> + do_list = XNEWVEC(gfc_code *, do_size);
Taste nit: Why not just toss do_list, do_level, and do_size around as
a function argument, instead of making them global variable? Just
define a struct containing them and pass it around via the "data"
argument for gfc_code_walker should work, I think.
IMHO names like "do_warn" and "do_list" are not very descriptive, if
not to say confusing. do_* names are used elsewhere in the compiler
for functions that perform ("do") a task, whereas your do_* functions
are for the Fortran DO construct. I'd prefer different names.
>> + to an INTENt(OUT) or INTENT(INOUT) dummy variable. */
s/INTENt/INTENT/
>> + /* Withot a formal arglist, there is only unknown INTENT,
s/Withot/Without/
>> + for (i=0; i> + "inside loop beginning at %L as INTENT(OUT) "
Extraneous space after loop.
How do you handle OPTIONAL args?
Ciao!
Steven
Re: PATCH: Handle ZERO_EXTEND offsettable address
On Sat, Nov 10, 2012 at 10:38:55AM -0800, H.J. Lu wrote:
> On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini wrote:
> > Il 10/11/2012 07:44, H.J. Lu ha scritto:
> >> Hi,
> >>
> >> In
> >>
> >> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
> >> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
> >> {*movti_internal_rex64}
> >> (expr_list:REG_DEAD (reg:SI 82)
> >> (expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
> >> (const_int -16 [0xfff0])) [0 sym+0 S16
> >> A64])
> >>
> >> we fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
> >> This patch adds ZERO_EXTEND support to adjust_address_1 and
> >> offsettable_address_addr_space_p. Tested on Linux/x32. OK to install?
> >
> > Is there any reason why SIGN_EXTEND should be handled differently?
> > (Just asking, I don't know this code well).
> >
>
> I don't have a testcase to show that we will generate SIGN_EXTEND
> for offsettable address. I can add an assert of GET_CODE != SIGN_EXTEND.
>
>
This patch also handles SIGN_EXTEND. Tested on Linux/x32. OK to
install?
Thanks.
H.J.
---
gcc/
2012-11-10 H.J. Lu
PR middle-end/55247
PR middle-end/55259
* emit-rtl.c (adjust_address_1): Handle ZERO_EXTEND and
SIGN_EXTEND.
* recog.c (offsettable_address_addr_space_p): Likewise.
* config/i386/i386.md (*movti_internal_rex64): Remove "!" from
riF->o alternative.
gcc/testsuite/
2012-11-10 H.J. Lu
PR middle-end/55247
PR middle-end/55259
* gcc.target/i386/pr55247-2.c: New file.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 2598a1f..243ab4e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1874,7 +1874,7 @@
(const_string "OI")))])
(define_insn "*movti_internal_rex64"
- [(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,!o ,x,x ,m")
+ [(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,riF,C,xm,x"))]
"TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 95bbfa7..22065f5 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2100,6 +2100,8 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
if (adjust_address)
{
+ rtx x;
+
/* If MEMREF is a LO_SUM and the offset is within the alignment of the
object, we can merge it into the LO_SUM. */
if (GET_MODE (memref) != BLKmode && GET_CODE (addr) == LO_SUM
@@ -2109,6 +2111,20 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
plus_constant (address_mode,
XEXP (addr, 1), offset));
+ /* We permute zero/sign-extension and addition operation only if
+converting the constant does not change it. */
+ else if ((GET_CODE (addr) == ZERO_EXTEND
+ || GET_CODE (addr) == SIGN_EXTEND)
+ && (x = GEN_INT (offset),
+ x == convert_memory_address_addr_space (address_mode,
+ x,
+ attrs.addrspace)))
+ {
+ enum rtx_code code = GET_CODE (addr);
+ addr = XEXP (addr, 0);
+ addr = plus_constant (GET_MODE (addr), addr, offset);
+ addr = gen_rtx_fmt_e (code, address_mode, addr);
+ }
else
addr = plus_constant (address_mode, addr, offset);
}
diff --git a/gcc/recog.c b/gcc/recog.c
index ee68e30..a916ef6 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -1934,15 +1934,22 @@ int
offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
addr_space_t as)
{
- enum rtx_code ycode = GET_CODE (y);
+ enum rtx_code ycode;
rtx z;
- rtx y1 = y;
+ rtx y1;
rtx *y2;
int (*addressp) (enum machine_mode, rtx, addr_space_t) =
(strictp ? strict_memory_address_addr_space_p
: memory_address_addr_space_p);
unsigned int mode_sz = GET_MODE_SIZE (mode);
+ /* Allow zero-extended or sign-extended address. */
+ if (GET_CODE (y) == ZERO_EXTEND || GET_CODE (y) == SIGN_EXTEND)
+y = XEXP (y, 0);
+
+ ycode = GET_CODE (y);
+ y1 = y;
+
if (CONSTANT_ADDRESS_P (y))
return 1;
diff --git a/gcc/testsuite/gcc.target/i386/pr55247-2.c
b/gcc/testsuite/gcc.target/i386/pr55247-2.c
new file mode 100644
index 000..d91b504
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr55247-2.c
@@ -0,0 +1,37 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options "-O2 -mx32 -mtune=generic -maddress-mode=long" } */
+
+typedef unsigned int uint32_t;
+typedef uint32_t Elf32_Word;
+typedef uint32_t Elf32_A
libgo patch committed: Fix bug comparing struct field types
This patch fixes a bug comparing struct field types in the reflect
package. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 8b1f2a35ded1 libgo/go/reflect/type.go
--- a/libgo/go/reflect/type.go Tue Nov 06 10:44:51 2012 -0800
+++ b/libgo/go/reflect/type.go Sat Nov 10 12:20:00 2012 -0800
@@ -1309,8 +1309,19 @@
for i := range t.fields {
tf := &t.fields[i]
vf := &v.fields[i]
- if tf.name != vf.name || tf.pkgPath != vf.pkgPath ||
-tf.typ != vf.typ || tf.tag != vf.tag || tf.offset != vf.offset {
+ if tf.name != vf.name && (tf.name == nil || vf.name == nil || *tf.name != *vf.name) {
+return false
+ }
+ if tf.pkgPath != vf.pkgPath && (tf.pkgPath == nil || vf.pkgPath == nil || *tf.pkgPath != *vf.pkgPath) {
+return false
+ }
+ if tf.typ != vf.typ {
+return false
+ }
+ if tf.tag != vf.tag && (tf.tag == nil || vf.tag == nil || *tf.tag != *vf.tag) {
+return false
+ }
+ if tf.offset != vf.offset {
return false
}
}
Re: [PATCH, i386]: Fix PR 55247, ICE: Max. number of generated reload insns per insn is achieved
On Sat, Nov 10, 2012 at 3:43 AM, Uros Bizjak wrote:
> Hello!
>
> Attached patch disparages riF->o alternative of *movti_internal_rex64
> insn, as described by Vlad in comment #2 [1]
>
> The core of the problem however is, that gcc is unable to detect
> zero-extended address as offsetable. H.J. will propose a patch for
> this [2].
My updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html
> 2012-11-10 Vladimir Makarov
> Uros Bizjak
>
> PR target/55247
> * config/i386/i386.md (*movti_internal_rex64): Add "!" to riF->o
> alternative.
>
> testsuite/ChangeLog:
>
> 2012-11-10 Uros Bizjak
>
> PR target/55247
> * gcc.target/i386/pr55247.c: New test.
>
> Tested on x86_64-linux-gnu {,m32} and committed to mainline SVN.
>
> [1] gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c2
> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c6
>
> Uros.
I checked in this patch to compile pr55247.c with -mno-sse -mno-mmx,
which triggers the bug.
H.J.
--
Index: ChangeLog
===
--- ChangeLog (revision 193393)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-11-10 H.J. Lu
+
+ * gcc.target/i386/pr55247.c: Require maybe_x32 target. Add
+ -mno-sse -mno-mmx to dg-options. Reformat.
+
2012-11-10 David Edelsohn
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
Index: gcc.target/i386/pr55247.c
===
--- gcc.target/i386/pr55247.c (revision 193393)
+++ gcc.target/i386/pr55247.c (working copy)
@@ -1,8 +1,8 @@
/* { dg-do compile { target { ! { ia32 } } } } */
-/* { dg-options "-O2 -mx32 -maddress-mode=long -mno-sse" } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options "-O2 -mno-sse -mno-mmx -mx32 -maddress-mode=long" } */
typedef unsigned int uint32_t;
-typedef unsigned int uintptr_t;
typedef uint32_t Elf32_Word;
typedef uint32_t Elf32_Addr;
typedef struct {
@@ -16,7 +16,7 @@
}
Elf32_Rela;
typedef struct {
- union {
+ union {
Elf32_Addr d_ptr;
}
d_un;
@@ -24,15 +24,12 @@
struct link_map {
Elf32_Dyn *l_info[34];
};
-typedef struct link_map *lookup_t;
extern void symbind32 (Elf32_Sym *);
void
_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
{
- const Elf32_Sym *const symtab = (const void *) (l)->l_info[6]->d_un.d_ptr;
- const Elf32_Rela *const reloc = (const void *)
((l)->l_info[23]->d_un.d_ptr + reloc_arg * sizeof (Elf32_Rela));
- const Elf32_Sym *refsym = &symtab[((reloc->r_info) >> 8)];
- const Elf32_Sym *defsym = refsym;
- Elf32_Sym sym = *defsym;
+ const Elf32_Sym *const symtab = (const void *) l->l_info[6]->d_un.d_ptr;
+ const Elf32_Rela *const reloc = (const void *)
(l->l_info[23]->d_un.d_ptr + reloc_arg * sizeof (Elf32_Rela));
+ Elf32_Sym sym = symtab[(reloc->r_info) >> 8];
symbind32 (&sym);
}
Re: [asan] Patch - fix an ICE in asan.c
Tobias Burnus wrote:
I spoke too early. With the updated patch, there is no ICE, but one
crashes for the following valid program with:
But with my original patch, it works.
To recap: My "if (gsi_end_p (i)) break;" (cf. [1]) fixes my original
issue (ICE for fail31.ii; [1]) and gives the correct diagnostic at run
time for strlen in the code [4] (both for correct and out-of-bounds
programs).
While Jakub's "*iter = gsi_for_stmt (call);" (cf. [3]) fixes the ICE for
my fail10.ii program [2]; I haven't tried to construct a run-time
version for that code.
Updated patches attached (for the "asan" branch and for the trunk on top
of Dodji's patches; I have only tested the latter).
Hopefully, the test suite will be working soon, it should help finding
such issues.
Tobias
[1] fail31.ii (strlen ICE):
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00786.html
[2] fail10.ii (control flow in BB ICE):
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html
[3] Jakub's patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00801.html
[4] strlen run test: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00809.html
(This patch is for the "asan" branch.)
2012-11-10 Tobias Burnus
Jakub Jelinek
* asan.c (maybe_instrument_builtin_call): Set *iter
to gsi for the call at the end.
(transform_statements): Leave loop when gsi_end_p.
diff --git a/gcc/asan.c b/gcc/asan.c
index 155e84b..f5e357a 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1187,14 +1187,15 @@ maybe_instrument_builtin_call (gimple_stmt_iterator *iter)
loc, /*is_store=*/false);
if (source1 != NULL_TREE)
instrument_mem_region_access (source1, len, iter,
loc, /*is_store=*/false);
else if (dest != NULL_TREE)
instrument_mem_region_access (dest, len, iter,
loc, /*is_store=*/true);
+ *iter = gsi_for_stmt (call);
return true;
}
return false;
}
/* Instrument the assignment statement ITER if it is subject to
instrumentation. */
@@ -1243,14 +1244,16 @@ transform_statements (void)
{
gimple s = gsi_stmt (i);
if (gimple_assign_single_p (s))
instrument_assignment (&i);
else if (is_gimple_call (s))
maybe_instrument_call (&i);
+ if (gsi_end_p (i))
+ break;
}
}
}
/* Build
struct __asan_global
{
(This patch is for the trunk after the "asan" patch has been applied.)
2012-11-10 Tobias Burnus
Jakub Jelinek
* asan.c (maybe_instrument_builtin_call): Set *iter
to gsi for the call at the end.
(transform_statements): Leave loop when gsi_end_p.
--- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
+++ gcc/asan.c 2012-11-10 19:23:33.0 +0100
@@ -1302,16 +1302,17 @@ instrument_builtin_call (gimple_stmt_ite
instrument_mem_region_access (source0, len, iter,
loc, /*is_store=*/false);
if (source1 != NULL_TREE)
instrument_mem_region_access (source1, len, iter,
loc, /*is_store=*/false);
else if (dest != NULL_TREE)
instrument_mem_region_access (dest, len, iter,
loc, /*is_store=*/true);
+ *iter = gsi_for_stmt (call);
}
}
/* Instrument the assignment statement ITER if it is subject to
instrumentation. */
static void
instrument_assignment (gimple_stmt_iterator *iter)
@@ -1357,16 +1358,18 @@ transform_statements (void)
for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
gimple s = gsi_stmt (i);
if (gimple_assign_single_p (s))
instrument_assignment (&i);
else if (is_gimple_call (s))
maybe_instrument_call (&i);
+ if (gsi_end_p (i))
+ break;
}
}
}
/* Build
struct __asan_global
{
const void *__beg;
Re: PATCH: Handle ZERO_EXTEND offsettable address
On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini wrote:
> Il 10/11/2012 07:44, H.J. Lu ha scritto:
>> Hi,
>>
>> In
>>
>> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
>> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
>> {*movti_internal_rex64}
>> (expr_list:REG_DEAD (reg:SI 82)
>> (expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
>> (const_int -16 [0xfff0])) [0 sym+0 S16 A64])
>>
>> we fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
>> This patch adds ZERO_EXTEND support to adjust_address_1 and
>> offsettable_address_addr_space_p. Tested on Linux/x32. OK to install?
>
> Is there any reason why SIGN_EXTEND should be handled differently?
> (Just asking, I don't know this code well).
>
I don't have a testcase to show that we will generate SIGN_EXTEND
for offsettable address. I can add an assert of GET_CODE != SIGN_EXTEND.
H.J.
---
>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> gcc/
>>
>> 2012-11-10 H.J. Lu
>>
>> PR rtl-optimization/55247
>> PR middle-end/55259
>> * emit-rtl.c (adjust_address_1): Handle ZERO_EXTEND.
>> * recog.c (offsettable_address_addr_space_p): Likewise.
>>
>> gcc/testsuite/
>>
>> 2012-11-10 H.J. Lu
>>
>> PR rtl-optimization/55247
>> PR middle-end/55259
>>
>> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>> index 95bbfa7..d7c454c 100644
>> --- a/gcc/emit-rtl.c
>> +++ b/gcc/emit-rtl.c
>> @@ -2109,6 +2109,12 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
>> HOST_WIDE_INT offset,
>> addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
>> plus_constant (address_mode,
>> XEXP (addr, 1), offset));
>> + else if (GET_CODE (addr) == ZERO_EXTEND)
>> + {
>> + addr = XEXP (addr, 0);
>> + addr = plus_constant (GET_MODE (addr), addr, offset);
>> + addr = gen_rtx_ZERO_EXTEND (address_mode, addr);
>> + }
>>else
>> addr = plus_constant (address_mode, addr, offset);
>> }
>> diff --git a/gcc/recog.c b/gcc/recog.c
>> index ee68e30..d3dd591 100644
>> --- a/gcc/recog.c
>> +++ b/gcc/recog.c
>> @@ -1934,15 +1934,21 @@ int
>> offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx
>> y,
>> addr_space_t as)
>> {
>> - enum rtx_code ycode = GET_CODE (y);
>> + enum rtx_code ycode;
>>rtx z;
>> - rtx y1 = y;
>> + rtx y1;
>>rtx *y2;
>>int (*addressp) (enum machine_mode, rtx, addr_space_t) =
>> (strictp ? strict_memory_address_addr_space_p
>>: memory_address_addr_space_p);
>>unsigned int mode_sz = GET_MODE_SIZE (mode);
>>
>> + if (GET_CODE (y) == ZERO_EXTEND)
>> +y = XEXP (y, 0);
>> +
>> + ycode = GET_CODE (y);
>> + y1 = y;
>> +
>>if (CONSTANT_ADDRESS_P (y))
>> return 1;
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/pr55247.c
>> b/gcc/testsuite/gcc.target/i386/pr55247.c
>> new file mode 100644
>> index 000..594139e
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pr55247.c
>> @@ -0,0 +1,35 @@
>> +/* { dg-do compile { target { ! { ia32 } } } } */
>> +/* { dg-require-effective-target maybe_x32 } */
>> +/* { dg-options "-O -mno-sse -mno-mmx -mx32 -maddress-mode=long" } */
>> +
>> +typedef unsigned int uint32_t;
>> +typedef uint32_t Elf32_Word;
>> +typedef uint32_t Elf32_Addr;
>> +typedef struct {
>> + Elf32_Word st_name;
>> + Elf32_Addr st_value;
>> + Elf32_Word st_size;
>> + unsigned char st_other;
>> +} Elf32_Sym;
>> +typedef struct {
>> + Elf32_Word r_info;
>> +}
>> +Elf32_Rela;
>> +typedef struct {
>> + union {
>> +Elf32_Addr d_ptr;
>> + }
>> + d_un;
>> +} Elf32_Dyn;
>> +struct link_map {
>> + Elf32_Dyn *l_info[34];
>> +};
>> +extern void symbind32 (Elf32_Sym *);
>> +void
>> +_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
>> +{
>> + const Elf32_Sym *const symtab = (const void *) l->l_info[6]->d_un.d_ptr;
>> + const Elf32_Rela *const reloc = (const void *)
>> (l->l_info[23]->d_un.d_ptr + reloc_arg * sizeof (Elf32_Rela));
>> + Elf32_Sym sym = symtab[(reloc->r_info) >> 8];
>> + symbind32 (&sym);
>> +}
>>
>
--
H.J.
Re: [PATCH] Fix combined tree for LTO
On Sat, Nov 10, 2012 at 6:46 AM, Paolo Bonzini wrote:
> Il 10/11/2012 05:30, Andrew Pinski ha scritto:
>> Hi,
>> The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
>> the final installed binary name. This patch fixes the problem by
>> changing if we got ld-new to just ld.
>> Note this issue has been around since 4.6 but not many people test
>> installed binary and it does not show up while doing testing from the
>> combined tree either.
>>
>> OK? Bootstrapped and tested with and without being in a combined tree
>> without any regressions.
>
> OK with one change: please make it test collect-ld as well.
Here is the patch which I applied.
Thanks,
Andrew Pinski
2012-11-10 Andrew Pinski
PR bootstrap/55202
* configure.ac: Set PLUGIN_LD_SUFFIX to just "ld" if it was "ld-new"
or "collect-ld".
* configure: Regenerate.
>
> Paolo
>
>> Thanks,
>> Andrew Pinski
>>
>> * configure.ac: Set PLUGIN_LD_SUFFIX to just "ld" if it was "ld-new".
>> * configure: Regenerate.
>>
>
Index: configure
===
--- configure (revision 193392)
+++ configure (working copy)
@@ -21343,6 +21343,12 @@ fi
ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
PLUGIN_LD_SUFFIX=`basename $gcc_cv_ld | sed -e "s,$target_alias-,,"`
+# if the PLUGIN_LD is set ld-new, just have it as ld
+# as that is the installed named.
+if test x$PLUGIN_LD_SUFFIX == xld-new \
+ || test x$PLUGIN_LD_SUFFIX == xcollect-ld ; then
+ PLUGIN_LD_SUFFIX=ld
+fi
# Check whether --with-plugin-ld was given.
if test "${with_plugin_ld+set}" = set; then :
Index: configure.ac
===
--- configure.ac(revision 193392)
+++ configure.ac(working copy)
@@ -2003,6 +2003,12 @@ fi])
ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
PLUGIN_LD_SUFFIX=`basename $gcc_cv_ld | sed -e "s,$target_alias-,,"`
+# if the PLUGIN_LD is set ld-new, just have it as ld
+# as that is the installed named.
+if test x$PLUGIN_LD_SUFFIX == xld-new \
+ || test x$PLUGIN_LD_SUFFIX == xcollect-ld ; then
+ PLUGIN_LD_SUFFIX=ld
+fi
AC_ARG_WITH(plugin-ld,
[AS_HELP_STRING([[--with-plugin-ld=[ARG]]], [specify the plugin linker])],
[if test x"$withval" != x; then
Re: [3/8] Add narrow_bit_field_mem
> Tested as described in the covering note. OK to install? > > Richard > > > gcc/ > * expmed.c (narrow_bit_field_mem): New function. > (store_bit_field_using_insv, store_bit_field_1, store_fixed_bit_field) > (extract_bit_field_1): Use it. This looks better now, thanks. -- Eric Botcazou
Re: [2/8] Add adjust_bitfield_address_size
> Tested as described in the covering note. OK to install? > > Richard > > > gcc/ > * expr.h (adjust_address_1): Add a size parameter. > (adjust_address, adjust_address_nv, adjust_bitfield_address) > (adjust_bitfield_address_nv): Adjust accordingly. > (adjust_bitfield_address_size): Define. > * emit-rtl.c (adjust_address_1): Add a size parameter. > Use it to set the size if MODE has no size. Check whether > the size matches before returning the original memref. > Require the size to be known for adjust_object. > (adjust_automodify_address_1, widen_memory_access): Update calls > to adjust_address_1. No objections by me. -- Eric Botcazou
Re: [1/8] Handle TRUNCATE in make_extraction
> Tested as described in the covering note. OK to install? > > Richard > > gcc/ > * combine.c (make_extraction): Handle TRUNCATEd INNERs. OK, thanks. -- Eric Botcazou
Invitation to use Google Talk
--- You've been invited by Claudiu Zissulescu to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-6d05ada042-4af1bd6b15-UsxLYA8higFMiMVCCKbLIKrPPKk To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/a-6d05ada042-4af1bd6b15-UsxLYA8higFMiMVCCKbLIKrPPKk?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team
Fix fallout of patch for PR rtl-optimization/54315
In the patch I installed for PR rtl-optimization/54315:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00745.html
the special code dealing with BLKmode in registers at the beginning of
store_field is disabled for CALL_EXPR:
/* If we are storing into an unaligned field of an aligned union that is
in a register, we may have the mode of TARGET being an integer mode but
MODE == BLKmode. In that case, get an aligned object whose size and
alignment are the same as TARGET and store TARGET into it (we can avoid
the store if the field being stored is the entire width of TARGET). Then
call ourselves recursively to store the field into a BLKmode version of
that object. Finally, load from the object into TARGET. This is not
very efficient in general, but should only be slightly more expensive
than the otherwise-required unaligned accesses. Perhaps this can be
cleaned up later. It's tempting to make OBJECT readonly, but it's set
twice, once with emit_move_insn and once via store_field. */
if (mode == BLKmode
&& (REG_P (target) || GET_CODE (target) == SUBREG)
&& TREE_CODE (exp) != CALL_EXPR)
{
rtx object = assign_temp (type, 1, 1);
rtx blk_object = adjust_address (object, BLKmode, 0);
if (bitsize != (HOST_WIDE_INT) GET_MODE_BITSIZE (GET_MODE (target)))
emit_move_insn (object, target);
store_field (blk_object, bitsize, bitpos,
bitregion_start, bitregion_end,
mode, exp, type, MEM_ALIAS_SET (blk_object), nontemporal);
emit_move_insn (target, object);
/* We want to return the BLKmode version of the data. */
return blk_object;
}
because PR rtl-optimization/54315 is about useless spills to the stack for
BLKmode values returned in registers. I didn't realize that this change also
affects the other 2 kinds of targets, namely those returning BLKmode values by
means of PARALLEL and those returning BLKmode values in memory. It turns out
that the change introduced 2 ACATS failures on SPARC64 (former kind) and 1
ACATS failure on SPARC (letter kind) because of this oversight.
Therefore, the attached patch adds the missing bits to store_field for the
other 2 kinds of targets, thus fixing the introduced regressions. However,
the code used for the latter kind is generic, i.e. it doesn't require that the
object being stored be a value returned from a function. As such, it makes
the above block of code totally useless. So the patch removes it altogether,
which makes the TYPE parameter of store_field useless, which in turn makes
the same parameter of store_constructor_field useless as well.
Bootstrapped/regtested on x86_64-suse-linux, sparc64-sun-solaris2.9, sparc-
sun-solaris2.10, powerpc-linux-gnu, ia64-linux-gnu and mips64el-linux-gnu
and applied on the mainline.
2012-11-10 Eric Botcazou
* expr.c (store_field): Remove TYPE parameter. Remove block of code
dealing with BLKmode in registers. Reimplement this support using
pseudo-registers and bit-field techniques.
(store_constructor_field): Remove TYPE parameter and adjust calls to
store_field.
(expand_assignment): Adjust calls to store_field. Add comment.
(store_expr): Add comment.
(store_constructor): Adjust calls to store_constructor_field.
(expand_expr_real_2): Adjust call to store_field.
--
Eric BotcazouIndex: expr.c
===
--- expr.c (revision 193322)
+++ expr.c (working copy)
@@ -137,12 +137,11 @@ static rtx compress_float_constant (rtx,
static rtx get_subtarget (rtx);
static void store_constructor_field (rtx, unsigned HOST_WIDE_INT,
HOST_WIDE_INT, enum machine_mode,
- tree, tree, int, alias_set_type);
+ tree, int, alias_set_type);
static void store_constructor (tree, rtx, int, HOST_WIDE_INT);
static rtx store_field (rtx, HOST_WIDE_INT, HOST_WIDE_INT,
unsigned HOST_WIDE_INT, unsigned HOST_WIDE_INT,
- enum machine_mode,
- tree, tree, alias_set_type, bool);
+ enum machine_mode, tree, alias_set_type, bool);
static unsigned HOST_WIDE_INT highest_pow2_factor_for_target (const_tree, const_tree);
@@ -4772,15 +4771,14 @@ expand_assignment (tree to, tree from, b
else if (bitpos + bitsize <= mode_bitsize / 2)
result = store_field (XEXP (to_rtx, 0), bitsize, bitpos,
bitregion_start, bitregion_end,
- mode1, from, TREE_TYPE (tem),
+ mode1, from,
get_alias_set (to), nontemporal);
else if (bitpos >= mode_bitsize / 2)
result = store_field (XEXP (to_rtx, 1), bitsize,
bitpos - mode_bitsize / 2,
bitregion_start, bitregion_end,
mode1, from,
- TREE_TYPE (tem), get_alias_set (to),
- nontemporal);
+ get_alias_set (to), nontemporal);
else if (bitpos == 0 && bitsize == mode_bitsize)
{
rtx from_rtx;
@@ -4801,8 +4799,7 @@ expand_assig
Re: [PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll
On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote: > I had reckoned that the behaviour could be reverted to what was before > while I figure out a way to get the warning in place for both cases, > i.e. with tree-vrp (where max_loop_iterations now causes the loop to > be folded away in -O2) and this unroll case (in -O1). I'll look at > getting a warning for the tree-vrp case separately if the infinite > loop behaviour needs to be retained. I'm sorry, I won't be able to get this done today. The patch causes a regression with torture/pr49518.c where it gives out the warning when it shouldn't. I had seen this warning earlier (with the earlier behaviour of not removing the exits) and fixed it, but it has reappeared now, perhaps due to some recent patch that removes more exits or something else. I'll get back on this late next week since I'll be offline for most of the week (it's holiday season here in India). Siddhesh
Re: [asan] Patch - fix an ICE in asan.c
Tobias Burnus wrote:
So untested:
Thanks for the patch! It fixed the problem half way: It fixes the
second issue I had (fail10.ii,
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ).
However, it didn't fix the original problem: As the call for strlen
directly returns, it never reaches your patch. Hence, it doesn't fix
fail31.ii of http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00786.html
If one uses the same line for strlen, it works.
I spoke too early. With the updated patch, there is no ICE, but one
crashes for the following valid program with:
==27313== ERROR: AddressSanitizer crashed on unknown address
0x13fffe8fc737 (pc 0x004008e3 sp 0x7fffa3f1c6d0 bp 0x7fffa3f1c700 T0)
AddressSanitizer can not provide additional info.
The crucial part is the "strlen" call.
#include
#include
int main(int argc, char *argv[])
{
int i;
for (i = 0; i < argc; i++)
{
printf("%d: '%s':%zd\n", i, argv[i], strlen(argv[i]));
}
return 0;
}
Tobias
Re: [PATCH] Fix combined tree for LTO
Il 10/11/2012 05:30, Andrew Pinski ha scritto: > Hi, > The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not > the final installed binary name. This patch fixes the problem by > changing if we got ld-new to just ld. > Note this issue has been around since 4.6 but not many people test > installed binary and it does not show up while doing testing from the > combined tree either. > > OK? Bootstrapped and tested with and without being in a combined tree > without any regressions. OK with one change: please make it test collect-ld as well. Paolo > Thanks, > Andrew Pinski > > * configure.ac: Set PLUGIN_LD_SUFFIX to just "ld" if it was "ld-new". > * configure: Regenerate. >
Re: PATCH: Handle ZERO_EXTEND offsettable address
Il 10/11/2012 07:44, H.J. Lu ha scritto:
> Hi,
>
> In
>
> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
> {*movti_internal_rex64}
> (expr_list:REG_DEAD (reg:SI 82)
> (expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
> (const_int -16 [0xfff0])) [0 sym+0 S16 A64])
>
> we fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
> This patch adds ZERO_EXTEND support to adjust_address_1 and
> offsettable_address_addr_space_p. Tested on Linux/x32. OK to install?
Is there any reason why SIGN_EXTEND should be handled differently?
(Just asking, I don't know this code well).
Paolo
> Thanks.
>
>
> H.J.
> ---
> gcc/
>
> 2012-11-10 H.J. Lu
>
> PR rtl-optimization/55247
> PR middle-end/55259
> * emit-rtl.c (adjust_address_1): Handle ZERO_EXTEND.
> * recog.c (offsettable_address_addr_space_p): Likewise.
>
> gcc/testsuite/
>
> 2012-11-10 H.J. Lu
>
> PR rtl-optimization/55247
> PR middle-end/55259
>
> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> index 95bbfa7..d7c454c 100644
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -2109,6 +2109,12 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
> HOST_WIDE_INT offset,
> addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
> plus_constant (address_mode,
> XEXP (addr, 1), offset));
> + else if (GET_CODE (addr) == ZERO_EXTEND)
> + {
> + addr = XEXP (addr, 0);
> + addr = plus_constant (GET_MODE (addr), addr, offset);
> + addr = gen_rtx_ZERO_EXTEND (address_mode, addr);
> + }
>else
> addr = plus_constant (address_mode, addr, offset);
> }
> diff --git a/gcc/recog.c b/gcc/recog.c
> index ee68e30..d3dd591 100644
> --- a/gcc/recog.c
> +++ b/gcc/recog.c
> @@ -1934,15 +1934,21 @@ int
> offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
> addr_space_t as)
> {
> - enum rtx_code ycode = GET_CODE (y);
> + enum rtx_code ycode;
>rtx z;
> - rtx y1 = y;
> + rtx y1;
>rtx *y2;
>int (*addressp) (enum machine_mode, rtx, addr_space_t) =
> (strictp ? strict_memory_address_addr_space_p
>: memory_address_addr_space_p);
>unsigned int mode_sz = GET_MODE_SIZE (mode);
>
> + if (GET_CODE (y) == ZERO_EXTEND)
> +y = XEXP (y, 0);
> +
> + ycode = GET_CODE (y);
> + y1 = y;
> +
>if (CONSTANT_ADDRESS_P (y))
> return 1;
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr55247.c
> b/gcc/testsuite/gcc.target/i386/pr55247.c
> new file mode 100644
> index 000..594139e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr55247.c
> @@ -0,0 +1,35 @@
> +/* { dg-do compile { target { ! { ia32 } } } } */
> +/* { dg-require-effective-target maybe_x32 } */
> +/* { dg-options "-O -mno-sse -mno-mmx -mx32 -maddress-mode=long" } */
> +
> +typedef unsigned int uint32_t;
> +typedef uint32_t Elf32_Word;
> +typedef uint32_t Elf32_Addr;
> +typedef struct {
> + Elf32_Word st_name;
> + Elf32_Addr st_value;
> + Elf32_Word st_size;
> + unsigned char st_other;
> +} Elf32_Sym;
> +typedef struct {
> + Elf32_Word r_info;
> +}
> +Elf32_Rela;
> +typedef struct {
> + union {
> +Elf32_Addr d_ptr;
> + }
> + d_un;
> +} Elf32_Dyn;
> +struct link_map {
> + Elf32_Dyn *l_info[34];
> +};
> +extern void symbind32 (Elf32_Sym *);
> +void
> +_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
> +{
> + const Elf32_Sym *const symtab = (const void *) l->l_info[6]->d_un.d_ptr;
> + const Elf32_Rela *const reloc = (const void *) (l->l_info[23]->d_un.d_ptr
> + reloc_arg * sizeof (Elf32_Rela));
> + Elf32_Sym sym = symtab[(reloc->r_info) >> 8];
> + symbind32 (&sym);
> +}
>
[PATCH} AIX Testsuite cleanup
A few more testsuite fixes to address failures on AIX. The only
really interesting one is g++.dg/other/anon5.C where Undefined is
capitalized in the AIX error message.
Thanks, David
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
* c-c++-common/vector-compare-1.c: Same.
* c-c++-common/vector-compare-2.c: Same.
* g++.dg/other/unused1.C: Skip on AIX.
* g++.dg/other/anon5.C: Allow Undefined to be capitalized. Ignore
extra message on AIX.
Index: other/anon5.C
===
--- other/anon5.C (revision 193385)
+++ other/anon5.C (working copy)
@@ -1,6 +1,8 @@
// PR c++/34094
// { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
// { dg-options "-g" }
+// Ignore additional message on powerpc-ibm-aix
+// { dg-prune-output "obtain more information" } */
namespace {
struct c
@@ -11,7 +13,7 @@
const bool &f()
{
- return c::t; // { dg-message "undefined" "undefined" { target *-*-* } 0 }
+ return c::t; // { dg-message "\[Uu\]ndefined" "undefined" { target
*-*-* } 0 }
// Some targets report the error for the previous line, others
// don't give line number inforamtion for it, so use line 0.
}
Re: libstdc++ PATCH to use __cplusplus rather than __GXX_EXPERIMENTAL_CXX0X__
On 9 November 2012 22:09, Jason Merrill wrote: > Now that G++ uses the value of __cplusplus specified by the standard, we > don't need the other macro anymore. > > OK for trunk, or should I save it for the next stage 1? > > Jason I'd been thinking about suggesting that change just the other day - do it!
*ping* [patch, fortran] PR 30146, errors for INTENT(OUT) and INTENT(INOUT) for DO loop variables
I wrote: after the dicsussion on c.l.f, it become clear that passing a DO loop variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error. The attached patch throws an error for both cases. I chose to issue the errors as a front-end pass because we cannot check for formal arguments during parsing (where the other checks are implemented). Regression-tested. OK for trunk? Ping ** 1.4285 ? Thomas
Re: [asan] Patch - fix an ICE in asan.c
Jakub Jelinek wrote: --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 +++ gcc/asan.c 2012-11-09 21:26:00.0 +0100 @@ -1362,6 +1362,8 @@ transform_statements (void) instrument_assignment (&i); else if (is_gimple_call (s)) maybe_instrument_call (&i); + if (gsi_end_p (i)) + break; } } } That looks a wrong place for this. I already expected that it was not fully correct ;-) So untested: Thanks for the patch! It fixed the problem half way: It fixes the second issue I had (fail10.ii, http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ). However, it didn't fix the original problem: As the call for strlen directly returns, it never reaches your patch. Hence, it doesn't fix fail31.ii of http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00786.html If one uses the same line for strlen, it works. Updated patches attached – one is on top of the trunk + Dodji's patches, the other is on top of the asan branch. * * * The question is whether one also needs to do something for the atomics handling in maybe_instrument_builtin_call, which has: instrument_derefs (iter, dest, loc, is_store); return; The instrument_derefs calls - in some cases - build_check_stmt, which in turn calls: *iter = gsi_start_bb (else_bb) Tobias (This patch is for the "trunk" after the asan integration patches.) 2012-11-10 Jakub Jelinek Tobias Burnus * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 +++ gcc/asan.c 2012-11-10 13:44:51.0 +0100 @@ -1068,6 +1068,7 @@ instrument_builtin_call (gimple_stmt_ite case BUILT_IN_STRLEN: instrument_strlen_call (iter); + *iter = gsi_for_stmt (call); return; /* And now the __atomic* and __sync builtins. @@ -1307,6 +1308,7 @@ instrument_builtin_call (gimple_stmt_ite else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); } } (This patch is for the "asan" branch.) 2012-11-10 Jakub Jelinek Tobias Burnus * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. diff --git a/gcc/asan.c b/gcc/asan.c index 155e84b..3297b52 100644 --- a/gcc/asan.c +++ b/gcc/asan.c @@ -952,6 +952,7 @@ maybe_instrument_builtin_call (gimple_stmt_iterator *iter) case BUILT_IN_STRLEN: instrument_strlen_call (iter); + *iter = gsi_for_stmt (call); return true; /* And now the __atomic* and __sync builtins. @@ -1191,6 +1192,7 @@ maybe_instrument_builtin_call (gimple_stmt_iterator *iter) else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); return true; } return false;
[PATCH, i386]: Fix PR 55247, ICE: Max. number of generated reload insns per insn is achieved
Hello!
Attached patch disparages riF->o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as offsetable. H.J. will propose a patch for
this [2].
2012-11-10 Vladimir Makarov
Uros Bizjak
PR target/55247
* config/i386/i386.md (*movti_internal_rex64): Add "!" to riF->o
alternative.
testsuite/ChangeLog:
2012-11-10 Uros Bizjak
PR target/55247
* gcc.target/i386/pr55247.c: New test.
Tested on x86_64-linux-gnu {,m32} and committed to mainline SVN.
[1] gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c2
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c6
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 193387)
+++ config/i386/i386.md (working copy)
@@ -1874,7 +1874,7 @@
(const_string "OI")))])
(define_insn "*movti_internal_rex64"
- [(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,x,x ,m")
+ [(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,!o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,riF,C,xm,x"))]
"TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
Index: testsuite/gcc.target/i386/pr55247.c
===
--- testsuite/gcc.target/i386/pr55247.c (revision 0)
+++ testsuite/gcc.target/i386/pr55247.c (working copy)
@@ -0,0 +1,38 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-options "-O2 -mx32 -maddress-mode=long -mno-sse" } */
+
+typedef unsigned int uint32_t;
+typedef unsigned int uintptr_t;
+typedef uint32_t Elf32_Word;
+typedef uint32_t Elf32_Addr;
+typedef struct {
+ Elf32_Word st_name;
+ Elf32_Addr st_value;
+ Elf32_Word st_size;
+ unsigned char st_other;
+} Elf32_Sym;
+typedef struct {
+ Elf32_Word r_info;
+}
+Elf32_Rela;
+typedef struct {
+ union {
+Elf32_Addr d_ptr;
+ }
+ d_un;
+} Elf32_Dyn;
+struct link_map {
+ Elf32_Dyn *l_info[34];
+};
+typedef struct link_map *lookup_t;
+extern void symbind32 (Elf32_Sym *);
+void
+_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
+{
+ const Elf32_Sym *const symtab = (const void *) (l)->l_info[6]->d_un.d_ptr;
+ const Elf32_Rela *const reloc = (const void *) ((l)->l_info[23]->d_un.d_ptr
+ reloc_arg * sizeof (Elf32_Rela));
+ const Elf32_Sym *refsym = &symtab[((reloc->r_info) >> 8)];
+ const Elf32_Sym *defsym = refsym;
+ Elf32_Sym sym = *defsym;
+ symbind32 (&sym);
+}
Re: [asan] Patch - fix an ICE in asan.c
On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote: > * I still have to do an all-language bootstrap and regtesting, > though the latter is probably pointless as there is currently not a > single -fasan test case. > --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 > +++ gcc/asan.c2012-11-09 21:26:00.0 +0100 > @@ -1362,6 +1362,8 @@ transform_statements (void) > instrument_assignment (&i); > else if (is_gimple_call (s)) > maybe_instrument_call (&i); > + if (gsi_end_p (i)) > + break; > } > } > } That looks a wrong place for this. Instead, maybe_instrument_call should ensure that *iter is set to the last stmt that shouldn't be instrumented. instrument_derefs does that correctly, so assignments and __atomic/__sync builtins should be correct (*iter is set to the assignment/call), for strlen call it seems to DTRT, but for other builtin calls it would leave *iter elsewhere. As we want to scan for accesses the rest of the bb that contained the call (but that bb after splitting already is above the highest bb number to be insturmented), we need to keep *iter at the call we just processed, so if there are say two consecutive calls the second one is going to be processed. So untested: 2012-11-10 Jakub Jelinek * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. --- gcc/asan.c.jj 2012-11-02 00:09:22.0 +0100 +++ gcc/asan.c 2012-11-10 10:00:03.717715834 +0100 @@ -1191,6 +1191,7 @@ maybe_instrument_builtin_call (gimple_st else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); return true; } return false; Jakub
Re: libstdc++ PATCH to use __cplusplus rather than __GXX_EXPERIMENTAL_CXX0X__
Ed Smith-Rowland <3dw...@verizon.net> ha scritto: >Paolo? ... carte blanche to Jason! (but I have a little lexer tweak pending... ;) Paolo
