[Patch, Fortran, committed] PR 51082: [F03] Wrong result for a pointer to a proc-pointer component
Hi all, I have just committed as obvious a simple one-line fix for a procedure pointer problem (after a successful regtest): http://gcc.gnu.org/viewcvs?view=revision&revision=186465 Cheers, Janus
Re: [Patch, Fortran] PR52864 - Fix pointer-intent regresssion
Hi Tobias,
> That's a GCC 4.6-4.8 regression. Pointer intents apply to the association
> status and not to the value. Thus, assigning to an intent(in) pointer is
> fine. The problem was that the LHS is no pointer due to the array access
> ("dt%ptr(1) =") thus, the check got triggered.
>
> Build and regtested on x86-64-linux.
> OK for the trunk and the 4.6/4.7 branch?
I'd say this patch is ok for trunk immediately, and for the branches
after a short waiting-period. Maybe you could extend the comment above
the code you're modifying?
Thanks,
Janus
RFA: Remove ADDRESS handling from gen*.c
ADDRESS has long had no meaning in .md files. This patch removes
the associated gen* support.
Borders on the obvious, but just to be sure: bootstrapped & regression
tested on x86_64-linux-gnu. OK to install?
Richard
gcc/
* genemit.c (gen_exp): Remove ADDRESS handling.
* genoutput.c (scan_operands): Likewise.
* genpeep.c (match_rtx): Likewise.
* genrecog.c (add_to_sequence): Likewise.
Index: gcc/genemit.c
===
--- gcc/genemit.c 2012-03-06 19:20:53.0 +
+++ gcc/genemit.c 2012-04-15 10:35:29.615548775 +0100
@@ -160,9 +160,6 @@ gen_exp (rtx x, enum rtx_code subroutine
gen_rtx_scratch (x, subroutine_type);
return;
-case ADDRESS:
- fatal ("ADDRESS expression code used in named instruction pattern");
-
case PC:
printf ("pc_rtx");
return;
Index: gcc/genoutput.c
===
--- gcc/genoutput.c 2011-08-27 09:54:07.0 +0100
+++ gcc/genoutput.c 2012-04-15 10:35:29.617548777 +0100
@@ -510,10 +510,6 @@ scan_operands (struct data *d, rtx part,
scan_operands (d, XVECEXP (part, 2, i), 0, 0);
return;
-case ADDRESS:
- scan_operands (d, XEXP (part, 0), 1, 0);
- return;
-
case STRICT_LOW_PART:
scan_operands (d, XEXP (part, 0), 0, 1);
return;
Index: gcc/genpeep.c
===
--- gcc/genpeep.c 2011-08-27 09:54:07.0 +0100
+++ gcc/genpeep.c 2012-04-15 10:35:29.617548777 +0100
@@ -231,10 +231,6 @@ match_rtx (rtx x, struct link *path, int
}
return;
-case ADDRESS:
- match_rtx (XEXP (x, 0), path, fail_label);
- return;
-
default:
break;
}
Index: gcc/genrecog.c
===
--- gcc/genrecog.c 2011-08-27 09:54:07.0 +0100
+++ gcc/genrecog.c 2012-04-15 11:14:58.661416813 +0100
@@ -687,7 +687,6 @@ add_to_sequence (rtx pattern, struct dec
sub = this_decision = new_decision (pos, last);
place = &this_decision->tests;
- restart:
mode = GET_MODE (pattern);
code = GET_CODE (pattern);
@@ -854,10 +853,6 @@ add_to_sequence (rtx pattern, struct dec
test->u.dup = XINT (pattern, 0);
goto fini;
-case ADDRESS:
- pattern = XEXP (pattern, 0);
- goto restart;
-
default:
break;
}
RFA: Clean up ADDRESS handling in alias.c
The comment in alias.c says:
The contents of an ADDRESS is not normally used, the mode of the
ADDRESS determines whether the ADDRESS is a function argument or some
other special value. Pointer equality, not rtx_equal_p, determines whether
two ADDRESS expressions refer to the same base address.
The only use of the contents of an ADDRESS is for determining if the
current function performs nonlocal memory memory references for the
purposes of marking the function as a constant function. */
The first paragraph is a bit misleading IMO. AFAICT, rtx_equal_p has
always given ADDRESS the full recursive treatment, rather than saying
that pointer equality determines ADDRESS equality. (This is in contrast
to something like VALUE, where pointer equality is used.) And AFAICT
we've always had:
static int
base_alias_check (rtx x, rtx y, enum machine_mode x_mode,
enum machine_mode y_mode)
{
...
/* If the base addresses are equal nothing is known about aliasing. */
if (rtx_equal_p (x_base, y_base))
return 1;
...
}
So I think the contents of an ADDRESS _are_ used to distinguish
between different bases.
The second paragraph ceased to be true in 2005 when the pure/const
analysis moved to its own IPA pass. Nothing now looks at the contents
beyond rtx_equal_p.
Also, base_alias_check effectively treats all arguments as a single base.
That makes conceptual sense, because this analysis isn't strong enough
to determine whether arguments are base values at all, never mind whether
accesses based on different arguments conflict. But the fact that we have
a single base isn't obvious from the way the code is written, because we
create several separate, non-rtx_equal_p, ADDRESSes to represent arguments.
See:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
/* Check whether this register can hold an incoming pointer
argument. FUNCTION_ARG_REGNO_P tests outgoing register
numbers, so translate if necessary due to register windows. */
if (FUNCTION_ARG_REGNO_P (OUTGOING_REGNO (i))
&& HARD_REGNO_MODE_OK (i, Pmode))
static_reg_base_value[i]
= gen_rtx_ADDRESS (VOIDmode, gen_rtx_REG (Pmode, i));
and:
/* Check for an argument passed in memory. Only record in the
copying-arguments block; it is too hard to track changes
otherwise. */
if (copying_arguments
&& (XEXP (src, 0) == arg_pointer_rtx
|| (GET_CODE (XEXP (src, 0)) == PLUS
&& XEXP (XEXP (src, 0), 0) == arg_pointer_rtx)))
return gen_rtx_ADDRESS (VOIDmode, src);
I think it would be cleaner and less wasteful to use a single rtx for
the single "base" (really "potential base").
So if we wanted to, we could now remove the operand from ADDRESS and
simply rely on pointer equality. I'm a bit reluctant to do that though.
It would make debugging harder, and it would mean either adding knowledge
of this alias-specific code to other files (specifically rtl.c:rtx_equal_p),
or adding special ADDRESS shortcuts to alias.c. But I think the code
would be more obvious if we replaced the rtx operand with a unique id,
which is what we already use for the REG_NOALIAS case:
new_reg_base_value[regno] = gen_rtx_ADDRESS (Pmode,
GEN_INT (unique_id++));
And if we do that, we can make the id a direct operand of the ADDRESS,
rather than a CONST_INT subrtx[*]. That should make rtx_equal_p cheaper too.
[*] I'm trying to get rid of CONST_INTs like these that have
no obvious mode.
All of which led to the patch below. I checked that it didn't change
the code generated at -O2 for a recent set of cc1 .ii files. Also
bootstrapped & regression-tested on x86_64-linux-gnu. OK to install?
To cover my back: I'm just trying to rewrite the current code according
to its current assumptions. Whether those assumptions are correct or not
is always open to debate...
Richard
gcc/
* rtl.def (ADDRESS): Turn operand into a HOST_WIDE_INT.
* alias.c (reg_base_value): Expand and update comment.
(arg_base_value): New variable.
(unique_id): Move up file.
(unique_base_value, unique_base_value_p, known_base_value_p): New.
(find_base_value): Use arg_base_value and known_base_value_p.
(record_set): Document REG_NOALIAS handling. Use unique_base_value.
(find_base_term): Use known_base_value_p.
(base_alias_check): Use unique_base_value_p.
(init_alias_target): Initialize arg_base_value. Use unique_base_value.
(init_alias_analysis): Use 1 as the first id for REG_NOALIAS bases.
Index: gcc/rtl.def
===
--- gcc/rtl.def 2012-04-15 15:23:52.747632394 +0100
+++ gcc/rtl.def 2012-04-15 15:58:48.234515667 +0100
@@ -109,8 +109,8 @@ DEF_RTL_EXPR(INSN_LIST, "insn_list", "ue
`emit_insn' takes the SEQUENCE apart and makes separate insns. */
DEF_RTL
Re: [Patch, Fortran] PR52916 - fix TREE_PUBLIC() = 0 for module procedures
On Wed, Apr 11, 2012 at 5:54 AM, Tobias Burnus wrote: > Dear all, > > my recent patch for setting PRIVATE module variables and procedures to > TREE_PUBLIC()=0 had a flaw: I completely forgot about generic interfaces. > Even if the specific name is PRIVATE, the specific function is still > callable through the a (public) generic name. > > Thanks to HJ for the report. (The bug causes a failures of SPEC CPU 2006.) > > I think the handling of type-bound procedures is correct. However, I > wouldn't mind if someone could confirm it. I only check for the specific > entries as GENERIC, OPERATOR and ASSIGNMENT use a type-bound-proc name, > which is already handled. I also didn't try to optimize for private DT, > private generics etc. First, I think it is not needed. And secondly, through > inheritance, it can get extremely complicated. > > Build and regtested on x86-64-linux. > OK for the trunk? > The testcase failed with /export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90:11.4:^M ^M use m^M 1^M Fatal Error: Can't open module file 'm.mod' for reading at (1): No such file or directory^M compiler exited with status 1 -- H.J.
C++ PATCH for c++/52818 (%ld in C++11)
C++11 inherits from C99, so we shouldn't complain about using %ld in
that mode.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4433edb6e099fbb6251c1ab76266108c45582ebc
Author: Jason Merrill
Date: Fri Apr 13 16:03:59 2012 -0400
PR c++/52818
* c-format.c (CPLUSPLUS_STD_VER): C++11 inherits from C99.
(C_STD_NAME): Distinguish between C++98 and C++11.
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 9fabc39..b967492 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -334,7 +334,7 @@ decode_format_attr (tree args, function_format_info *info, int validated_p)
/* The C standard version C++ is treated as equivalent to
or inheriting from, for the purpose of format features supported. */
-#define CPLUSPLUS_STD_VER STD_C94
+#define CPLUSPLUS_STD_VER (cxx_dialect < cxx11 ? STD_C94 : STD_C99)
/* The C standard version we are checking formats against when pedantic. */
#define C_STD_VER ((int) (c_dialect_cxx () \
? CPLUSPLUS_STD_VER \
@@ -345,7 +345,8 @@ decode_format_attr (tree args, function_format_info *info, int validated_p)
pedantic. FEATURE_VER is the version in which the feature warned out
appeared, which is higher than C_STD_VER. */
#define C_STD_NAME(FEATURE_VER) (c_dialect_cxx () \
- ? "ISO C++" \
+ ? (cxx_dialect < cxx11 ? "ISO C++98" \
+: "ISO C++11") \
: ((FEATURE_VER) == STD_EXT \
? "ISO C" \
: "ISO C90"))
diff --git a/gcc/testsuite/g++.dg/warn/format8.C b/gcc/testsuite/g++.dg/warn/format8.C
new file mode 100644
index 000..ffceb79
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/format8.C
@@ -0,0 +1,7 @@
+// PR c++/52818
+// { dg-options "-pedantic-errors -Wformat" }
+
+extern "C" int printf (const char *, ...);
+void f() {
+ printf("%lf", 0.0); // { dg-warning "%lf" "" { target c++98 } }
+}
C++ PATCH for c++/52706 (nullptr_t mangling)
We were incorrectly treating nullptr_t as a substitutable type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d13e197a238f2cbcca283e8d2332ea75af00b297
Author: Jason Merrill
Date: Fri Apr 13 17:34:31 2012 -0400
PR c++/52706
* mangle.c (write_type): nullptr_t is a builtin type.
diff --git a/gcc/common.opt b/gcc/common.opt
index 39f1679..ee0c66a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -788,6 +788,8 @@ Driver Undocumented
;argument.
;First selectable in G++ 4.7.
;
+; 7: The version of the ABI that treats nullptr_t as a builtin type.
+;First selectable in G++ 4.8.
; Additional positive integers will be assigned as new versions of
; the ABI become the default version of the ABI.
fabi-version=
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 1536828..d00df1f 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2023,6 +2023,8 @@ write_type (tree type)
case NULLPTR_TYPE:
write_string ("Dn");
+ if (abi_version_at_least (7))
+ ++is_builtin_type;
break;
case TYPEOF_TYPE:
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr27.C b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
new file mode 100644
index 000..1b86868
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
@@ -0,0 +1,8 @@
+// PR c++/52706
+// { dg-options "-std=c++11 -fabi-version=0" }
+// { dg-final { scan-assembler "_Z1fIDnLDn0EEiT_" } }
+
+template
+int f(T);
+
+int i2 = f(nullptr); // 17
Re: [Patch, Fortran] PR52916 - fix TREE_PUBLIC() = 0 for module procedures
> The testcase failed with ...
It is fixed by the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/public_private_module_3.f90
2012-04-15 11:18:00.0 +0200
+++ gcc/testsuite/gfortran.dg/public_private_module_3.f90 2012-04-15
19:09:10.0 +0200
@@ -58,3 +58,4 @@ contains
subroutine foo()
end subroutine foo
end module m2
+! { dg-final { keep-modules "" } }
--- ../_clean/gcc/testsuite/gfortran.dg/public_private_module_4.f90
2012-04-15 11:18:00.0 +0200
+++ gcc/testsuite/gfortran.dg/public_private_module_4.f90 2012-04-15
19:12:08.0 +0200
@@ -20,3 +20,5 @@ a = b + (c .myop. a)
call x%func()
end
+! { dg-final { cleanup-modules "m" } }
+! { dg-final { cleanup-modules "m2" } }
This may need some synchronization with
implicitly cleanup-modules, part 2.
Dominique
Re: [Patch, Fortran] PR52916 - fix TREE_PUBLIC() = 0 for module procedures
H.J. Lu wrote:
The testcase failed with
/export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90:11.4:^M
^M
use m^M
1^M
Fatal Error: Can't open module file 'm.mod' for reading at (1): No
such file or directory^M
compiler exited with status 1
Ups. Seemingly, the mod files in the testsuite/gfortran.dg got picked
up. Additional sources are appended after the main source - rather than
the other way round.
I intent to fix it with the following patch.
Thanks for testing!
Tobias
Index: public_private_module_3.f90
===
--- public_private_module_3.f90 (Revision 186467)
+++ public_private_module_3.f90 (Arbeitskopie)
@@ -1,7 +1,6 @@
-! { dg-do compile }
+! { dg-do link }
+! { dg-additional-sources public_private_module_4.f90 }
!
-! To be used by public_private_module_4.f90
-!
! PR fortran/52916
! Cf. PR fortran/40973
!
Index: public_private_module_4.f90
===
--- public_private_module_4.f90 (Revision 186467)
+++ public_private_module_4.f90 (Arbeitskopie)
@@ -1,6 +1,7 @@
-! { dg-do link }
-! { dg-additional-sources public_private_module_3.f90 }
+! { dg-do compile { target skip-all-targets } }
!
+! To be used by public_private_module_3.f90
+!
! PR fortran/52916
! Cf. PR fortran/40973
!
[libcpp] maybe canonicalize system paths in line-map
This patch tries to store the shortest form of a path to a system file, either the original given or the canonical form returned by realpath. User files are left untouched. This converts this: t.cc: In function 'void f()': t.cc:2:23: error: no matching function for call to 'sort(int)' t.cc:2:23: note: candidates are: In file included from /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0, from t.cc:1: /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template void std::sort(_RAIter, _RAIter) /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template argument deduction/substitution failed: t.cc:2:23: note: candidate expects 2 arguments, 1 provided In file included from /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0, from t.cc:1: /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template void std::sort(_RAIter, _RAIter, _Compare) /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template argument deduction/substitution failed: t.cc:2:23: note: candidate expects 3 arguments, 1 provided into this: canonicalize-paths.C: In function ‘void f()’: canonicalize-paths.C:2:23: error: no matching function for call to ‘sort(int)’ canonicalize-paths.C:2:23: note: candidates are: In file included from /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0, from canonicalize-paths.C:1: /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template void std::sort(_RAIter, _RAIter) /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template argument deduction/substitution failed: canonicalize-paths.C:2:23: note: candidate expects 2 arguments, 1 provided In file included from /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0, from canonicalize-paths.C:1: /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template void std::sort(_RAIter, _RAIter, _Compare) /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template argument deduction/substitution failed: canonicalize-paths.C:2:23: note: candidate expects 3 arguments, 1 provided Bootstrapped and regtested on x86-64-unknown-linux-gnu. OK for trunk? 2012-04-15 Manuel López-Ibáñez PR 52974 libcpp/ * line-map.c (maybe_shorter_path): New. (linemap_add): Use it. pr52974.diff Description: Binary data
[Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected
Hi all, here is a small patch for an OOP problem. For discussion see the PR. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2012-04-15 Janus Weil PR fortran/52968 * class.c (gfc_build_class_symbol): Make sure the 'f2k_derived' namespace is present. 2012-04-15 Janus Weil PR fortran/52968 * gfortran.dg/typebound_call_23.f03: New test case. pr52968.diff Description: Binary data typebound_call_23.f03 Description: Binary data
[v3] libstdc++/52702
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
/
2012-04-15 Paolo Carlini
PR libstdc++/52702
* include/std/type_traits (is_trivially_destructible): Add.
(has_trivial_destructor): Remove.
* testsuite/util/testsuite_common_types.h: Adjust.
* testsuite/20_util/tuple/requirements/dr801.cc: Likewise.
* testsuite/20_util/pair/requirements/dr801.cc: Likewise.
* testsuite/20_util/is_trivially_destructible/value.cc: New.
* testsuite/20_util/is_trivially_destructible/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_destructible/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Adjust dg-error line numbers.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Likewise.
Index: include/std/type_traits
===
--- include/std/type_traits (revision 186464)
+++ include/std/type_traits (working copy)
@@ -1147,30 +1147,45 @@
: public __is_nt_move_assignable_impl<_Tp>
{ };
- /// has_trivial_default_constructor
+ /// is_trivially_constructible (still unimplemented)
+
+ /// is_trivially_default_constructible (still unimplemented)
+
+ /// is_trivially_copy_constructible (still unimplemented)
+
+ /// is_trivially_move_constructible (still unimplemented)
+
+ /// is_trivially_assignable (still unimplemented)
+
+ /// is_trivially_copy_assignable (still unimplemented)
+
+ /// is_trivially_move_assignable (still unimplemented)
+
+ /// is_trivially_destructible
template
+struct is_trivially_destructible
+: public __and_, integral_constant>::type
+{ };
+
+ /// has_trivial_default_constructor (temporary legacy)
+ template
struct has_trivial_default_constructor
: public integral_constant
{ };
- /// has_trivial_copy_constructor
+ /// has_trivial_copy_constructor (temporary legacy)
template
struct has_trivial_copy_constructor
: public integral_constant
{ };
- /// has_trivial_copy_assign
+ /// has_trivial_copy_assign (temporary legacy)
template
struct has_trivial_copy_assign
: public integral_constant
{ };
- /// has_trivial_destructor
- template
-struct has_trivial_destructor
-: public integral_constant
-{ };
-
/// has_virtual_destructor
template
struct has_virtual_destructor
Index: testsuite/util/testsuite_common_types.h
===
--- testsuite/util/testsuite_common_types.h (revision 186464)
+++ testsuite/util/testsuite_common_types.h (working copy)
@@ -549,7 +549,7 @@
typedef std::has_trivial_default_constructor<_Tp> ctor_p;
static_assert(ctor_p::value, "default constructor not trivial");
- typedef std::has_trivial_destructor<_Tp> dtor_p;
+ typedef std::is_trivially_destructible<_Tp> dtor_p;
static_assert(dtor_p::value, "destructor not trivial");
}
};
Index: testsuite/20_util/tuple/requirements/dr801.cc
===
--- testsuite/20_util/tuple/requirements/dr801.cc (revision 186464)
+++ testsuite/20_util/tuple/requirements/dr801.cc (working copy)
@@ -29,7 +29,7 @@
// static_assert(std::is_literal_type::value, "! literal");
static_assert(std::has_trivial_copy_constructor::value,
"! triv copy");
- static_assert(std::has_trivial_destructor::value,
+ static_assert(std::is_trivially_destructible::value,
"! triv destructor");
// static_assert(std::is_standard_layout::value,
// "! standard layout");
Index: testsuite/20_util/pair/requirements/dr801.cc
===
--- testsuite/20_util/pair/requirements/dr801.cc(revision 186473)
+++ testsuite/20_util/pair/requirements/dr801.cc(working copy)
@@ -1,7 +1,7 @@
// { dg-do compile }
// { dg-options "-std=gnu++0x" }
-// Copyright (C) 2010 Free Software Foundation, Inc.
+// Copyright (C) 2010, 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
@@ -29,7 +29,7 @@
// static_assert(std::is_literal_type::value, "! literal");
static_assert(std::has_trivial_copy_constructor::value,
"! triv copy");
- static_assert(std::has_trivial_destructor::value,
+ static_assert(std::is_trivially_destructible::value,
"! triv destructor");
// static_assert(std::is_standard_layout::value,
// "! standard layout");
Index: testsuite/20_util/make_signed/requirements/typedefs_neg.cc
===
[doc] tm.texi: Move NO_DOLLAR_IN LABEL and NO_DOT_IN_LABEL to Label Output section (was: GCC 4.6.1 likes to rename my functions)
On Wed, 6 Jul 2011, Paulo J. Matos wrote:
> On 06/07/11 16:08, Richard Guenther wrote:
>> See cgraph.c:clone_function_name, it uses the NO_DOT_IN_LABEL and
>> NO_DOLLAR_IN_LABEL target macros and ASM_FORMAT_PRIVATE_NAME.
> Why are NO_DOLLAR_IN LABEL and NO_DOT_IN_LABEL not listed in the "Output
> and Generation of Labels" instead of "Misc". The former sounds like it's
> a better fit to describe these macros.
Because nobody moved them yet? ;-)
Richi, are you fine with this?
Gerald
2012-04-16 Gerald Pfeifer
* doc/tm.texi (Misc): Move descriptions of NO_DOLLAR_IN_LABEL
and NO_DOT_IN_LABEL from here...
(Label Output): ...to here.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 186466)
+++ doc/tm.texi (working copy)
@@ -7842,6 +7842,20 @@
to redefine @code{ASM_OUTPUT_MEASURED_SIZE} to use some other technique.
@end defmac
+@defmac NO_DOLLAR_IN_LABEL
+Define this macro if the assembler does not accept the character
+@samp{$} in label names. By default constructors and destructors in
+G++ have @samp{$} in the identifiers. If this macro is defined,
+@samp{.} is used instead.
+@end defmac
+
+@defmac NO_DOT_IN_LABEL
+Define this macro if the assembler does not accept the character
+@samp{.} in label names. By default constructors and destructors in G++
+have names that use @samp{.}. If this macro is defined, these names
+are rewritten to avoid @samp{.}.
+@end defmac
+
@defmac TYPE_ASM_OP
A C string containing the appropriate assembler directive to specify the
type of a symbol, without any arguments. On systems that use ELF, the
@@ -10778,20 +10792,6 @@
there is no need to define this macro in that case.
@end defmac
-@defmac NO_DOLLAR_IN_LABEL
-Define this macro if the assembler does not accept the character
-@samp{$} in label names. By default constructors and destructors in
-G++ have @samp{$} in the identifiers. If this macro is defined,
-@samp{.} is used instead.
-@end defmac
-
-@defmac NO_DOT_IN_LABEL
-Define this macro if the assembler does not accept the character
-@samp{.} in label names. By default constructors and destructors in G++
-have names that use @samp{.}. If this macro is defined, these names
-are rewritten to avoid @samp{.}.
-@end defmac
-
@defmac INSN_SETS_ARE_DELAYED (@var{insn})
Define this macro as a C expression that is nonzero if it is safe for the
delay slot scheduler to place instructions in the delay slot of @var{insn},
Re: jcf-reader: support for JSR 292 classfile extensions
On Wed, 11 Apr 2012, Andrew Haley wrote: > I wonder what we're supposed to do about warnings that only trigger > on 32-bit systems. Just wait for reports, or do we really have to > boostrap with both? I think it's okay not to bootstrap on 32-bit systems in addition to your regular testers. I bootstrap an i386 build nightly and will just report when something breaks, and I believe there are others as well. Gerald
Re: [C++ Patch] PR 49152
.. hi all, hi Gaby, a couple of days ago, Manuel suggested in the audit trail of the main "caret diagnostics" PR, that now that we actually have got a form of it, the kind of change I proposed to resolve PR 49152 may make much more sense. In any case, my original patch still regtests fine today. What do you think? Thanks, Paolo.
Re: [C++ Patch] PR 49152
On Sun, Apr 15, 2012 at 8:54 PM, Paolo Carlini wrote: > .. hi all, hi Gaby, > > a couple of days ago, Manuel suggested in the audit trail of the main "caret > diagnostics" PR, that now that we actually have got a form of it, the kind > of change I proposed to resolve PR 49152 may make much more sense. In any > case, my original patch still regtests fine today. > > What do you think? a hybrid approach; I would suggest something like this: (a) if caret is in effect, then print the caret pointing to the symbol in question; otherwise (b) print the symbol and the type (as suggested by Marc). This is all best abstracted in a separate function.
C++ PATCH for c++/52292 (problems with variadic member templates)
In coerce_template_parms, inner_args is the set of args we're actually
working on, whereas "args" also includes any args of the enclosing
scope. Treating the latter as the former leads to problems when there
actually are multiple levels.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 4e0709c10d6b3d9139eba31f6d162ae8b81915e2
Author: Jason Merrill
Date: Sun Apr 15 20:28:33 2012 -0400
PR c++/52292
PR c++/52380
* pt.c (coerce_template_parms): Even if we aren't converting we
want to expand argument packs.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 07a2cc0..42dc0a7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6882,7 +6882,7 @@ coerce_template_parms (tree parms,
{
/* We don't know how many args we have yet, just
use the unconverted ones for now. */
- new_inner_args = args;
+ new_inner_args = inner_args;
break;
}
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic124.C b/gcc/testsuite/g++.dg/cpp0x/variadic124.C
new file mode 100644
index 000..8ddc810
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic124.C
@@ -0,0 +1,29 @@
+// PR c++/52292
+// { dg-options -std=c++11 }
+
+template class T>
+struct foo {
+template
+foo(T x) { }
+};
+
+template
+struct bar {
+bar(T x) : value(x) { }
+
+T value;
+};
+
+struct generic : private foo {
+template
+generic(bar x) : foo(x)
+{
+}
+
+};
+
+int main()
+{
+bar x(32);
+generic y(x); // FAILS
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic125.C b/gcc/testsuite/g++.dg/cpp0x/variadic125.C
new file mode 100644
index 000..89fd6b0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic125.C
@@ -0,0 +1,25 @@
+// PR c++/52380
+// { dg-do compile { target c++11 } }
+
+template
+struct S
+{
+ template
+ struct Unary// Line 5
+ {};
+
+ template
+ struct Dispatch // Line 9
+: public Unary
+ {};
+
+ template
+ struct Variadic
+: public Dispatch
+ {};
+};
+
+int main()
+{
+ S::Variadic z;
+}
C++ PATCH for c++/47220 (accepts-invalid with ill-formed variadic argument list)
For some reason, coerce_template_parameter_pack wasn't checking for and
diagnosing error_mark_node like coerce_template_parms does. Fixed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 601d1dd536710d65054d6a24bbae2bbf7f1e466b
Author: Jason Merrill
Date: Sun Apr 15 20:58:07 2012 -0400
PR c++/47220
* pt.c (coerce_template_parameter_pack): Check for error_mark_node.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 42dc0a7..95d0aba 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6697,7 +6697,12 @@ coerce_template_parameter_pack (tree parms,
TREE_VEC_ELT (packed_types, arg_idx - parm_idx);
}
- if (arg != error_mark_node)
+ if (arg == error_mark_node)
+ {
+ if (complain & tf_error)
+ error ("template argument %d is invalid", arg_idx + 1);
+ }
+ else
arg = convert_template_argument (actual_parm,
arg, new_args, complain, parm_idx,
in_decl);
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr39639.C b/gcc/testsuite/g++.dg/cpp0x/pr39639.C
index 4fd8b56..0838a0b 100644
--- a/gcc/testsuite/g++.dg/cpp0x/pr39639.C
+++ b/gcc/testsuite/g++.dg/cpp0x/pr39639.C
@@ -2,6 +2,7 @@
// Origin: PR c++/39639
// { dg-do compile }
// { dg-options "-std=c++0x" }
+// { dg-prune-output "template argument 1 is invalid" }
template
struct S
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic126.C b/gcc/testsuite/g++.dg/cpp0x/variadic126.C
new file mode 100644
index 000..513c7e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic126.C
@@ -0,0 +1,8 @@
+// PR c++/47220
+// { dg-do compile { target c++11 } }
+
+template < typename ... > struct A;
+
+struct B : A < // { dg-error "invalid" }
+{
+};
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C b/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C
index 9ab2589..024afc8 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C
@@ -22,7 +22,7 @@ namespace A
{
template
struct I : H {};
- template struct J;
+ template struct J {};
template struct K;
struct L
{
@@ -36,7 +36,7 @@ namespace A
template
struct N : L::M {};
template
- struct K :J <,>, L
+ struct K :J <>, L
{
typedef T O (B4 ...);
struct P {};
Re: [C++ Patch] PR 49152
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote: a hybrid approach; I would suggest something like this: (a) if caret is in effect, then print the caret pointing to the symbol in question; otherwise (b) print the symbol and the type (as suggested by Marc). I may have forgotten the details, but looking at the beginning of the PR, don't we always want the types? Show where the failing operator== is, and print the types of the 2 arguments? I tried to parenthesize your sentence so it meant that, but it wasn't convincing... -- Marc Glisse
Re: [Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected
Janus Weil wrote: > here is a small patch for an OOP problem. For discussion see the PR. > Regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK and thanks for the patch. Note, however, that since Bernhard's patch*, using cleanup-modules is usually not needed. * http://gcc.gnu.org/ml/fortran/2012-03/msg00069.html Tobias > 2012-04-15 Janus Weil > > PR fortran/52968 > * class.c (gfc_build_class_symbol): Make sure the 'f2k_derived' > namespace is present. > > 2012-04-15 Janus Weil > > PR fortran/52968 > * gfortran.dg/typebound_call_23.f03: New test case.
