Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)
On 12/24/2012 05:56 AM, Jason Merrill wrote: On 12/22/2012 06:02 PM, Paolo Carlini wrote: Well, we still reject it after the patch My 4.7 and trunk compilers both accept it (with -std=c++11, of course). I just updated and rebuilt my 4.7 for you (which definitely I didn't hack over the next days) and it still rejects it. Likewise mainline. Note that the *first* testcase in the Bug Report, the one involving the abtract base, now is correctly accepted by both. Are you sure your patch handles the access control issue too?? (isn't obvious to me that it does, looking at the patch itself and your comments) Thanks, Paolo.
Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)
... to explain more concretely what I mean, if I *brutally* hack
mainline per the below, then the testcase is accepted.
Paolo.
//
Index: call.c
===
--- call.c (revision 194659)
+++ call.c (working copy)
@@ -7535,7 +7535,11 @@ build_new_method_call_1 (tree instance, tree fns,
if (CONSTRUCTOR_NELTS (init_list) == 0
TYPE_HAS_DEFAULT_CONSTRUCTOR (basetype)
!processing_template_decl)
- init = build_value_init (basetype, complain);
+ {
+ push_deferring_access_checks (dk_no_check);
+ init = build_value_init (basetype, complain);
+ pop_deferring_access_checks ();
+ }
/* If BASETYPE is an aggregate, we need to do aggregate
initialization. */
Re: [PATCH] PR c++/52343 - error with alias template as template template argument
Jason Merrill ja...@redhat.com writes:
On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
else if (TREE_TYPE (t)
INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
-!TREE_CONSTANT (t))
+!TREE_CONSTANT (t)
+ /* Class template and alias template arguments should be OK. */
+!DECL_TYPE_TEMPLATE_P (t))
Instead, let's add a previous else if to catch template template
arguments (and do nothing) so that when we hit this else if, we know
we're dealing with a non-type argument.
Right. Here you go.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
PR c++/52343
* pt.c (check_instantiated_arg): Allow type template arguments.
gcc/testsuite/
PR c++/52343
* g++.dg/cpp0x/alias-decl-29.C: New test.
---
gcc/cp/pt.c| 3 +++
gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C | 10 ++
2 files changed, 13 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1b3f039..9e99c09 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14421,6 +14421,9 @@ check_instantiated_arg (tree tmpl, tree t,
tsubst_flags_t complain)
return true;
}
}
+ /* Class template and alias template arguments should be OK. */
+ else if (DECL_TYPE_TEMPLATE_P (t))
+;
/* A non-type argument of integral or enumerated type must be a
constant. */
else if (TREE_TYPE (t)
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
new file mode 100644
index 000..f6cc695
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C
@@ -0,0 +1,10 @@
+// Origin: PR c++/52343
+// { dg-do compile { target c++11 } }
+
+templatetypename
+using A = int;
+
+templatetemplateclass class
+struct B {};
+
+BA b;
--
Dodji
Re: [PATCH] PR c++/52343 - error with alias template as template template argument
Gabriel Dos Reis g...@integrable-solutions.net writes: G On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill ja...@redhat.com wrote: On 12/21/2012 07:35 AM, Dodji Seketeli wrote: else if (TREE_TYPE (t) INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t)) - !TREE_CONSTANT (t)) + !TREE_CONSTANT (t) + /* Class template and alias template arguments should be OK. */ + !DECL_TYPE_TEMPLATE_P (t)) Instead, let's add a previous else if to catch template template arguments (and do nothing) so that when we hit this else if, we know we're dealing with a non-type argument. Thanks; that would make the logic clearer. I would suggest that we abstract this series of conjunction into a separate (static inline) function, e.g. nontype_argument_p. These conjunctions represents a non-type argument only if they are satisfied /and/ the previous 'if' branches are not taken. So just putting the conjunctions in e.g, nontype_argument_p could be seen as confusion too, IMHO. Could we just consider that the patch + comment of my earlier message and the comment of these conjunctions /* A non-type argument of integral or enumerated type must be a constant. */ should make this less confusing? -- Dodji
Re: [PATCH] PR c++/55311 - Cannot specialize alias template with arg of type array of char
Jason Merrill ja...@redhat.com writes:
On 12/22/2012 11:03 AM, Dodji Seketeli wrote:
[1]: The relacement of the VAR_DECL by its initializer is done by
decay_conversion by callig decl_constant_value_safe. That replacement
doesn't happen if processing_template_decl is not set. That's why it
doesn't happen for the class template instantiation at line 9, leading
to no error message there.
This is the bug. decay_conversion on an array should take the
address, not return the initializer.
Right. So would something like this be acceptable then?
gcc/cp/
PR c++/55311
* pt.c (decay_conversion): Do not return the initializer of an array.
gcc/testsuite/
PR c++/55311
* g++.dg/cpp0x/alias-decl-30.C: New test.
---
gcc/cp/typeck.c| 20 +---
gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C | 15 +++
2 files changed, 28 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ef76dcd..3fa913d 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1880,19 +1880,25 @@ decay_conversion (tree exp, tsubst_flags_t complain)
return error_mark_node;
}
- /* FIXME remove? at least need to remember that this isn't really a
- constant expression if EXP isn't decl_constant_var_p, like with
- C_MAYBE_CONST_EXPR. */
- exp = decl_constant_value_safe (exp);
- if (error_operand_p (exp))
-return error_mark_node;
+ code = TREE_CODE (type);
+
+ /* For and array decl decay_conversion should not try to return its
+ initializer. */
+ if (code != ARRAY_TYPE)
+{
+ /* FIXME remove? at least need to remember that this isn't really a
+constant expression if EXP isn't decl_constant_var_p, like with
+C_MAYBE_CONST_EXPR. */
+ exp = decl_constant_value_safe (exp);
+ if (error_operand_p (exp))
+ return error_mark_node;
+}
if (NULLPTR_TYPE_P (type) !TREE_SIDE_EFFECTS (exp))
return nullptr_node;
/* build_c_cast puts on a NOP_EXPR to make the result not an lvalue.
Leave such NOP_EXPRs, since RHS is being used in non-lvalue context. */
- code = TREE_CODE (type);
if (code == VOID_TYPE)
{
if (complain tf_error)
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
new file mode 100644
index 000..7ad5e6d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
@@ -0,0 +1,15 @@
+// Origin PR c++/55311
+// { dg-do compile { target c++11 } }
+
+template const char *const C, typename T
+struct A
+{};
+
+struct B {};
+
+extern constexpr char HELLO_WORLD[] = hello world;
+
+AHELLO_WORLD, B g; // -- This works fine
+
+template typename T
+using PartiallySpecialized = AHELLO_WORLD, T; // -- This fails
--
Dodji
Re: fix libquadmath build regression
Il 21/12/2012 06:17, Alexandre Oliva ha scritto: Revision 193063 brought in calls to fraiseexcept() into libquadmath, which caused a build regression on Fedora 16 (BLAG 160k actually) x86_64 while building an i686-linux-gnu native toolchain. The problem is that glibc has an extern inline definition of fraiseexcept that is introduced by including fenv.h (it's in bits/fenv.h), and this definition requires SSE support regardless of target arch of word width, so it doesn't work for an i686 native that doesn't assume SSE registers and instructions are available. This bug is fixed in newer versions of glibc, but I figured it wouldn't hurt to have a work-around in place for libquadmath to build, detecting that the extern inline in the header is broken and introducing a wrapper that bypasses the header so as to use the out-of-line definition in the math library. Is this ok to install? Would it be possible to fix it in fixincludes instead? Paolo
[RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64
Hello!
Currently, we use %rbx as REAL_PIC_OFFSET_TABLE_REGNUM on x86_64.
Since this register gets marked as fixed reg in
ix86_conditional_register_usage, we get into troubles with insns that
use %rbx (cmpxchg, cpuid). According to x86_64 psABI, we are free to
use any register, so attached patch changes %rbx with %r15 (also
following the example in the psABI). This patch has no implications on
small code model (that doesn't use REAL_PIC_OFFSET_TABLE_REGNUM
anyway), but on medium and large code model fixes usage of cpuid.h
(please see PR 55712 [1]) and avoids a pair of xchgs around cmpxchg or
cpuid instructions.
Probably, we can also enhance ix86_select_alt_pic_regnum for x86_64,
but this is 4.9 material.
2012-12-24 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (R14_REG, R15_REG): New constants.
* config/i386/i386.h (REAL_PIC_OFFSET_TABLE_REGNUM): Use R15_REG
for 64bit targets.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55712
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Uros.
Index: i386.h
===
--- i386.h (revision 194703)
+++ i386.h (working copy)
@@ -1173,7 +1173,7 @@
the pic register when possible. The change is visible after the
prologue has been emitted. */
-#define REAL_PIC_OFFSET_TABLE_REGNUM BX_REG
+#define REAL_PIC_OFFSET_TABLE_REGNUM (TARGET_64BIT ? R15_REG : BX_REG)
#define PIC_OFFSET_TABLE_REGNUM\
((TARGET_64BIT ix86_cmodel == CM_SMALL_PIC) \
Index: i386.md
===
--- i386.md (revision 194703)
+++ i386.md (working copy)
@@ -301,6 +301,8 @@
(R11_REG40)
(R12_REG41)
(R13_REG42)
+ (R14_REG43)
+ (R15_REG44)
(XMM8_REG 45)
(XMM9_REG 46)
(XMM10_REG 47)
Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64
Uros Bizjak ubiz...@gmail.com writes: Hello! Currently, we use %rbx as REAL_PIC_OFFSET_TABLE_REGNUM on x86_64. Since this register gets marked as fixed reg in ix86_conditional_register_usage, we get into troubles with insns that use %rbx (cmpxchg, cpuid). According to x86_64 psABI, we are free to use any register, so attached patch changes %rbx with %r15 (also following the example in the psABI). This patch has no implications on small code model (that doesn't use REAL_PIC_OFFSET_TABLE_REGNUM anyway), but on medium and large code model fixes usage of cpuid.h (please see PR 55712 [1]) and avoids a pair of xchgs around cmpxchg or cpuid instructions. So everyone who worked around this and use r15 now broke. It would be probably better to just teach the register allocator to spill those registers as needed, to handle some asm() statement. Not sure how hard that would be. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64
In the case of cpuid, the code is hardly performance sensitive, and probably runs only at startup. An alternative solution for the broken code here is to move the result from rbx to another register, and to save/restore rbx. Currently, this is the only place in libgcc and newlib affected by this problem. Leif Ekblad - Original Message - From: Andi Kleen a...@firstfloor.org To: Uros Bizjak ubiz...@gmail.com Cc: gcc-patches@gcc.gnu.org; Richard Henderson r...@redhat.com; Jakub Jelinek ja...@redhat.com; j...@suse.cz; H.J. Lu hjl.to...@gmail.com Sent: Monday, December 24, 2012 10:32 PM Subject: Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64 Uros Bizjak ubiz...@gmail.com writes: Hello! Currently, we use %rbx as REAL_PIC_OFFSET_TABLE_REGNUM on x86_64. Since this register gets marked as fixed reg in ix86_conditional_register_usage, we get into troubles with insns that use %rbx (cmpxchg, cpuid). According to x86_64 psABI, we are free to use any register, so attached patch changes %rbx with %r15 (also following the example in the psABI). This patch has no implications on small code model (that doesn't use REAL_PIC_OFFSET_TABLE_REGNUM anyway), but on medium and large code model fixes usage of cpuid.h (please see PR 55712 [1]) and avoids a pair of xchgs around cmpxchg or cpuid instructions. So everyone who worked around this and use r15 now broke. It would be probably better to just teach the register allocator to spill those registers as needed, to handle some asm() statement. Not sure how hard that would be. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64
On Monday 24 December 2012 17:26:47 Leif Ekblad wrote: In the case of cpuid, the code is hardly performance sensitive, and probably runs only at startup. An alternative solution for the broken code here is to move the result from rbx to another register, and to save/restore rbx. Currently, this is the only place in libgcc and newlib affected by this problem. it's not a question of performance. i can't remember how many various projects i've had to tweak the inline asm code to work with __PIC__ (either because it's going into shared library code or it's being built as a PIE). Andi's point is now we have to redo all of that work a 2nd time and handle two different cases depending on gcc version ? it'd be a _lot_ better if gcc were intelligent and end users didn't have to code crap like stuffing %ebx somewhere temporarily. -mike signature.asc Description: This is a digitally signed message part.
