Re: [PATCH] Fix _Hashtable::erase(iterator, iterator) (PR libstdc++/51845)
On Thu, Jan 19, 2012 at 12:16:01AM +0100, Jakub Jelinek wrote:
> As described in the PR, if two argument erase is removing the last
> element of one bucket (i.e. the one referenced in _M_buckets array
> for the next bucket) and then at least one element from the
> following bucket, but not all elements from that next bucket,
> __is_bucket_begin is initially false and in the second for (;;) iteration,
> while it is already true, __n_bkt == __bkt and thus _M_remove_bucket_begin
> doesn't do anything, and following if (__n && __n_bkt != __bkt) is
> false as well (1 && 0), thus nothing is changed in the _M_buckets array
> and we end up referencing there a removed element. We might crash if we
> read it and if we modify it, we usually corrupt malloc data structures.
If you want a testcase that fails on x86_64-linux without the patch and
succeeds with it, here it is:
2012-01-19 Jakub Jelinek
PR libstdc++/51845
* testsuite/23_containers/unordered_multimap/erase/51845-multimap.cc:
New test.
---
libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/51845-multimap.cc.jj
2012-01-19 09:23:56.667642676 +0100
+++
libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/51845-multimap.cc
2012-01-19 09:24:50.253325306 +0100
@@ -0,0 +1,72 @@
+// { dg-options "-std=gnu++0x" }
+
+// 2012-01-19 Jakub Jelinek
+//
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling
2012/1/18 Jason Merrill : > I still think the problem is that we're applying the attributes more than > once, and we should only apply them once. If we fix that, we don't need to > merge them. > > Jason Well, I will try to search for it a bit more. Nevertheless is the chaining at this place IMHO a pretty bad idea. The merging of attributes looks more sane. Also is this merging patch pretty less invasive and would be fine for older branches, too. The issue I see by changing here do_friend and calls to attribute-modifier is, that it easily causes side-effects, which are escaping underdected for awhile. Kai
Re: [PATCH] Fix PR 51505
On 01/19/2012 08:34 AM, Jakub Jelinek wrote: > >Ok, thanks for working on this. > Installed, do you want this for 4.6/4.5? If yes, please give it at least a couple of weeks on the trunk. It's fine by me but yes, let's give it time to bake. Paolo
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
if test "x${build}" = "x${target}"&& test "x${build}" = "x${host}"; then
This test is no longer necessary, is it? ia64 does its own cross-compile
detection via AC_RUN_IFELSE, and other hosts are cross-compile safe.
The patch is okay if you remove it.
H.J., can ia64 fall back to the common test when cross compiling? Or
perhaps even always?
Paolo
Re: [PATCH] Fix PR 33512 Folding of x & ((~x) | y) into x & y on the tree level
On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther
wrote:
> On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski
> wrote:
>> Hi,
>> This adds the folding of x & ((~x) | y)) into x & y on the tree
>> level via fold-const.c
>> There is already partly done on the RTL level but it would be a good
>> thing for the tree level also.
>>
>>
>> OK for 4.8 (yes I know we have not branched yet but I thought I would
>> send it out so I don't forget about it)?
>> Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>
> Can you instead patch tree-ssa-forwprop.c:simplify_bitwise_binary?
Yes and here is a new patch which also adds optimizing x | ((~x) & y)) to x | y.
Also it adds the optimizing x & (x | y) to x and x | (x & y) to x to
tree-ssa-forwprop.c:simplify_bitwise_binary
since it was an easy extension on top of the ~x case (well I
implemented the one without the ~ first). I did not remove those
folding from fold-const.c though.
Also I was thinking maybe this belongs in reassociate though I don't
see how to do it.
OK for 4.8, once in stage 1? Again bootstrapped and tested on
x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
ChangeLog:
* tree-ssa-forwprop.c (defcodefor_name): New function.
(simplify_bitwise_binary): Use defcodefor_name.
Simplify "( X | Y) & X" to X and "( X & Y) | X" to X.
Simplify "(~X | Y) & X" to "X & Y" and
"(~X & Y) | X" to "X | Y".
testsuite/ChangeLog:
* gcc.dg/tree-ssa/andor-3.c: New testcase.
* gcc.dg/tree-ssa/andor-4.c: New testcase.
* gcc.dg/tree-ssa/andor-5.c: New testcase.
>
> Thanks,
> Richard.
>
>> Thanks,
>> Andrew Pinski
>>
>> ChangeLog:
>> * fold-const.c (fold_binary_loc ): Add folding of x
>> & (~x | y) into x & y.
>>
>> testsuite/ChangeLog:
>> * gcc.dg/tree-ssa/andor-3.c: New testcase.
Index: testsuite/gcc.dg/tree-ssa/andor-3.c
===
--- testsuite/gcc.dg/tree-ssa/andor-3.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/andor-3.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f(int y, int x)
+{
+ return x & ((~x) | y);
+}
+int f1(int y, int x)
+{
+ return x & (y | (~x));
+}
+int f2(int y, int x)
+{
+ return ((~x) | y) & x;
+}
+int f3(int y, int x)
+{
+ return (y | (~x)) & x;
+}
+
+
+/* { dg-final { scan-tree-dump-times "~x" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "x_..D. \& y_..D." 4 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: testsuite/gcc.dg/tree-ssa/andor-4.c
===
--- testsuite/gcc.dg/tree-ssa/andor-4.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/andor-4.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f(int y, int x)
+{
+ return x | ((~x) & y);
+}
+int f1(int y, int x)
+{
+ return x | (y & (~x));
+}
+int f2(int y, int x)
+{
+ return ((~x) & y) | x;
+}
+int f3(int y, int x)
+{
+ return (y & (~x)) | x;
+}
+
+
+/* { dg-final { scan-tree-dump-times "~x" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "x_..D. \\\| y_..D." 4 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: testsuite/gcc.dg/tree-ssa/andor-5.c
===
--- testsuite/gcc.dg/tree-ssa/andor-5.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/andor-5.c (revision 0)
@@ -0,0 +1,50 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f(int y, int x)
+{
+ int a = x | y;
+ return a & x;
+}
+int f1(int y, int x)
+{
+ int a = y | x;
+ return a & x;
+}
+int f2(int y, int x)
+{
+ int a = x | y;
+ return x & a;
+}
+int f3(int y, int x)
+{
+ int a = x | y;
+ return x & a;
+}
+int f4(int y, int x)
+{
+ int a = x & y;
+ return a | x;
+}
+int f5(int y, int x)
+{
+ int a = y & x;
+ return a | x;
+}
+int f6(int y, int x)
+{
+ int a = x & y;
+ return x | a;
+}
+int f7(int y, int x)
+{
+ int a = x & y;
+ return x | a;
+}
+/* These all should be optimized to just return x; */
+
+
+/* { dg-final { scan-tree-dump-times "\\\|" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\&" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "return x_..D.;" 8 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 183295)
+++ tree-ssa-forwprop.c (working copy)
@@ -1742,6 +1742,24 @@ simplify_bitwise_binary_1 (enum tree_cod
return NULL_TREE;
}
+/* Given a ssa_name in NAME see if it was defined by an assignment and
+ set CODE to be the code and ARG1 to the first operand on the rhs and ARG2
+ to the second operand on the rhs. */
+static inline void
+defcodefor_name (tree name, enum tree_code *code, tree *arg1, tree *arg2)
+{
+ gimple def;
+ gcc_assert (TREE_CODE (name) == SSA_NAME);
+ def = SSA_NAME_DEF_STMT (na
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On Thu, Jan 19, 2012 at 09:54:43AM +0100, Paolo Bonzini wrote:
> On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
> >if test "x${build}" = "x${target}"&& test "x${build}" = "x${host}"; then
>
> This test is no longer necessary, is it? ia64 does its own
> cross-compile detection via AC_RUN_IFELSE, and other hosts are
> cross-compile safe. The patch is okay if you remove it.
While the linker test is done using the target linker (it uses default
linker flags btw, so in case a linker would be buggy for one target and not
for a different target also supported by the same linker, it would be
a problem, but let's assume that the linker is either buggy or not for
all targets it supports), AC_PREPROC_IFELSE is done using the host compiler.
For cross-compiling we would need to check the target libc headers.
For glibc we could certainly do something similar to the
case "$target" in
*-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu)
[# glibc 2.4 and later provides __stack_chk_fail and
# either __stack_chk_guard, or TLS access to stack guard canary.
if test -f $target_header_dir/features.h \
&& $EGREP '^[ ]*#[]*define[ ]+__GNU_LIBRARY__[
]+([1-9][0-9]|[6-9])' \
$target_header_dir/features.h > /dev/null; then
if $EGREP '^[ ]*#[]*define[ ]+__GLIBC__[
]+([1-9][0-9]|[3-9])' \
$target_header_dir/features.h > /dev/null; then
gcc_cv_libc_provides_ssp=yes
elif $EGREP '^[ ]*#[]*define[ ]+__GLIBC__[]+2' \
$target_header_dir/features.h > /dev/null \
&& $EGREP '^[ ]*#[]*define[ ]+__GLIBC_MINOR__[
]+([1-9][0-9]|[4-9])' \
$target_header_dir/features.h > /dev/null; then
gcc_cv_libc_provides_ssp=yes
fi
fi]
test configure already does (and glibc only supports ELF targets, so
the ELF check could be avoided).
> H.J., can ia64 fall back to the common test when cross compiling?
> Or perhaps even always?
I've kept ia64 as is because that is what we did for ia64 configure already
in 4.6 and earlier. As ia64 was using .init_array etc. far before the
linker merging of .ctors and .init_array has been fixed, probably it just
switched over to .init_array completely many years ago or something.
Jakub
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
On Wed, 18 Jan 2012, Aldy Hernandez wrote: > On 01/18/12 03:09, Richard Guenther wrote: > > On Tue, 17 Jan 2012, Aldy Hernandez wrote: > > > > > > > > > > What I have in mind is to abstract out the initialization of TM > > > > > builtins > > > > > from > > > > > gtm-builtins.def (through its inclusion in builtins.def) into a > > > > > separate > > > > > function that we can call either in c_define_builtins() from the C-ish > > > > > front-ends, or from lto_define_builtins (once we encounter a TM > > > > > builtin > > > > > and > > > > > enable flag_tm appropriately). > > > > > > > > Hm? They are included in builtins.def, that looks appropriate for > > > > middle-end builtins. Thus they should be initialized by lto1, too. > > > > Are they not? > > > > > > Since flag_tm is NULL, when lto_define_builtins runs, the TM builtins do > > > not > > > get initialized. This is because DEF_TM_BUILTIN is predicated on flag_tm. > > > > Ok, so arrange that -fgnu-tm is enabled at link-time as soon as it was > > enabled in one TU. You can do that alongside handling of OPT_fPIC, etc. > > in lto-wrapper.c:merge_and_complain. > > The following patch fixes the problem. > > OK? Ok. Thanks, Richard.
[PATCH] Fix up aliasing violations in src/ia64/ffi.c (PR rtl-optimization/48496)
Hi!
For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
aliasing by accessing the same object through incompatible lvalues
(in an asm operand through float resp. double lvalue and on the next
line through UINT32 resp. UINT64 lvalue.
GCC apparently errors out on this while reloading the asm, but only
without -fno-strict-aliasing, which it shouldn't, nevertheless IMHO
libffi shouldn't violate aliasing in the first place, which I'd say
would demote that PR from P1 to P2.
For FFI_TYPE_LONGDOUBLE we already do the right thing.
Ok for trunk?
2012-01-19 Jakub Jelinek
PR rtl-optimization/48496
* src/ia64/ffi.c (ffi_call): Fix up aliasing violations.
--- libffi/src/ia64/ffi.c 2010-08-11 21:08:14.0 +0200
+++ libffi/src/ia64/ffi.c 2012-01-14 18:43:35.652923850 +0100
@@ -324,13 +324,17 @@ ffi_call(ffi_cif *cif, void (*fn)(void),
case FFI_TYPE_FLOAT:
if (gpcount < 8 && fpcount < 8)
stf_spill (&stack->fp_regs[fpcount++], *(float *)avalue[i]);
- stack->gp_regs[gpcount++] = *(UINT32 *)avalue[i];
+ {
+ UINT32 tmp;
+ memcpy (&tmp, avalue[i], sizeof (UINT32));
+ stack->gp_regs[gpcount++] = tmp;
+ }
break;
case FFI_TYPE_DOUBLE:
if (gpcount < 8 && fpcount < 8)
stf_spill (&stack->fp_regs[fpcount++], *(double *)avalue[i]);
- stack->gp_regs[gpcount++] = *(UINT64 *)avalue[i];
+ memcpy (&stack->gp_regs[gpcount++], avalue[i], sizeof (UINT64));
break;
case FFI_TYPE_LONGDOUBLE:
Jakub
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On 01/19/2012 10:06 AM, Jakub Jelinek wrote: While the linker test is done using the target linker (it uses default linker flags btw, so in case a linker would be buggy for one target and not for a different target also supported by the same linker, it would be a problem, but let's assume that the linker is either buggy or not for all targets it supports), AC_PREPROC_IFELSE is done using the host compiler. For cross-compiling we would need to check the target libc headers. Ah, right, so the patch is okay. For glibc we could certainly do something similar to the case "$target" in *-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu) [# glibc 2.4 and later provides __stack_chk_fail and # either __stack_chk_guard, or TLS access to stack guard canary. if test -f $target_header_dir/features.h \ && $EGREP '^[ ]*#[]*define[ ]+__GNU_LIBRARY__[ ]+([1-9][0-9]|[6-9])' \ $target_header_dir/features.h> /dev/null; then if $EGREP '^[ ]*#[]*define[ ]+__GLIBC__[ ]+([1-9][0-9]|[3-9])' \ $target_header_dir/features.h> /dev/null; then gcc_cv_libc_provides_ssp=yes elif $EGREP '^[ ]*#[]*define[ ]+__GLIBC__[]+2' \ $target_header_dir/features.h> /dev/null \ && $EGREP '^[ ]*#[]*define[ ]+__GLIBC_MINOR__[ ]+([1-9][0-9]|[4-9])' \ $target_header_dir/features.h> /dev/null; then gcc_cv_libc_provides_ssp=yes fi fi] Or something like (cat $target_header_dir/features.h; echo glibc_so_ver=__GNU_LIBRARY__ echo glibc_ver=__GLIBC__ echo glibc_minor_ver=__GLIBC_MINOR__) | gcc -x c - | \ grep ^glibc.*ver= > glibc-ver.sh . glibc.sh which could be moved more easily to a helper macro. Paolo
[PATCH] Testcase for PR37997
... which is confused about a useful testcase not using uninitialized
variables.
Testcase committed.
Richard.
2012-01-19 Richard Guenther
PR tree-optimization/37997
* gcc.dg/tree-ssa/ssa-pre-28.c: New testcase.
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c (revision 0)
@@ -0,0 +1,21 @@
+/* PR37997 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-pre-details" } */
+
+int foo (int i, int b, int result)
+{
+ int mask;
+ if (b)
+mask = -1;
+ else
+mask = 0;
+ result = i + 1;
+ result = result & mask;
+ return result;
+}
+
+/* We should insert i + 1 into the if (b) path as well as the simplified
+ i + 1 & -1 expression. And do replacement with two PHI temps. */
+
+/* { dg-final { scan-tree-dump-times "with prephitmp" 2 "pre" } } */
+/* { dg-final { cleanup-tree-dump "pre" } } */
Re: [PATCH] Fix up aliasing violations in src/ia64/ffi.c (PR rtl-optimization/48496)
On Thu, 19 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
> aliasing by accessing the same object through incompatible lvalues
> (in an asm operand through float resp. double lvalue and on the next
> line through UINT32 resp. UINT64 lvalue.
> GCC apparently errors out on this while reloading the asm, but only
> without -fno-strict-aliasing, which it shouldn't, nevertheless IMHO
> libffi shouldn't violate aliasing in the first place, which I'd say
> would demote that PR from P1 to P2.
> For FFI_TYPE_LONGDOUBLE we already do the right thing.
> Ok for trunk?
Ok.
Thanks,
Richard.
> 2012-01-19 Jakub Jelinek
>
> PR rtl-optimization/48496
> * src/ia64/ffi.c (ffi_call): Fix up aliasing violations.
>
> --- libffi/src/ia64/ffi.c 2010-08-11 21:08:14.0 +0200
> +++ libffi/src/ia64/ffi.c 2012-01-14 18:43:35.652923850 +0100
> @@ -324,13 +324,17 @@ ffi_call(ffi_cif *cif, void (*fn)(void),
> case FFI_TYPE_FLOAT:
> if (gpcount < 8 && fpcount < 8)
> stf_spill (&stack->fp_regs[fpcount++], *(float *)avalue[i]);
> - stack->gp_regs[gpcount++] = *(UINT32 *)avalue[i];
> + {
> + UINT32 tmp;
> + memcpy (&tmp, avalue[i], sizeof (UINT32));
> + stack->gp_regs[gpcount++] = tmp;
> + }
> break;
>
> case FFI_TYPE_DOUBLE:
> if (gpcount < 8 && fpcount < 8)
> stf_spill (&stack->fp_regs[fpcount++], *(double *)avalue[i]);
> - stack->gp_regs[gpcount++] = *(UINT64 *)avalue[i];
> + memcpy (&stack->gp_regs[gpcount++], avalue[i], sizeof (UINT64));
> break;
>
> case FFI_TYPE_LONGDOUBLE:
>
> Jakub
>
>
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH] Fix _Hashtable::erase(iterator, iterator) (PR libstdc++/51845)
On 01/19/2012 12:16 AM, Jakub Jelinek wrote: Fixed thusly, if __is_bucket_begin is true, then we know __n is the first item in its bucket and thus __prev_n should be in the _M_buckets array. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok, the testcase too of course. Thanks for taking care of this, Jakub. Paolo.
Re: [PATCH] Fix _Hashtable::erase(iterator, iterator) (PR libstdc++/51845)
On 19 January 2012 08:36, Jakub Jelinek wrote: > > If you want a testcase that fails on x86_64-linux without the patch and > succeeds with it, here it is: Thanks, Jakub, the analysis and patch look right, OK to checkin with the testcase.
*ping* - libiberty: Fix "make pdf" for copying-lib.texi
* PING *
On 01/09/2012 03:59 PM, Tobias Burnus wrote:
"make pdf" fails with:
libiberty/copying-lib.texi:481: This command can
appear only outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
@fi
@sectionheading #1#2#3#4->{@checkenv {}
@csname #2fonts@endcsname
@rmisbold @...
@\heading ...tionheading {#1}{sec}{Yomitfromtoc}{}
@suppressfirstparagraphin...
l.481 @heading NO WARRANTY
The patch below fixes the issue, but I am not sure whether the
numbering should continue with "15.". (Which is the current result in
"info" or when continuing with "enter".)
OK?
Tobias
PS: Does this need special care, e.g. for sourceware?
--- a/libiberty/copying-lib.texi
+++ b/libiberty/copying-lib.texi
@@ -475,6 +475,7 @@ Software Foundation; we sometimes make exceptions
for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
+@end enumerate
@iftex
@heading NO WARRANTY
@@ -483,6 +484,7 @@ and reuse of software generally.
@center NO WARRANTY
@end ifinfo
+@enumerate 15
@item
BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
Re: [PATCH] Fix PR 33512 Folding of x & ((~x) | y) into x & y on the tree level
On Thu, Jan 19, 2012 at 10:00 AM, Andrew Pinski wrote: > On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther > wrote: >> On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski >> wrote: >>> Hi, >>> This adds the folding of x & ((~x) | y)) into x & y on the tree >>> level via fold-const.c >>> There is already partly done on the RTL level but it would be a good >>> thing for the tree level also. >>> >>> >>> OK for 4.8 (yes I know we have not branched yet but I thought I would >>> send it out so I don't forget about it)? >>> Bootstrapped and tested on x86_64-linux-gnu with no regressions. >> >> Can you instead patch tree-ssa-forwprop.c:simplify_bitwise_binary? > > Yes and here is a new patch which also adds optimizing x | ((~x) & y)) to x | > y. > Also it adds the optimizing x & (x | y) to x and x | (x & y) to x to > tree-ssa-forwprop.c:simplify_bitwise_binary > since it was an easy extension on top of the ~x case (well I > implemented the one without the ~ first). I did not remove those > folding from fold-const.c though. > > Also I was thinking maybe this belongs in reassociate though I don't > see how to do it. I still have plans to create that piecewise gimple_fold (see my proposal from early last year) that would be the container for this kind of pattern matching. It would then be usable from reassoc as well (but reassoc has the issue of only collecting one kind of op, so its simplification wouldn't trigger reliably on these). http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01099.html > OK for 4.8, once in stage 1? Again bootstrapped and tested on > x86_64-linux-gnu with no regressions. Ok. Thanks, Richard. > Thanks, > Andrew Pinski > > ChangeLog: > * tree-ssa-forwprop.c (defcodefor_name): New function. > (simplify_bitwise_binary): Use defcodefor_name. > Simplify "( X | Y) & X" to X and "( X & Y) | X" to X. > Simplify "(~X | Y) & X" to "X & Y" and > "(~X & Y) | X" to "X | Y". > > testsuite/ChangeLog: > * gcc.dg/tree-ssa/andor-3.c: New testcase. > * gcc.dg/tree-ssa/andor-4.c: New testcase. > * gcc.dg/tree-ssa/andor-5.c: New testcase. > > >> >> Thanks, >> Richard. >> >>> Thanks, >>> Andrew Pinski >>> >>> ChangeLog: >>> * fold-const.c (fold_binary_loc ): Add folding of x >>> & (~x | y) into x & y. >>> >>> testsuite/ChangeLog: >>> * gcc.dg/tree-ssa/andor-3.c: New testcase.
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On Wed, 2012-01-18 at 22:25 +0100, Uros Bizjak wrote: > On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier > wrote: > > >> IMO, whatever the future decision would be, we shouldn't leave one > >> part of the compiler out-of-sync from the other. Proposed patch fixes > >> _current_ situation, where in the future, it is expected that compiler > >> and library changes in sync... > > > > > > So in order to keep them in sync, this should be also applied to libitm if > > your solution is chosen (At least to avoid confusion). > > If the Intel TM-ABI (no idea what's the status of this specification) > > specifies variadic function and regparm, it should be changed too. > > > > Index: libitm.h > > === > > --- libitm.h(revision 183273) > > +++ libitm.h(working copy) > > @@ -136,7 +136,7 @@ typedef uint64_t _ITM_transactionId_t; /* Transact > > > > extern _ITM_transactionId_t _ITM_getTransactionId(void) ITM_REGPARM; > > > > -extern uint32_t _ITM_beginTransaction(uint32_t, ...) ITM_REGPARM; > > +extern uint32_t _ITM_beginTransaction(uint32_t, ...); > > > > extern void _ITM_abortTransaction(_ITM_abortReason) ITM_REGPARM > > ITM_NORETURN; > > The spec does say that all function should be regparm(2), but I agree > that the above is less confusing. The attribute is ignored, but > perhaps a comment would clear this confusion even more. Uros, thanks for spotting the vararg issue. This looks okay to me, but Richard Henderson will have to OK this. If regparm(2) cannot work with variadic functions on x86, then I'd prefer removing the regparm. beginTransaction was switched to being variadic to allow communicating which kinds of versions a compiler has generated for the transaction's code (besides the default instrumentation that we have right now). I'd believe Ulrich Drepper's experience that making this variadic is better than restricting this to 64b (minus 10 bits or so already in use). BTW, would regparm(2) optimize on any arch/platform besides 32b x86? What about x32? Note that if we remove the regparm, we should also remove it on the other functions associated with txn begin (GTM_beginTransaction etc.). Torvald
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On Thu, 2012-01-19 at 13:24 +0100, Torvald Riegel wrote: > Note that if we remove the regparm, we should also remove it on the > other functions associated with txn begin (GTM_beginTransaction etc.). And update libitm.texi ...
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On Thu, Jan 19, 2012 at 1:24 PM, Torvald Riegel wrote: >> The spec does say that all function should be regparm(2), but I agree >> that the above is less confusing. The attribute is ignored, but >> perhaps a comment would clear this confusion even more. > > Uros, thanks for spotting the vararg issue. This looks okay to me, but > Richard Henderson will have to OK this. > > If regparm(2) cannot work with variadic functions on x86, then I'd > prefer removing the regparm. beginTransaction was switched to being > variadic to allow communicating which kinds of versions a compiler has > generated for the transaction's code (besides the default > instrumentation that we have right now). I'd believe Ulrich Drepper's > experience that making this variadic is better than restricting this to > 64b (minus 10 bits or so already in use). > > BTW, would regparm(2) optimize on any arch/platform besides 32b x86? > What about x32? No, regparm is effective only on x86_32. x32 strictly follows x86_64 ABI. > Note that if we remove the regparm, we should also remove it on the > other functions associated with txn begin (GTM_beginTransaction etc.). No, this is not needed. The patch adds the move that loads %eax with the first parameter from function arguments and pass it via regparm ABI to GTM_beginTransaction. OTOH, in GTM_beginTransaction we can still access other variable arguments through the pointer to CFA. Uros.
[Patch, Fortran] PR 51899 - Fix building libgfortran's chmod.c with MinGW
This patch fixes three issues with building libgfortran for MinGW/MinGW64:
a) mode_t is unsigned short while scanf's %o expects an unsigned int
variable.
b) umask is not available
c) Only read and write is available but not group/other
read/write/execute, SUID/SGID or the sticky bit.
Thanks to Kai for some advice - he also stated that the patch looks okay.
Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64
OK for the trunk?
Tobias
2012-01-19 Tobias Burnus
PR libgfortran/51899
* configure.ac: Check whether umask is available.
* intrinsics/chmod.c (chmod_func): Make compile with MinGW.
* configure: Regenerate.
* config.h.in: Regenerate.
diff --git a/libgfortran/config.h.in b/libgfortran/config.h.in
index 3bba6e6..3739309 100644
--- a/libgfortran/config.h.in
+++ b/libgfortran/config.h.in
@@ -783,6 +783,9 @@
/* Define to 1 if the system has the type `uintptr_t'. */
#undef HAVE_UINTPTR_T
+/* Define to 1 if you have the `umask' function. */
+#undef HAVE_UMASK
+
/* Define to 1 if you have the header file. */
#undef HAVE_UNISTD_H
diff --git a/libgfortran/configure b/libgfortran/configure
index 3cf9ac8..0498238 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -2591,6 +2591,7 @@ as_fn_append ac_func_list " getpid"
as_fn_append ac_func_list " getppid"
as_fn_append ac_func_list " getuid"
as_fn_append ac_func_list " geteuid"
+as_fn_append ac_func_list " umask"
# Check that the precious variables saved in the cache have kept the same
# value.
ac_cache_corrupted=false
@@ -12317,7 +12318,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12320 "configure"
+#line 12321 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -12423,7 +12424,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12426 "configure"
+#line 12427 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -16532,6 +16533,8 @@ done
+
+
# Check for C99 (and other IEEE) math functions
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for acosf in -lm" >&5
$as_echo_n "checking for acosf in -lm... " >&6; }
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index e8bbda5..af987bd 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -266,7 +266,7 @@ ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
alarm access fork execl wait setmode execve pipe dup2 close \
strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
getcwd localtime_r gmtime_r strerror_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid)
+readlink getgid getpid getppid getuid geteuid umask)
# Check for C99 (and other IEEE) math functions
AC_CHECK_LIB([m],[acosf],[AC_DEFINE([HAVE_ACOSF],[1],[libm includes acosf])])
diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
index 6c685f4..01db8be 100644
--- a/libgfortran/intrinsics/chmod.c
+++ b/libgfortran/intrinsics/chmod.c
@@ -37,6 +37,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Sets the file permission "chmod" using a mode string.
+ For MinGW, only _S_IWRITE and _S_IREAD are supported. To set those,
+ only the user attributes are used.
+
The mode string allows for the same arguments as POSIX's chmod utility.
a) string containing an octal number.
b) Comma separated list of clauses of the form:
@@ -89,8 +92,15 @@ chmod_func (char *name, char *mode, gfc_charlen_type name_len,
if (mode[0] >= '0' && mode[0] <= '9')
{
+#ifdef __MINGW32__
+ unsigned mode;
+ if (sscanf (mode, "%o", &mode) != 1)
+ return 1;
+ file_mode = (mode_t) mode;
+#else
if (sscanf (mode, "%o", &file_mode) != 1)
return 1;
+#endif
return chmod (file, file_mode);
}
@@ -101,10 +111,14 @@ chmod_func (char *name, char *mode, gfc_charlen_type name_len,
file_mode = stat_buf.st_mode & ~S_IFMT;
is_dir = stat_buf.st_mode & S_IFDIR;
+#ifdef HAVE_UMASK
/* Obtain the umask without distroying the setting. */
mode_mask = 0;
mode_mask = umask (mode_mask);
(void) umask (mode_mask);
+#else
+ honor_umask = false;
+#endif
for (i = 0; i < mode_len; i++)
{
@@ -113,7 +127,9 @@ chmod_func (char *name, char *mode, gfc_charlen_type name_len,
ugo[0] = false;
ugo[1] = false;
ugo[2] = false;
+#ifdef HAVE_UMASK
honor_umask = true;
+#endif
}
continue_clause = false;
rwxXstugo[0] = false;
@@ -140,7 +156,9 @@ chmod_func (char *name, char *mode, gfc_charlen_type name_len,
ugo[1] = true;
ugo[2] = true;
part = 1;
+#ifdef HAVE_UMASK
honor_umask = false;
+#endif
break;
case 'u':
if (part == 2)
@@ -153,7 +171,9 @@ chmod_func (char *name, char *mode, gfc_charlen_type name_len,
return 1;
ugo[0] = true;
[PATCH, RTL] Fix PR 51106
Hello,
As discussed with Jakub in the PR, the problem is that a jump asm goto insn
is removed without purging the dead edges. Bootstrapped and tested on
x86-64. I had to use dg-prune-output to remove the error message and to
make the test pass, as we only checking for an ICE.
OK for trunk/4.6/4.5?
Andrey
gcc/
2012-01-19 Andrey Belevantsev
PR target/51106
* function.c (instantiate_virtual_regs_in_insn): Use delete_insn_and_edges
when removing a wrong asm insn.
testsuite/
2012-01-19 Jakub Jelinek
PR target/51106
* gcc.c-torture/compile/pr51106.c: New test.
diff --git a/gcc/function.c b/gcc/function.c
index fcb79f5..94e51f4 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -1737,7 +1737,7 @@ instantiate_virtual_regs_in_insn (rtx insn)
if (!check_asm_operands (PATTERN (insn)))
{
error_for_asm (insn, "impossible constraint in %");
- delete_insn (insn);
+ delete_insn_and_edges (insn);
}
}
else
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr51106.c b/gcc/testsuite/gcc.c-torture/compile/pr51106.c
new file mode 100644
index 000..2f1c51d
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr51106.c
@@ -0,0 +1,19 @@
+/* { dg-options "-w" } */
+/* { dg-prune-output "impossible constraint" } */
+int
+foo (int x)
+{
+ asm goto ("" : : "i" (x) : : lab);
+ return 1;
+lab:
+ return 0;
+}
+
+int
+bar (int x)
+{
+ asm goto ("" : : "i" (x) : : lab);
+ __builtin_unreachable ();
+lab:
+ return 0;
+}
Re: [PATCH, RTL] Fix PR 51106
On Thu, Jan 19, 2012 at 06:13:58PM +0400, Andrey Belevantsev wrote:
> 2012-01-19 Andrey Belevantsev
>
> PR target/51106
> * function.c (instantiate_virtual_regs_in_insn): Use
> delete_insn_and_edges when removing a wrong asm insn.
This is ok for trunk.
> 2012-01-19 Jakub Jelinek
>
> PR target/51106
> * gcc.c-torture/compile/pr51106.c: New test.
I'd prefer to explicitly test for the warnings and errors.
So something like:
--- gcc/testsuite/gcc.dg/torture/pr51106-1.c.jj 2012-01-19 15:23:28.501117223
+0100
+++ gcc/testsuite/gcc.dg/torture/pr51106-1.c2012-01-19 15:37:20.658296791
+0100
@@ -0,0 +1,14 @@
+/* PR target/51106 */
+/* { dg-do "compile" } */
+/* { dg-skip-if "RTL error" { "*-*-*" } { "-fno-fat-lto-objects" } { "" } } */
+
+int
+foo (int x)
+{
+ asm goto ("" : : "i" (x) : : lab); /* { dg-error "impossible constraint" } */
+ return 1;
+lab:
+ return 0;
+}
+
+/* { dg-warning "probably doesn.t match constraints" "" { target *-*-* } 8 } */
--- gcc/testsuite/gcc.dg/torture/pr51106-2.c.jj 2012-01-19 15:23:28.0
+0100
+++ gcc/testsuite/gcc.dg/torture/pr51106-2.c2012-01-19 15:37:30.062243322
+0100
@@ -0,0 +1,14 @@
+/* PR target/51106 */
+/* { dg-do "compile" } */
+/* { dg-skip-if "RTL error" { "*-*-*" } { "-fno-fat-lto-objects" } { "" } } */
+
+int
+bar (int x)
+{
+ asm goto ("" : : "i" (x) : : lab); /* { dg-error "impossible constraint" } */
+ __builtin_unreachable ();
+lab:
+ return 0;
+}
+
+/* { dg-warning "probably doesn.t match constraints" "" { target *-*-* } 8 } */
Jakub
Re: [PATCH ARM] Fix PR51835, ARM EABI violation
On 19/01/12 06:46, Bin Cheng wrote: > Hi, > Currently gcc generates code violating ARM EABI when passing arguments to > some floating point > helper functions, which are __aeabi_d2iz/__aeabi_d2uiz. As reported in bug > PR51835. > > This patch fixes the issue, with test cases. > > It is for trunk and 4.6 branch, and I have checked the output codes > manually. > Is it OK? > > Thanks > > gcc/ChangeLog: > 2012-01-17 Bin Cheng > > PR target/51835 > * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI > for > __aeabi_d2iz/__aeabi_d2uiz in hard-float abi if only > single-precision > arithmetic is supported in hardware. > > gcc/testsuite/ChangeLog: > 2012-01-17 Bin Cheng > > PR target/51835 > * testsuite/gcc.target/arm/pr51835.c: New testcase. > > OK both. R.
C++ PATCH for c++/51889 (problem overloading function using in template)
When we have a class-scope using-declaration that nominates functions,
we want to insert those functions into the derived class'
CLASSTYPE_METHOD_VEC. In non-template code we do this in
handle_using_decl, which is called from check_bases_and_members. But we
don't call that function for a class template definition. Previously,
for templates we were inserting them from finish_member_declaration, but
that leads to name collisions if a function with the same signature is
declared after the using-declaration, as in this testcase. So this
patch delays inserting the used function until finish_struct time, to
match the non-template case.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 542a826b421991226a5083f769fd1054339b4ff6
Author: Jason Merrill
Date: Thu Jan 19 00:53:45 2012 -0500
PR c++/51889
* class.c (finish_struct): Call add_method here for function usings.
* semantics.c (finish_member_declaration): Not here.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 9b957fe..e6f33fe 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6195,6 +6195,18 @@ finish_struct (tree t, tree attributes)
if (DECL_PURE_VIRTUAL_P (x))
VEC_safe_push (tree, gc, CLASSTYPE_PURE_VIRTUALS (t), x);
complete_vars (t);
+ /* We need to add the target functions to the CLASSTYPE_METHOD_VEC if
+ an enclosing scope is a template class, so that this function be
+ found by lookup_fnfields_1 when the using declaration is not
+ instantiated yet. */
+ for (x = TYPE_FIELDS (t); x; x = DECL_CHAIN (x))
+ if (TREE_CODE (x) == USING_DECL)
+ {
+ tree fn = strip_using_decl (x);
+ if (is_overloaded_fn (fn))
+ for (; fn; fn = OVL_NEXT (fn))
+ add_method (t, OVL_CURRENT (fn), x);
+ }
/* Remember current #pragma pack value. */
TYPE_PRECISION (t) = maximum_field_alignment;
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 40676b6..a5a10d0 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2671,20 +2671,6 @@ finish_member_declaration (tree decl)
{
if (TREE_CODE (decl) == USING_DECL)
{
- /* We need to add the target functions to the
- CLASSTYPE_METHOD_VEC if an enclosing scope is a template
- class, so that this function be found by lookup_fnfields_1
- when the using declaration is not instantiated yet. */
-
- tree target_decl = strip_using_decl (decl);
- if (dependent_type_p (current_class_type)
- && is_overloaded_fn (target_decl))
- {
- tree t = target_decl;
- for (; t; t = OVL_NEXT (t))
- add_method (current_class_type, OVL_CURRENT (t), decl);
- }
-
/* For now, ignore class-scope USING_DECLS, so that
debugging backends do not see them. */
DECL_IGNORED_P (decl) = 1;
diff --git a/gcc/testsuite/g++.dg/inherit/using7.C b/gcc/testsuite/g++.dg/inherit/using7.C
new file mode 100644
index 000..de177c9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inherit/using7.C
@@ -0,0 +1,12 @@
+// PR c++/51889
+
+struct A {
+ void f();
+};
+
+template
+struct B: A
+{
+ using A::f;
+ void f();
+};
Re: Fix regression on PR46590 (slow compile with -O0)
Hi,
On Mon, 16 Jan 2012, Richard Guenther wrote:
> > Regstrapping in progress on x86_64-linux, okay for trunk?
>
> Ok.
I've committed (r183305) a slightly changed variant that merges the two
outer bitmap loops again, like so:
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i, bi)
{
unsigned j;
bitmap_iterator bj;
- EXECUTE_IF_SET_IN_BITMAP (work, i + 1, j, bj)
+ /* First the conflicts between new and old_conflicts. */
+ EXECUTE_IF_SET_IN_BITMAP (old_conflicts, 0, j, bj)
+ add_stack_var_conflict (i, j);
+ /* Then the conflicts between only the new members. */
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, i + 1,
+ j, bj)
add_stack_var_conflict (i, j);
}
Ciao,
Michael.
Re: [PATCH] PR debug/45682 - wrong struct DIE nesting with -fdebug-types-section
On 01/17/2012 06:52 PM, Cary Coutant wrote: Would you consider it OK with a comment? Yes. How about if I call copy_declaration_context directly from remove_child_or_replace_with_skeleton, instead of calling them sequentially in break_out_comdat_types? OK. Jason
[Patch,docs,AVR,M32C, RL78, SPU]: Describe AVR address spaces and more AVR options
This is basically documentation of AVR specific extensions and stuff like * command line options like -maccumulate-args etc. * AVR named address spaces Section doc/extend.texi::Named Address Spaces is split into several subsections now; each subsection taking care of one target in alphabetical order: AVR, M32C, RL78, SPU. As I already wrote in http://gcc.gnu.org/ml/gcc/2012-01/msg00175.html references in the documentation miss their intended anchors/targets. That is a general problem and not specific to the new references introduced by this patch. Ok to commit? Johann * doc/extend.texi (Named Address Spaces): Split into subsections. (AVR Named Address Spaces): New subsection. (M32C Named Address Spaces): New subsection. (RL78 Named Address Spaces): New subsection. (SPU Named Address Spaces): New subsection. (Variable Attributes): New anchor "AVR Variable Attributes". (AVR Variable Attributes): Rewrite and avoid wording "address space" in this context. * doc/invoke.texi (AVR Options): Rewrite and add documentation for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls. (AVR Built-in Macros): New subsubsection therein. * doc/md.texi (AVR constraints): Remove "C04", "R".
Re: [Patch,docs,AVR,M32C, RL78, SPU]: Describe AVR address spaces and more AVR options
Georg-Johann Lay wrote:
> This is basically documentation of AVR specific extensions and stuff like
>
> * command line options like -maccumulate-args etc.
> * AVR named address spaces
>
> Section doc/extend.texi::Named Address Spaces is split into several
> subsections
> now; each subsection taking care of one target in alphabetical order:
> AVR, M32C, RL78, SPU.
>
> As I already wrote in http://gcc.gnu.org/ml/gcc/2012-01/msg00175.html
> references in the documentation miss their intended anchors/targets. That is a
> general problem and not specific to the new references introduced by this
> patch.
>
> Ok to commit?
>
> Johann
>
> * doc/extend.texi (Named Address Spaces): Split into subsections.
> (AVR Named Address Spaces): New subsection.
> (M32C Named Address Spaces): New subsection.
> (RL78 Named Address Spaces): New subsection.
> (SPU Named Address Spaces): New subsection.
> (Variable Attributes): New anchor "AVR Variable Attributes".
> (AVR Variable Attributes): Rewrite and avoid wording
> "address space" in this context.
> * doc/invoke.texi (AVR Options): Rewrite and add documentation
> for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls.
> (AVR Built-in Macros): New subsubsection therein.
> * doc/md.texi (AVR constraints): Remove "C04", "R".
...and for the curious, here is the patch.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 183305)
+++ doc/extend.texi (working copy)
@@ -1215,15 +1215,192 @@ Pragmas to control overflow and rounding
Fixed-point types are supported by the DWARF2 debug information format.
@node Named Address Spaces
-@section Named address spaces
-@cindex named address spaces
+@section Named Address Spaces
+@cindex Named Address Spaces
As an extension, the GNU C compiler supports named address spaces as
defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
address spaces in GCC will evolve as the draft technical report
changes. Calling conventions for any target might also change. At
-present, only the SPU, M32C, and RL78 targets support other address
-spaces. On the SPU target, for example, variables may be declared as
+present, only the AVR, SPU, M32C, and RL78 targets support address
+spaces other than the generic address space.
+
+Address space identifiers may be used exactly like any other C type
+qualifier (e.g., @code{const} or @code{volatile}). See the N1275
+document for more details.
+
+@anchor{AVR Named Address Spaces}
+@subsection AVR Named Address Spaces
+
+On the AVR target, there are several address spaces that can be used
+in order to put read-only data into the flash memory and access that
+data by means of the special instructions @code{LPM} or @code{ELPM}
+needed to read from flash.
+
+Per default, any data including read-only data is located in RAM so
+that address spaces are needed to locate the data in flash memory
+@emph{and} to generate the right instructions to access the data
+without using (inline) assembler code.
+
+@table @code
+@item __pgm
+@cindex @code{__pgm} AVR Named Address Spaces
+The @code{__pgm} qualifier will locate data in the
+@code{.progmem.data} section. Data will be read using the @code{LPM}
+instruction. Pointers to this address space are 16 bits wide.
+
+@item __pgm1
+@item __pgm2
+@item __pgm3
+@item __pgm4
+@item __pgm5
+@cindex @code{__pgm1} AVR Named Address Spaces
+@cindex @code{__pgm2} AVR Named Address Spaces
+@cindex @code{__pgm3} AVR Named Address Spaces
+@cindex @code{__pgm4} AVR Named Address Spaces
+@cindex @code{__pgm5} AVR Named Address Spaces
+These are 16-bit address spaces locating data in section
+@code{.progmem@var{N}.data} where @var{N} refers to
+address space @code{__pgm@var{N}}.
+The compiler will set the @code{RAMPZ} segment register approptiately
+before reading data by means of the @code{ELPM} instruction.
+On devices with less 64kiB flash segments as indicated by the address
+space, the compiler will cut down the segment number to a number the
+device actually supports (where counting starts at @code{0}
+for space @code{__pgm}). For example, if you access address space
+@code{__pgm3} on an ATmega128 device with two 64kiB flash segments,
+the compiler will generate a read from space @code{__pgm1}, i.e.@: it
+will load @code{RAMPZ} with @code{1} before reading.
+@item __pgmx
+@cindex @code{__pgmx} AVR Named Address Spaces
+This is a 24-bit address space that linearizes flash and RAM:
+If the high bit of the address is set, data is read from
+RAM using the lower two bytes as RAM address.
+If the high bit of the address is clear, data is read from flash
+with @code{RAMPZ} set according to the high byte of the address.
+Objects in this address space will be located in @code{.progmem.data}.
+@end table
+
+For each named address space supported by avr-gcc there is an equally
+named but uppercase built-in macro defined.
+T
Re: [PATCH] Fix PR51782(?)
Richard Guenther wrote:
> This should fix PR51782 - we need to look at the base address operand
> of MEM_REF and TARGET_MEM_REF to get at the address-space information
> as both can have an embedded VIEW_CONVERT_EXPR. This is then
> consistent with the gimple type system which keeps address-space
> changing conversions of pointers in the IL.
>
> Note that set_mem_attributes_minus_bitpos also looks broken in this
> regard as it requires that even explicit VIEW_CONVERT_EXPRs have
> the address-space encoded (or COMPONENT_REFs, too). I'm not
> sure that you get a proper TYPE_ADDR_SPACE from even s.i for
> struct S { int i; } s; but somebody with a target available
> could check that.
>
> Pointless bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2012-01-17 Richard Guenther
>
> PR middle-end/51782
> * expr.c (expand_assignment): Take address-space information
> from the address operand of MEM_REF and TARGET_MEM_REF.
> (expand_expr_real_1): Likewise.
Unfortunately, this does not fix the problem:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782#c13
Johann
> Index: gcc/expr.c
> ===
> *** gcc/expr.c(revision 183205)
> --- gcc/expr.c(working copy)
> *** expand_assignment (tree to, tree from, b
> *** 4590,4596
> if (TREE_CODE (to) == MEM_REF)
> {
> addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 1;
> tree base = TREE_OPERAND (to, 0);
> address_mode = targetm.addr_space.address_mode (as);
> op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL);
> --- 4590,4596
> if (TREE_CODE (to) == MEM_REF)
> {
> addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
> tree base = TREE_OPERAND (to, 0);
> address_mode = targetm.addr_space.address_mode (as);
> op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL);
> *** expand_assignment (tree to, tree from, b
> *** 4608,4614
> }
> else if (TREE_CODE (to) == TARGET_MEM_REF)
> {
> ! addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (to));
> struct mem_address addr;
>
> get_address_description (to, &addr);
> --- 4608,4615
> }
> else if (TREE_CODE (to) == TARGET_MEM_REF)
> {
> ! addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
> struct mem_address addr;
>
> get_address_description (to, &addr);
> *** expand_expr_real_1 (tree exp, rtx target
> *** 9253,9259
>
> case TARGET_MEM_REF:
> {
> ! addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (exp));
> struct mem_address addr;
> enum insn_code icode;
> unsigned int align;
> --- 9254,9261
>
> case TARGET_MEM_REF:
> {
> ! addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0;
> struct mem_address addr;
> enum insn_code icode;
> unsigned int align;
> *** expand_expr_real_1 (tree exp, rtx target
> *** 9288,9294
> case MEM_REF:
> {
> addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 1;
> enum machine_mode address_mode;
> tree base = TREE_OPERAND (exp, 0);
> gimple def_stmt;
> --- 9290,9296
> case MEM_REF:
> {
> addr_space_t as
> ! = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0;
> enum machine_mode address_mode;
> tree base = TREE_OPERAND (exp, 0);
> gimple def_stmt;
>
[PATCH] Don't consider clones of user functions as uninstrumentable by mudflap (PR libmudflap/40778)
Hi!
It isn't clear why mudflap doesn't instrument DECL_ARTIFICIAL functions,
if it couldn't avoid instrumenting just a subset of them.
But there is certainly no reason why it shouldn't instrument normal clones
of user functions (OpenMP, TM, ISRA, ...). Fixed thusly,
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-01-19 Jakub Jelinek
PR libmudflap/40778
* tree-mudflap.c (mf_artificial): New function.
(execute_mudflap_function_ops, execute_mudflap_function_decls,
mx_register_decls, mudflap_enqueue_decl): Use it.
* testsuite/libmudflap.c/fail68-frag.c: New test.
--- gcc/tree-mudflap.c 2011-12-08 16:36:52.233959103 +0100
+++ gcc/tree-mudflap.c 2012-01-19 11:18:45.817151412 +0100
@@ -69,6 +69,13 @@ static tree mx_xfn_xform_decls (gimple_s
static gimple_seq mx_register_decls (tree, gimple_seq, location_t);
static unsigned int execute_mudflap_function_decls (void);
+/* Return true if DECL is artificial stub that shouldn't be instrumented by
+ mf. We should instrument clones of non-artificial functions. */
+static inline bool
+mf_artificial (const_tree decl)
+{
+ return DECL_ARTIFICIAL (DECL_ORIGIN (decl));
+}
/* */
/* Some generally helpful functions for mudflap instrumentation. */
@@ -412,8 +419,8 @@ execute_mudflap_function_ops (void)
/* Don't instrument functions such as the synthetic constructor
built during mudflap_finish_file. */
- if (mf_marked_p (current_function_decl) ||
- DECL_ARTIFICIAL (current_function_decl))
+ if (mf_marked_p (current_function_decl)
+ || mf_artificial (current_function_decl))
return 0;
push_gimplify_context (&gctx);
@@ -994,8 +1001,8 @@ execute_mudflap_function_decls (void)
/* Don't instrument functions such as the synthetic constructor
built during mudflap_finish_file. */
- if (mf_marked_p (current_function_decl) ||
- DECL_ARTIFICIAL (current_function_decl))
+ if (mf_marked_p (current_function_decl)
+ || mf_artificial (current_function_decl))
return 0;
push_gimplify_context (&gctx);
@@ -1078,7 +1085,7 @@ mx_register_decls (tree decl, gimple_seq
/* Add the __mf_register call at the current appending point. */
if (gsi_end_p (initially_stmts))
{
- if (!DECL_ARTIFICIAL (decl))
+ if (!mf_artificial (decl))
warning (OPT_Wmudflap,
"mudflap cannot track %qE in stub function",
DECL_NAME (decl));
@@ -1249,7 +1256,7 @@ mudflap_enqueue_decl (tree obj)
during mudflap_finish_file (). That would confuse the user,
since the text would refer to variables that don't show up in the
user's source code. */
- if (DECL_P (obj) && DECL_EXTERNAL (obj) && DECL_ARTIFICIAL (obj))
+ if (DECL_P (obj) && DECL_EXTERNAL (obj) && mf_artificial (obj))
return;
VEC_safe_push (tree, gc, deferred_static_decls, obj);
--- libmudflap/testsuite/libmudflap.c/fail68-frag.c.jj 2010-12-16
17:15:40.0 +0100
+++ libmudflap/testsuite/libmudflap.c/fail68-frag.c 2010-12-16
17:26:16.0 +0100
@@ -0,0 +1,27 @@
+/* PR libmudflap/40778 */
+
+char p[32];
+static int j;
+
+__attribute__((noinline))
+static void foo (int i)
+{
+ if (j++ == 0)
+p[i + 4] = 12;
+ else
+p[i - 4] = 13;
+}
+
+int
+main ()
+{
+ foo (30);
+ foo (30);
+ foo (30);
+ return 0;
+}
+
+/* { dg-output "mudflap violation 1.*" } */
+/* { dg-output "Nearby object 1.*" } */
+/* { dg-output "mudflap object.*name.*p" } */
+/* { dg-do run { xfail *-*-* } } */
Jakub
[PATCH] PR51856: Fix find_reloads_subreg_address bug
Hi,
the attached patch fixes a problem which has been introduced with:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01527.html
Bootstrapped and regtested on x86_64, s390, and s390x.
Ok for mainline?
Bye,
-Andreas-
2012-01-19 Andreas Krebbel
PR rtl-optimization/51856
* reload.c (find_reloads_subreg_address): Set the address_reloaded
flag to reloaded.
2012-01-19 Andreas Krebbel
* gcc.c-torture/compile/pr51856.c: New testcase.
---
gcc/reload.c |2 !!
gcc/testsuite/gcc.c-torture/compile/pr51856.c | 23 +++
2 files changed, 23 insertions(+), 2 modifications(!)
Index: gcc/reload.c
===
*** gcc/reload.c.orig
--- gcc/reload.c
*** find_reloads_subreg_address (rtx x, int
*** 6232,6238
}
}
if (reloaded && address_reloaded)
! *address_reloaded = 1;
return x;
}
--- 6232,6238
}
}
if (reloaded && address_reloaded)
! *address_reloaded = reloaded;
return x;
}
Index: gcc/testsuite/gcc.c-torture/compile/pr51856.c
===
*** /dev/null
--- gcc/testsuite/gcc.c-torture/compile/pr51856.c
***
*** 0
--- 1,23
+ struct B { int b1; long long b2, b3; int b4; };
+ struct C { char c1[40], c2, c3[96]; long long c4[5], c5; char c6[596]; };
+ void fn1 (long long), fn2 (char *, int), fn4 (void);
+ int r, fn3 (int, const char *, int, char *, int, int);
+
+ void
+ foo (int t, int u, int v, int w, int x, int y, struct B *z)
+ {
+ char c[512], d[512], e;
+ struct C g;
+ long long f, h[255];
+ struct B j;
+ __builtin_bzero (&j, sizeof j);
+ if (y > w)
+ fn4 ();
+ __builtin_bzero (&g, sizeof g);
+ g.c5 = h[0];
+ fn1 (z ? z->b3 : f);
+ g.c2 = y;
+ fn2 (d, 256);
+ if (fn3 (r, "", e, c, 0, 16))
+ fn4 ();
+ }
Re: [Patch, Fortran] PR 51899 - Fix building libgfortran's chmod.c with MinGW
Tobias Burnus wrote: Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64 OK for the trunk? MinGW64 was successful - thanks to Brad for testing it and for updating the version, which is linked from the wiki. Tobias
Re: [PATCH] Don't consider clones of user functions as uninstrumentable by mudflap (PR libmudflap/40778)
On Thu, Jan 19, 2012 at 06:10:06PM +0100, Jakub Jelinek wrote: > 2012-01-19 Jakub Jelinek > > PR libmudflap/40778 > * tree-mudflap.c (mf_artificial): New function. > (execute_mudflap_function_ops, execute_mudflap_function_decls, > mx_register_decls, mudflap_enqueue_decl): Use it. > > * testsuite/libmudflap.c/fail68-frag.c: New test. Frank acked this on IRC, committed to trunk. Jakub
[Patch, Fortran] PR 51904 - with ICE with SIZE intrinsic
Seemingly, resolve and friends are confused if there is no symtree -
thus set it.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch? (It's a regression.)
Tobias
2012-01-19 Tobias Burnus
PR fortran/51904
*expr.c (gfc_build_intrinsic_call): Also set the symtree.
2012-01-19 Tobias Burnus
PR fortran/51904
* gfortran.dg/intrinsic_size_2.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 8f04c73..7cea780 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4519,6 +4519,11 @@ gfc_build_intrinsic_call (const char* name, locus where, unsigned numarg, ...)
result->value.function.name = name;
result->value.function.isym = isym;
+ result->symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
+ gcc_assert (result->symtree
+ && (result->symtree->n.sym->attr.flavor == FL_PROCEDURE
+ || result->symtree->n.sym->attr.flavor == FL_UNKNOWN));
+
va_start (ap, numarg);
atail = NULL;
for (i = 0; i < numarg; ++i)
--- /dev/null 2012-01-19 08:39:17.883655782 +0100
+++ gcc/gcc/testsuite/gfortran.dg/intrinsic_size_2.f90 2012-01-19 20:14:12.0 +0100
@@ -0,0 +1,17 @@
+! { dg-do compile }
+!
+! PR fortran/51904
+!
+! Contributed by David Sagan.
+!
+
+call qp_draw_polyline_basic([1.0,2.0])
+contains
+subroutine qp_draw_polyline_basic (x)
+ implicit none
+ real :: x(:), f
+ integer :: i
+ f = 0
+ print *, size(f*x)
+end subroutine
+end
Re: *ping* - libiberty: Fix "make pdf" for copying-lib.texi
I have no problems running "make pdf" in libiberty. texi2dvi (GNU Texinfo 4.13) 1.135
Re: [Patch, Fortran] PR 51904 - with ICE with SIZE intrinsic
On Thu, Jan 19, 2012 at 08:23:58PM +0100, Tobias Burnus wrote: > Seemingly, resolve and friends are confused if there is no symtree - > thus set it. > > Build and regtested on x86-64-linux. > OK for the trunk and the 4.6 branch? (It's a regression.) > Yes. Almost looks obvious (except I've read the audit trail in the PR). -- Steve
Re: *ping* - libiberty: Fix "make pdf" for copying-lib.texi
DJ Delorie wrote:
I have no problems running "make pdf" in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
That's odd. I have exactly the same version and I get the following TeX
error.
Tobias
texi2pdf /home/tob/projects/gcc-git/gcc/libiberty/libiberty.texi
This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
restricted \write18 enabled.
entering extended mode
(/home/tob/projects/gcc-git/gcc/libiberty/libiberty.texi
(/usr/share/texmf/tex/texinfo/texinfo.tex
Loading texinfo [version 2011-05-23.16]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/share/texmf/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.)
[1{/var/lib/t
exmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1 Chapter 2 [1]
[2] (/home/tob/projects/gcc-git/gcc/libiberty/obstacks.texi Chapter 3 [3]
[4] Cross reference values unknown; you must run TeX again. [5] [6] [7]
[8] [9] [10] [11] [12] [13]) Chapter 4 [14]
(/home/tob/projects/gcc-git/gcc/libiberty/functions.texi [15] [16] [17]
[18] [19] [20] [21]
Underfull \hbox (badness 1) in paragraph at lines 677--681
[]@textrm For ex-am-ple, if @textsl bin[]prefix @textrm is @texttt
/alpha/beta
/gamma/gcc/delta[]@textrm , @textsl pre-fix @textrm is
[22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35])
Appendix A [36] (/home/tob/projects/gcc-git/gcc/libiberty/copying-lib.texi
[37] [38] [39] [40] [41] [42]
/home/tob/projects/gcc-git/gcc/libiberty/copying-lib.texi:480: This
command can
appear only outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
@fi
@sectionheading #1#2#3#4->{@checkenv {}
@csname #2fonts@endcsname
@rmisbold @...
@\heading ...tionheading {#1}{sec}{Yomitfromtoc}{}
@suppressfirstparagraphin...
l.480 @heading NO WARRANTY
?
Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling
On 01/19/2012 03:36 AM, Kai Tietz wrote: Well, I will try to search for it a bit more. Nevertheless is the chaining at this place IMHO a pretty bad idea. The merging of attributes looks more sane. Also is this merging patch pretty less invasive and would be fine for older branches, too. That's true, let's go ahead and put in your merging patch for now, we can fix it better in 4.8. Jason
patch for PR40761.
The following patch solves PR40761 which is described on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761. The patch was bootstrapped on x86/x86-64 with -O2 and -O0 with checking enabled. Committed as rev. 183312. 2012-01-19 Vladimir Makarov PR rtl-optimization/40761 * ira-int.h (struct ira_loop_tree_node): Add comment for member loop. Add new member loop_num. (IRA_LOOP_NODE_BY_INDEX): Modify the check. (ira_build): Remove the parameter. * ira.c (ira_print_disposition): Use loop_num instead of loop->num. (ira.c): Do not build CFG loops for one region allocation. Remove argument from ira_build call. * ira-build.c (init_loop_tree_node): New function. (create_loop_tree_nodes): Use it. Separate the case when CFG loops are not built. (more_one_region_p): Check current_loops. (finish_loop_tree_nodes): Separate the case when CFG loops are not built. (add_loop_to_tree): Process loop equal to NULL too. (form_loop_tree): Separate the case when CFG loops are not built. Use explicitly number for the root. (rebuild_regno_allocno_maps, create_loop_tree_node_allocnos): Add an assertion. (ira_print_expanded_allocno, loop_compare_func): Use loop_num instead of loop->num. (mark_loops_for_removal): Ditto. Use loop_num instead of loop->num. (mark_all_loops_for_removal): Ditto. (remove_unnecessary_regions): Separate the case when CFG loops are not built. (ira_build): Remove the parameter. Use explicit number of regions when CFG loops are not built. * ira-color.c (print_loop_title): Separate the case for the root node. Use loop_num instead of loop->num. (move_spill_restore): Use loop_num instead of loop->num. * ira-emit.c (setup_entered_from_non_parent_p): Add an assertion. (change_loop): Ditto. (change_loop): Use loop_num instead of loop->num. * ira-lives.c (process_bb_node_lives): Ditto. * ira-costs.c (print_allocno_costs, find_costs_and_classes): Ditto. * ira-conflicts.c (print_allocno_conflicts): Ditto.
Re: FW: patch to fix PR21617
On 01/18/2012 02:30 PM, Zamyatin, Igor wrote: Yes, we use Atom for EEMBC measurements. We'll be glad to help you with your findings. Thanks. Unfortunately I tried several alternative patches but I did not find a better solution (it is mostly code size degradation on CoreI7). Now I am even thinking that the best action would have been ignoring the original PR.
[pph] Fix checksum of trees coming from external PPH images (issue5554070)
When we read a tree from the cache of an external PPH file and the
tree is mutated in the current file, we need to re-sign the tree to
reflect the changes.
The problem was, that the signing code was assuming that the tree had
come from the *current* file, so it was trying to sign a cache entry
for the internal cache, which would ICE if the internal cache is
smaller than the external one.
I have not yet been able to produce a small test case for this, but it
fixes several thousand ICEs in our internal code. I will add a test
case as soon as I get one reduced.
* pph-in.c (pph_in_tree): Sign EXPR from the cache it was
taken from.
* pph-streamer.h (pph_cache_select): Handle PPH_RECORD_START,
PPH_RECORD_START_MERGE_BODY, PPH_RECORD_START_MERGE_KEY
and PPH_RECORD_START_MUTATED.
diff --git a/gcc/cp/pph-in.c b/gcc/cp/pph-in.c
index 2dbad83..0b2529f 100644
--- a/gcc/cp/pph-in.c
+++ b/gcc/cp/pph-in.c
@@ -2565,8 +2565,7 @@ pph_in_tree (pph_stream *stream)
/* When reading a mutated tree, we only need to re-read its
body, the tree itself is already in the cache for another
PPH image. */
- expr = (tree) pph_cache_find (stream, PPH_RECORD_XREF, image_ix, ix,
- PPH_any_tree);
+ expr = (tree) pph_cache_find (stream, marker, image_ix, ix,
PPH_any_tree);
}
else if (marker == PPH_RECORD_START_MERGE_BODY)
{
@@ -2600,7 +2599,7 @@ pph_in_tree (pph_stream *stream)
pph_trace_tree (expr, pph_trace_back,
marker == PPH_RECORD_START_MERGE_BODY ? pph_trace_merge_body
: marker == PPH_RECORD_START_MUTATED ? pph_trace_mutate
- : pph_trace_normal );
+ : pph_trace_normal);
/* If needed, sign the recently materialized tree to detect
mutations. Note that we only need to compute signatures
@@ -2612,8 +2611,13 @@ pph_in_tree (pph_stream *stream)
{
unsigned crc;
size_t nbytes;
+ pph_cache *cache;
+
+ /* Retrieve the cache to sign based on where we materialized
+EXPR from. */
+ cache = pph_cache_select (stream, marker, image_ix);
crc = pph_get_signature (expr, &nbytes);
- pph_cache_sign (&stream->cache, ix, crc, nbytes);
+ pph_cache_sign (cache, ix, crc, nbytes);
}
return expr;
diff --git a/gcc/cp/pph-streamer.h b/gcc/cp/pph-streamer.h
index b641776..c5db972 100644
--- a/gcc/cp/pph-streamer.h
+++ b/gcc/cp/pph-streamer.h
@@ -293,9 +293,16 @@ void pph_reader_finish (void);
/* Return the pickle cache in STREAM corresponding to MARKER.
- if MARKER is PPH_RECORD_IREF, it returns the cache in STREAM itself.
- If MARKER is PPH_RECORD_XREF, it returns the cache in
- STREAM->INCLUDES[INCLUDE_IX].
+ INCLUDE_IX is only used for MARKER values PPH_RECORD_XREF or
+ PPH_RECORD_START_MUTATED.
+
+ If MARKER is one of {PPH_RECORD_IREF, PPH_RECORD_START,
+ PPH_RECORD_START_MERGE_BODY, PPH_RECORD_START_MERGE_KEY}, it
+ returns the cache in STREAM itself.
+
+ If MARKER is one of {PPH_RECORD_XREF, PPH_RECORD_START_MUTATED}, it
+ returns the cache in STREAM->INCLUDES[INCLUDE_IX].
+
If MARKER is a PREF, it returns the preloaded cache. */
static inline pph_cache *
pph_cache_select (pph_stream *stream, enum pph_record_marker marker,
@@ -304,9 +311,13 @@ pph_cache_select (pph_stream *stream, enum
pph_record_marker marker,
switch (marker)
{
case PPH_RECORD_IREF:
+case PPH_RECORD_START:
+case PPH_RECORD_START_MERGE_BODY:
+case PPH_RECORD_START_MERGE_KEY:
return &stream->cache;
break;
case PPH_RECORD_XREF:
+case PPH_RECORD_START_MUTATED:
return &VEC_index (pph_stream_ptr, stream->includes, include_ix)->cache;
break;
case PPH_RECORD_PREF:
--
This patch is available for review at http://codereview.appspot.com/5554070
Re: Go patch committed: Recognize more test lines
On Wed, Jan 18, 2012 at 3:17 PM, Ian Lance Taylor wrote: >>> This patch to the Go testsuite driver recognizes a few more test lines >>> in Go tests. I somehow failed to notice these the last time I updated >>> the Go testsuite. This patch includes a couple of changes to make the >>> newly recognized tests pass. Ran Go testsuite on >>> x86_64-unknown-linux-gnu. Committed to mainline. >> >> Some of the go tests require explicit -mieee compile flag [1]. Is >> there a way to conditionally pass this flag to the compiler? > > What does Java do? Nothing... while the library is compiled with -mieee (the same as libgo), the user is still expected to pass -mieee as a compile flag for full IEEE compliance. > > For Go, like Java, we should turn on the -mieee option by default. Both > Go and Java specify the floating point model precisely--Go not as > precisely as Java, but it does require denormals to be supported. > Unfortunately I'm not sure how to do that. My best idea at the moment > is to add a new target hook to common/common-target.def meaning "we > actually care about floating point." > > That said, it would be easy enough to handle -mieee to way we handle > -minline-all-stringops in libgo/configure.ac and libgo/Makefile.am. > That would let us use -mieee when building and testing libgo. But it > should really be the default in all cases, not just libgo. While looking at remaining failures, it looks to me that go tests expects full IEEE compliance. I have addressed this via patch that adds -mieee to either DEFAULT_GOCFLAGS in go-test.exp or to additional_flags via alternate driver. This fixes all "floating point error" go.test failures, remaining are: FAIL: go.test/test/chan/select2.go execution, -O2 -g WARNING: program timed out. FAIL: ./select5-out.go compilation, -O2 -g where select2.go claims too much memory: PASS: go.test/test/chan/select2.go compilation, -O2 -g Setting LD_LIBRARY_PATH to .:/space/uros/gcc-build-go/alphaev68-unknown-linux-gnu/./libgo/.libs:/space/uros/gcc-build-go/gcc:.:/space/uros/gcc-build-go/alphaev68-unknown-linux-gnu/./libgo/.libs:/space/uros/gcc-build-go/gcc spawn [open ...]^M BUG: too much memory for 100,000 selects: 2098576 FAIL: go.test/test/chan/select2.go execution, -O2 -g I will propose the patch in a follow-up message. Uros.
Re: Go patch committed: Recognize more test lines
Uros Bizjak writes: >>> Some of the go tests require explicit -mieee compile flag [1]. Is >>> there a way to conditionally pass this flag to the compiler? >> >> What does Java do? > > Nothing... while the library is compiled with -mieee (the same as > libgo), the user is still expected to pass -mieee as a compile flag > for full IEEE compliance. I'm not going to worry too much about Alpha, but this is just wrong. I recognize that Alpha imposes a significant penalty on IEEE-correctness, but nevertheless the Java and Go languages require it. Programmers shouldn't have to use a special option to get correct behaviour as defined by the language. It should be the other way around: they should have to use a special option to indicate that they don't care about correct behaviour. > I will propose the patch in a follow-up message. Thanks. Ian
[PATCH, go] Add -mieee to various go.test tests
Hello!
Attached patch adds -mieee to tests that need full IEEE compliance to
pass. While working on patch, I have noticed that go-test.exp doesn't
pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
format (so, these simply get ignored). With this issue fixed, we can
add -mieee to DEFAULT_GOCFLAGS. Tests, compiled through torture
procedure, expects their special flags in a separate driver file.
Attached patch fixes all "floating point errors" on
alphaev68-pc-linux-gnu through these two methods.
2012-01-19 Uros Bizjak
* go.test/go-test.exp (go-gc-tests): Add -mieee to DEFAULT_GOCFLAGS
for alpha*-*-* and sh*-*-* to enable full IEEE compliance mode.
Pass correctly formatted options to go_target_compile.
* go.test/test/fixedbugs/bug321.x: New file.
* go.test/test/zerodivide.x: Ditto.
* go.test/test/floatcmp.x: Ditto.
Patch was tested on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu.
OK for mainline SVN?
Uros.
Index: test/zerodivide.x
===
--- test/zerodivide.x (revision 0)
+++ test/zerodivide.x (revision 0)
@@ -0,0 +1,6 @@
+if { [istarget "alpha*-*-*"] || [istarget "sh*-*-*"] } {
+# alpha and SH require -mieee for this test.
+set additional_flags "-mieee"
+}
+
+return 0
Index: test/floatcmp.x
===
--- test/floatcmp.x (revision 0)
+++ test/floatcmp.x (revision 0)
@@ -0,0 +1,6 @@
+if { [istarget "alpha*-*-*"] || [istarget "sh*-*-*"] } {
+# alpha and SH require -mieee for this test.
+set additional_flags "-mieee"
+}
+
+return 0
Index: test/fixedbugs/bug321.x
===
--- test/fixedbugs/bug321.x (revision 0)
+++ test/fixedbugs/bug321.x (revision 0)
@@ -0,0 +1,6 @@
+if { [istarget "alpha*-*-*"] || [istarget "sh*-*-*"] } {
+# alpha and SH require -mieee for this test.
+set additional_flags "-mieee"
+}
+
+return 0
Index: go-test.exp
===
--- go-test.exp (revision 183305)
+++ go-test.exp (working copy)
@@ -208,6 +208,15 @@
set DEFAULT_GOCFLAGS " -pedantic-errors"
}
+# Enable full IEEE compliance mode.
+if { [istarget alpha*-*-*]
+ || [istarget sh*-*-*] } then {
+ lappend DEFAULT_GOCFLAGS "-mieee"
+}
+
+set options ""
+lappend options "additional_flags=$DEFAULT_GOCFLAGS"
+
# Set GOARCH for tests that need it.
go-set-goarch
@@ -585,7 +594,7 @@
set dg-do-what-default "link"
set output_file "./[file rootname [file tail $test]].exe"
set comp_output [go_target_compile "$ofile1 $ofile2" \
-$output_file "executable" "$DEFAULT_GOCFLAGS"]
+$output_file "executable" "$options"]
set comp_output [go-dg-prune $target_triplet $comp_output]
verbose -log $comp_output
set result [go_load "$output_file" "" ""]
@@ -610,7 +619,7 @@
set dg-do-what-default "link"
set output_file "./[file rootname [file tail $test]].exe"
set comp_output [go_target_compile "$ofile1 $ofile2 $ofile3" \
-$output_file "executable" "$DEFAULT_GOCFLAGS"]
+$output_file "executable" "$options"]
set comp_output [go-dg-prune $target_triplet $comp_output]
if [string match "" $comp_output] {
pass $name
@@ -633,7 +642,7 @@
set ofile2 "[file rootname [file tail $test]].o"
set output_file "./[file rootname [file tail $test]].exe"
set comp_output [go_target_compile "$ofile1 $ofile2" \
-$output_file "executable" "$DEFAULT_GOCFLAGS"]
+$output_file "executable" "$options"]
set comp_output [go-dg-prune $target_triplet $comp_output]
if [string match "" $comp_output] {
set result [go_load "$output_file" "" ""]
@@ -660,7 +669,7 @@
set dg-do-what-default "link"
set output_file "./[file rootname [file tail $file2]].exe"
set comp_output [go_target_compile "$ofile1 $ofile2" \
-$output_file "executable" "$DEFAULT_GOCFLAGS"]
+$output_file "executable" "$options"]
set comp_output [go-dg-prune $target_triplet $comp_output]
if [string match "" $comp_output] {
set result [go_load "$output_file" "" ""]
@@ -726,7 +735,7 @@
errchk $file3 ""
set output_file "./[file rootname [file tail $test]].exe"
set comp_output [go_target_compile "$ofile0 $ofile1 $ofile2" \
-$output_file "executable" "$DEFAULT_GOCFLAGS"]
+$out
[google-main] Add DW_AT_GNU_pubtypes and DW_AT_GNU_pubnames to comdat type units. (issue5553069)
commit de9e01e3b50f75bcd47da9d32ab0691c65094df5
Author: Sterling Augustine
Date: Thu Jan 19 14:31:14 2012 -0800
Add DW_AT_GNU_pubtypes and Add DW_AT_GNU_pubnames to comdat type dies.
M gcc/dwarf2out.c
Tested:
Via make check-c and make check-c++. No new issues found.
ChangeLog:
2012-01-19 Sterling Augustine
* gcc/dwarf2out.c (break_out_comdat_types): Call add_AT_lineptr with
DW_AT_GNU_pubnames and DW_AT_GNU_pubtypes.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 57f18ad..3e34354 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -7287,6 +7287,15 @@ break_out_comdat_types (dw_die_ref die)
type_node->root_die = unit;
type_node->next = comdat_type_list;
comdat_type_list = type_node;
+if (targetm.want_debug_pub_sections)
+{
+ /* FIXME: Should use add_AT_pubnamesptr. This works because most
+ targets don't care what the base section is. */
+ add_AT_lineptr (unit, DW_AT_GNU_pubnames,
+ debug_pubnames_section_label);
+ add_AT_lineptr (unit, DW_AT_GNU_pubtypes,
+ debug_pubtypes_section_label);
+}
/* Generate the type signature. */
generate_type_signature (c, type_node);
--
This patch is available for review at http://codereview.appspot.com/5553069
Re: [PATCH] PR debug/45682 - wrong struct DIE nesting with -fdebug-types-section
>> Would you consider it OK with a comment?
>
> Yes.
>
>> How about if I call copy_declaration_context directly from
>> remove_child_or_replace_with_skeleton, instead of calling them
>> sequentially in break_out_comdat_types?
>
> OK.
Updated patch attached. I fixed the regex so the test is independent
of whether the strings are emitted with DW_FORM_string or
DW_FORM_strp.
Bootstrapped on x86_64, no regressions.
OK for trunk, or hold for next stage 1?
-cary
2012-01-19 Cary Coutant
Dodji Seketeli
gcc/ChangeLog:
PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller. Place skeleton DIE under parent DIE of original declaration.
Move call to copy_declaration_context to here ...
(break_out_comdat_types): ... from here.
gcc/testsuite/ChangeLog:
PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.
2012-01-19 Cary Coutant
Dodji Seketeli
gcc/ChangeLog:
PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller. Place skeleton DIE under parent DIE of original declaration.
Move call to copy_declaration_context to here ...
(break_out_comdat_types): ... from here.
gcc/testsuite/ChangeLog:
PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.
commit 959d3b18ff6812a0316960ac49b283c11fd20460
Author: Cary Coutant
Date: Thu Jan 19 14:00:59 2012 -0800
PR debug/45682: Place skeleton DIE under parent of original decl.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f9f4295..6101087 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3302,11 +3302,12 @@ static int should_move_die_to_comdat (dw_die_ref);
static dw_die_ref clone_as_declaration (dw_die_ref);
static dw_die_ref clone_die (dw_die_ref);
static dw_die_ref clone_tree (dw_die_ref);
-static void copy_declaration_context (dw_die_ref, dw_die_ref);
+static dw_die_ref copy_declaration_context (dw_die_ref, dw_die_ref);
static void generate_skeleton_ancestor_tree (skeleton_chain_node *);
static void generate_skeleton_bottom_up (skeleton_chain_node *);
static dw_die_ref generate_skeleton (dw_die_ref);
static dw_die_ref remove_child_or_replace_with_skeleton (dw_die_ref,
+ dw_die_ref,
dw_die_ref);
static void break_out_comdat_types (dw_die_ref);
static dw_die_ref copy_ancestor_tree (dw_die_ref, dw_die_ref, htab_t);
@@ -7070,16 +7071,17 @@ clone_as_declaration (dw_die_ref die)
return clone;
}
-/* Copy the declaration context to the new compile unit DIE. This includes
+/* Copy the declaration context to the new type unit DIE. This includes
any surrounding namespace or type declarations. If the DIE has an
AT_specification attribute, it also includes attributes and children
attached to the specification. */
-static void
+static dw_die_ref
copy_declaration_context (dw_die_ref unit, dw_die_ref die)
{
dw_die_ref decl;
dw_die_ref new_decl;
+ dw_die_ref orig_parent = NULL;
decl = get_AT_ref (die, DW_AT_specification);
if (decl == NULL)
@@ -7090,6 +7092,10 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref
die)
dw_die_ref c;
dw_attr_ref a;
+ /* The original DIE will be changed to a declaration, and must
+ be moved to be a child of the original declaration DIE. */
+ orig_parent = decl->die_parent;
+
/* Copy the type node pointer from the new DIE to the original
declaration DIE so we can forward references later. */
decl->die_id.die_type_node = die->die_id.die_type_node;
@@ -7118,6 +7124,8 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref die)
add_AT_specification (die, new_decl);
}
}
+
+ return orig_parent;
}
/* Generate the skeleton ancestor tree for the given NODE, then clone
@@ -7201,17 +7209,23 @@ generate_skeleton (dw_die_ref die)
return node.new_die;
}
-/* Remove the DIE from its parent, possibly replacing it with a cloned
- declaration. The original DIE will be moved to a new compile unit
- so that existing references to it follow it to the new location. If
- any of the original DIE's descendants is a declaration, we need to
- replace the original DIE with a skeleton tree and move the
- declarations back into the skeleton tree. */
+/* Remove the CHILD DIE from its parent, possibly replacing it with a cloned
+ declaration. The original DIE is moved to a new compile unit so that
+ existing references to it follow it to the new location. If any of the
+ original DIE's descendants is a declaration, we need to replace the
+
Re: [PATCH, go] Add -mieee to various go.test tests
Uros Bizjak writes: > Attached patch adds -mieee to tests that need full IEEE compliance to > pass. While working on patch, I have noticed that go-test.exp doesn't > pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected > format (so, these simply get ignored). With this issue fixed, we can > add -mieee to DEFAULT_GOCFLAGS. Tests, compiled through torture > procedure, expects their special flags in a separate driver file. > > Attached patch fixes all "floating point errors" on > alphaev68-pc-linux-gnu through these two methods. > > 2012-01-19 Uros Bizjak > > * go.test/go-test.exp (go-gc-tests): Add -mieee to DEFAULT_GOCFLAGS > for alpha*-*-* and sh*-*-* to enable full IEEE compliance mode. > Pass correctly formatted options to go_target_compile. > * go.test/test/fixedbugs/bug321.x: New file. > * go.test/test/zerodivide.x: Ditto. > * go.test/test/floatcmp.x: Ditto. > > Patch was tested on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu. > > OK for mainline SVN? I did implement support for .x files in go-test.exp for some reason, but actually I should not have. I want the contents of the go.test/test directory to be an exact copy of the master Go testsuite except for the README.gcc file, which it is. So I would like to see this fixed in some other way. Sorry. And I just have to repeat that this patch is an ugly ugly hack, since -mieee should be the default. Perhaps we should investigate having gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those targets which require it. Ian
Re: [v3] proposed fix for libstdc++/49204 causes abi_check failure
On 31 December 2011 17:33, Jonathan Wakely wrote: > I want to commit the attached patch: > > PR libstdc++/49204 > * include/std/future (__future_base::_State_base::wait()): Call > _M_complete_async instead of _M_run_deferred. > (__future_base::_State_base::wait_for()): Call _M_has_deferred and > return future_status. > (__future_base::_State_base::wait_until()): Likewise. > (__future_base::_State_base::_M_run_deferred()): Rename to ... > (__future_base::_State_base::_M_complete_async()): This. > (__future_base::_State_base::_M_has_deferred()): New. > (__basic_future::wait_for(), __basic_future::wait_until()): Return > future_status. > (__future_base::_Deferred_state::_M_run_deferred()): Rename to ... > (__future_base::_Deferred_state::_M_complete_async()): This. > (__future_base::_Async_state::_M_join()): New. > (__future_base::_Async_state::~_Async_state()): Call _M_join. > (__future_base::_Async_state::_M_complete_async()): Likewise. > * testsuite/30_threads/packaged_task/members/get_future.cc: Expect > future_status return instead of bool. > * testsuite/30_threads/shared_future/members/wait_until.cc: Likewise. > * testsuite/30_threads/shared_future/members/wait_for.cc: Likewise. > * testsuite/30_threads/future/members/wait_until.cc: Likewise. > * testsuite/30_threads/future/members/wait_for.cc: Likewise. > * testsuite/30_threads/promise/members/set_value2.cc: Likewise. > * testsuite/30_threads/promise/members/set_value3.cc: Likewise. > * testsuite/30_threads/promise/members/swap.cc: Likewise. > * testsuite/30_threads/async/sync.cc: Likewise, and test 'deferred' > status. > > But it causes this abi_check error: > > 1 incompatible symbols > 0 > _ZTVNSt13__future_base11_State_baseE > vtable for std::__future_base::_State_base > version status: unversioned > type: object > type size: 48 > status: > > incompatible sizes > 40 > 48 > > I've renamed _M_run_deferred to _M_complete_async but it has the same > signature, semantics and position in the vtable. I've also added > _M_has_deferred() at the end of the vtable, for an internal > implementation type that users use directly or refer to. Is that OK > and the testsuite can be adjusted to know about the new vtable size? Here's a different, partial fix for PR 49204, changing the timed waiting functions to return future_status, but not returning future_status::deferred, as that requires the ABI change detailed above. This doesn't change the library ABI, but might still be too big a change for 4.7 at this stage. The ChangeLog is in several parts, as I did the work in stages. I'd combine that properly if checking it in. Define the key function non-inline, so it's only emitted in the library not every file using std::async: PR libstdc++/49204 * include/std/future (__future_base::_Async_state_common): Do not define destructor inline. * src/future.cc (__future_base::_Async_state_common): Define destructor, so key function is in the library. * config/abi/pre/gnu.ver: Add exports for ~_Async_state_common. Meet the synchronisation requirement, as stated in the PR: PR libstdc++/49204 * include/std/future (__future_base::_Async_state): Replace with _Async_state_common class for non-dependent functionality and _Async_state_impl class template for dependent functionality. (__future_base::_Async_state_common::_M_join): Serialize attempts to join thread. (__future_base::_Async_state_common::_M_run_deferred): Join. (__future_base::_Async_state::_M_do_run): Replace with lambda. Make timed waiting functions return future_status: PR libstdc++/49204 * include/std/future (__future_base::_State_base::wait()): Use lambda expression for predicate and remove redundant test. (__future_base::_State_base::wait_for()): Return future_status and use lambda expression for predicate. (__future_base::_State_base::wait_until()): Likewise. (__basic_future::wait_for(), __basic_future::wait_until()): Likewise. * testsuite/30_threads/packaged_task/members/get_future.cc: Expect future_status return instead of bool. * testsuite/30_threads/shared_future/members/wait_until.cc: Likewise. * testsuite/30_threads/shared_future/members/wait_for.cc: Likewise. * testsuite/30_threads/future/members/wait_until.cc: Likewise. * testsuite/30_threads/future/members/wait_for.cc: Likewise. * testsuite/30_threads/promise/members/set_value2.cc: Likewise. * testsuite/30_threads/promise/members/set_value3.cc: Likewise. * testsuite/30_threads/promise/members/swap.cc: Likewise. The final piece, not included in this patch, would be adding the new virtual function and renam
Re: [PATCH, go] Add -mieee to various go.test tests
On Jan 19, 2012, at 3:39 PM, Ian Lance Taylor wrote: > And I just have to repeat that this patch is an ugly ugly hack, since > -mieee should be the default. Perhaps we should investigate having > gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those > targets which require it. I agree. One way forward may be to make -mieee a MI flag then you can portably introduce it unconditionally into the specs (ick) or into the option processing code to default it on for go (and java). Don't know about Ada or Fortran.
Re: [Patch,docs,AVR,M32C, RL78, SPU]: Describe AVR address spaces and more AVR options
2012/1/19 Georg-Johann Lay : > Georg-Johann Lay wrote: >> This is basically documentation of AVR specific extensions and stuff like >> >> * command line options like -maccumulate-args etc. >> * AVR named address spaces >> >> Section doc/extend.texi::Named Address Spaces is split into several >> subsections >> now; each subsection taking care of one target in alphabetical order: >> AVR, M32C, RL78, SPU. >> >> As I already wrote in http://gcc.gnu.org/ml/gcc/2012-01/msg00175.html >> references in the documentation miss their intended anchors/targets. That is >> a >> general problem and not specific to the new references introduced by this >> patch. >> >> Ok to commit? >> >> Johann >> >> * doc/extend.texi (Named Address Spaces): Split into subsections. >> (AVR Named Address Spaces): New subsection. >> (M32C Named Address Spaces): New subsection. >> (RL78 Named Address Spaces): New subsection. >> (SPU Named Address Spaces): New subsection. >> (Variable Attributes): New anchor "AVR Variable Attributes". >> (AVR Variable Attributes): Rewrite and avoid wording >> "address space" in this context. >> * doc/invoke.texi (AVR Options): Rewrite and add documentation >> for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls. >> (AVR Built-in Macros): New subsubsection therein. >> * doc/md.texi (AVR constraints): Remove "C04", "R". > > ...and for the curious, here is the patch. > Please commit. Denis.
[Patch, Fortran] PR51056 - fix __vtab USE warnings
-Wall was warning about explicitly imported but not used __vtab,
__def_init etc. variables.
Build and regtested on x86-64-linux
OK for the trunk?
Tobias
2012-01-20 Tobias Burnus
Janus Weil
PR fortran/51056
* module.c (load_needed, read_module): Don't mark __vtab etc.
as use_only.
2012-01-20 Tobias Burnus
Janus Weil
PR fortran/51056
* gfortran.dg/use_21.f90: New.
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 0616a85..b2808d4 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4351,7 +4351,11 @@ load_needed (pointer_info *p)
mio_symbol (sym);
sym->attr.use_assoc = 1;
- if (only_flag)
+
+ /* Mark as only or rename for later diagnosis for explicitly imported
+ but not used warnings; don't mark internal symbols such as __vtab,
+ __def_init etc. */
+ if (only_flag && sym->name[0] != '_' && sym->name[1] != '_')
sym->attr.use_only = 1;
if (p->u.rsym.renamed)
sym->attr.use_rename = 1;
@@ -4574,8 +4578,9 @@ read_module (void)
p = name;
/* Exception: Always import vtabs & vtypes. */
- if (p == NULL && (strncmp (name, "__vtab_", 5) == 0
- || strncmp (name, "__vtype_", 6) == 0))
+ if (p == NULL && name[0] == '_'
+ && (strncmp (name, "__vtab_", 5) == 0
+ || strncmp (name, "__vtype_", 6) == 0))
p = name;
/* Skip symtree nodes not in an ONLY clause, unless there
@@ -4641,7 +4646,10 @@ read_module (void)
if (strcmp (name, p) != 0)
sym->attr.use_rename = 1;
- sym->attr.use_only = only_flag;
+ if (name[0] != '_'
+ || (strncmp (name, "__vtab_", 5) != 0
+ && strncmp (name, "__vtype_", 6) != 0))
+ sym->attr.use_only = only_flag;
/* Store the symtree pointing to this symbol. */
info->u.rsym.symtree = st;
--- /dev/null 2012-01-19 08:39:17.883655782 +0100
+++ gcc/gcc/testsuite/gfortran.dg/use_21.f90 2012-01-19 20:12:11.0 +0100
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-Wall" }
+!
+! PR fortran/51056
+!
+! Contributed by Kacper Kowalik
+!
+module domain
+ implicit none
+ private
+ public :: domain_container, dom
+
+ type :: domain_container
+ integer :: D_x !< set to 1 when x-direction exists, 0 otherwise
+contains
+ procedure :: init => init_domain_container
+ end type domain_container
+
+ type(domain_container) :: dom
+
+ contains
+ subroutine init_domain_container(this)
+ implicit none
+ class(domain_container), intent(inout) :: this
+ this%D_x = 0
+ end subroutine init_domain_container
+end module domain
+
+program ala
+ use domain, only: dom
+ implicit none
+ call dom%init
+end program ala
+
+! { dg-final { cleanup-modules "domain" } }
Re: [Patch, Fortran] PR51056 - fix __vtab USE warnings
Dear Tobias, This patch is OK for trunk. I have made a lot of progress on PR51870; class scalars work correctly but I need to extend the fix to class arrays. It requires a complete rewrite of the parts of gfc_trans_allocate that are associated with class allocation and initialization. The result is much cleaner and is based on the API in trans-expr.c, rather than the present kludgy use of the frontend. Cheers Paul On Fri, Jan 20, 2012 at 8:09 AM, Tobias Burnus wrote: > -Wall was warning about explicitly imported but not used __vtab, __def_init > etc. variables. > > Build and regtested on x86-64-linux > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
