* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
@ 2012-10-09 18:48 ` manu at gcc dot gnu.org
2014-04-13 16:49 ` manu at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 20+ messages in thread
From: manu at gcc dot gnu.org @ 2012-10-09 18:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-10-09 18:47:33 UTC ---
Reconfirmed with revision 192154:
pr99.cc:6:30: error: call of overloaded ‘f(X<int>, X<int>)’ is ambiguous
return f(X<int>(), X<int>());
^
pr99.cc:6:30: note: candidates are:
pr99.cc:2:26: note: int f(X<int>, X<Q>) [with Q = int]
template<typename Q> int f(X<int>, X<Q>);
^
pr99.cc:3:26: note: int f(X<Q>, X<int>) [with B = int]
template<typename B> int f(X<B>, X<int>);
^
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
2012-10-09 18:48 ` manu at gcc dot gnu.org
@ 2014-04-13 16:49 ` manu at gcc dot gnu.org
2014-04-13 18:09 ` manu at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 20+ messages in thread
From: manu at gcc dot gnu.org @ 2014-04-13 16:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Wolfgang Bangerth from comment #11)
> Here's another very nice example from PR 20313:
> -------------------------
> template<int j> struct s;
> template<int i> s<i>::s(int j) {}
> -------------------------
> Note that the definition of the constructor is invalid because the struct
> isn't complete. Here's what we get:
> g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
> x.cc:2: error: invalid use of undefined type ?struct s<j>?
> x.cc:1: error: declaration of ?struct s<j>?
> x.cc:2: error: template definition of non-template ?s<j>::s(int)?
>
> Note how the compiler uses the template argument 'j', although we use
> template argument 'i' in line 2!
I have been doing a bit more analysis and it is not very clear what would be
the correct output in this example. For the slightly different testcase:
template<int x> struct s;
template<int i> s<i>::s(int j) {}
GCC 4.9 prints:
/home/manuel/test1/pr99.cc:2:30: error: invalid use of incomplete type ‘struct
s<x>’
template<int i> s<i>::s(int j) {}
^
/home/manuel/test1/pr99.cc:1:24: error: declaration of ‘struct s<x>’
template<int x> struct s;
^
If we do this change:
Index: pt.c
===================================================================
--- pt.c (revision 209347)
+++ pt.c (working copy)
@@ -7574,10 +7574,11 @@ lookup_template_class_1 (tree d1, tree a
class, however, such a reference is an instantiation. */
if ((entering_scope
|| !PRIMARY_TEMPLATE_P (gen_tmpl)
|| currently_open_class (template_type))
/* comp_template_args is expensive, check it last. */
+ && false
&& comp_template_args (TYPE_TI_ARGS (template_type),
arglist))
return template_type;
/* If we already have this specialization, return it. */
then it prints:
/home/manuel/test1/pr99.cc:2:30: error: invalid use of incomplete type ‘struct
s<i>’
template<int i> s<i>::s(int j) {}
^
/home/manuel/test1/pr99.cc:1:24: error: declaration of ‘struct s<i>’
template<int x> struct s;
^
I am not sure one output is better than the other.
>From gcc-bugs-return-448920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 13 17:46:21 2014
Return-Path: <gcc-bugs-return-448920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28261 invoked by alias); 13 Apr 2014 17:46:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28229 invoked by uid 48); 13 Apr 2014 17:46:15 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
Date: Sun, 13 Apr 2014 17:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.6.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-50459-4-E0ym6cFR3u@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00940.txt.bz2
Content-length: 1155
http://gcc.gnu.org/bugzilla/show_bug.cgi?idP459
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The problem on the C side of things is that the values of the enum are
represented by CONST_DECL nodes and check_user_alignment doesn't look through
it. So maybe something like the following? (Tested x86_64-linux, no
regressions.)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 1d56bc0..d70ca3d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -7418,6 +7418,13 @@ check_user_alignment (const_tree align, bool allow_zero)
{
int i;
+ if (TREE_CODE (align) == IDENTIFIER_NODE)
+ {
+ tree t = lookup_name (CONST_CAST_TREE (align));
+ if (t && TREE_CODE (t) == CONST_DECL)
+ align = DECL_INITIAL (t);
+ }
+
if (TREE_CODE (align) != INTEGER_CST
|| !INTEGRAL_TYPE_P (TREE_TYPE (align)))
{
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
2012-10-09 18:48 ` manu at gcc dot gnu.org
2014-04-13 16:49 ` manu at gcc dot gnu.org
@ 2014-04-13 18:09 ` manu at gcc dot gnu.org
2014-04-13 19:25 ` manu at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 20+ messages in thread
From: manu at gcc dot gnu.org @ 2014-04-13 18:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo.carlini at oracle dot com
--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Christian Ehrhardt from comment #5)
> From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
> To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, carlo@alinoe.com,
> gdr@gcc.gnu.org, gcc-prs@gcc.gnu.org, martin@loewis.home.cs.tu-berlin.de
> Cc:
> Subject: Re: c++/99: [2003-03-26] Bug in type in error message.
> Date: Tue, 6 May 2003 15:04:23 +0200
>
> Here's a further reduced testcase, along with some more analysis:
>
> template<typename S> class X {};
> template<typename Q> int f(X<int>, X<Q>);
> template<typename B> int f(X<B>, X<int>);
>
> int main(void) {
> return f(X<int>(), X<int>());
> }
>
For this testcase, the problem is that:
(gdb) p debug_tree(arglist)
<tree_vec 0x7ffff7570d40
elt 0 <template_type_parm 0x7ffff7566348 Q VOID
align 8 symtab 0 alias set -1 canonical type 0x7ffff7566150
index 0 level 1 orig_level 1
chain <type_decl 0x7ffff755fc38 Q>>>
and
(gdb) p debug_tree(arglist)
<tree_vec 0x7ffff7570e60
elt 0 <template_type_parm 0x7ffff7566690 B VOID
align 8 symtab 0 alias set -1 canonical type 0x7ffff7566150
index 0 level 1 orig_level 1
chain <type_decl 0x7ffff755ff18 B>>>
have the same hash:
(gdb) p hash
$128 = 3284467468
I am not sure whether we should change the hashing function or whether we
should add some additional check. But what kind of check?
>From gcc-bugs-return-448922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 13 18:19:29 2014
Return-Path: <gcc-bugs-return-448922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13549 invoked by alias); 13 Apr 2014 18:19:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13527 invoked by uid 48); 13 Apr 2014 18:19:25 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/53063] encode group options in the .opt files
Date: Sun, 13 Apr 2014 18:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-53063-4-ALMz4i5gQy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53063-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53063-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00942.txt.bz2
Content-length: 1432
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-04-13
Ever confirmed|0 |1
--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
In order to fully fix this, we would need to handle also CPP options, in order
to auto-generate this code:
/* Wlong-long is disabled by default. It is enabled by:
[-Wpedantic | -Wtraditional] -std=[gnu|c]++98 ; or
[-Wpedantic | -Wtraditional] -std=non-c99 .
Either -Wlong-long or -Wno-long-long override any other settings. */
if (warn_long_long == -1)
warn_long_long = ((pedantic || warn_traditional)
&& (c_dialect_cxx () ? cxx_dialect == cxx98 :
!flag_isoc99));
cpp_opts->cpp_warn_long_long = warn_long_long;
/* Similarly with -Wno-variadic-macros. No check for c99 here, since
this also turns off warnings about GCCs extension. */
cpp_opts->warn_variadic_macros
= cpp_warn_variadic_macros && (pedantic || warn_traditional);
There also a few options in c_common_post_options that have not been converted
to the new mechanism yet.
>From gcc-bugs-return-448923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 13 19:11:57 2014
Return-Path: <gcc-bugs-return-448923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3428 invoked by alias); 13 Apr 2014 19:11:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3373 invoked by uid 48); 13 Apr 2014 19:11:48 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60834] New: [OOP] ICE with ASSOCIATE construct (gimplify_var_or_parm_decl, at gimplify.c:1721)
Date: Sun, 13 Apr 2014 19:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-60834-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00943.txt.bz2
Content-length: 983
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`834
Bug ID: 60834
Summary: [OOP] ICE with ASSOCIATE construct
(gimplify_var_or_parm_decl, at gimplify.c:1721)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
The following code ICEs with -O1 but not with -O0:
module m
implicit none
type :: t
real :: diffusion=1.
end type
contains
subroutine solve(this, x)
class(t), intent(in) :: this
real, intent(in) :: x(:)
integer :: i
integer, parameter :: n(1:5)=[(i,i=1, 5)]
associate( nu=>this%diffusion)
associate( exponential=>exp(-(x(i)-n) ))
do i = 1, size(x)
end do
end associate
end associate
end subroutine solve
end module m
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-04-13 18:09 ` manu at gcc dot gnu.org
@ 2014-04-13 19:25 ` manu at gcc dot gnu.org
2021-09-06 6:14 ` pinskia at gcc dot gnu.org
2021-10-01 10:06 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 20+ messages in thread
From: manu at gcc dot gnu.org @ 2014-04-13 19:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dodji at gcc dot gnu.org
--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #21)
> (In reply to Christian Ehrhardt from comment #5)
> > From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
> > To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, carlo@alinoe.com,
> > gdr@gcc.gnu.org, gcc-prs@gcc.gnu.org, martin@loewis.home.cs.tu-berlin.de
> > Cc:
> > Subject: Re: c++/99: [2003-03-26] Bug in type in error message.
> > Date: Tue, 6 May 2003 15:04:23 +0200
> >
> > Here's a further reduced testcase, along with some more analysis:
> >
> > template<typename S> class X {};
> > template<typename Q> int f(X<int>, X<Q>);
> > template<typename B> int f(X<B>, X<int>);
> >
> > int main(void) {
> > return f(X<int>(), X<int>());
> > }
> >
>
> For this testcase, the problem is that:
>
> (gdb) p debug_tree(arglist)
> <tree_vec 0x7ffff7570d40
> elt 0 <template_type_parm 0x7ffff7566348 Q VOID
> align 8 symtab 0 alias set -1 canonical type 0x7ffff7566150
> index 0 level 1 orig_level 1
> chain <type_decl 0x7ffff755fc38 Q>>>
>
> and
>
> (gdb) p debug_tree(arglist)
> <tree_vec 0x7ffff7570e60
> elt 0 <template_type_parm 0x7ffff7566690 B VOID
> align 8 symtab 0 alias set -1 canonical type 0x7ffff7566150
> index 0 level 1 orig_level 1
> chain <type_decl 0x7ffff755ff18 B>>>
>
> have the same hash:
>
> (gdb) p hash
> $128 = 3284467468
>
> I am not sure whether we should change the hashing function or whether we
> should add some additional check. But what kind of check?
And this triggers also with simple typedefs:
template<typename S> class X {};
template<typename Q> int f(X<int>, X<Q>);
template<typename B> int f(X<B>, X<myint>);
int foo(void) {
return f(X<int>(), X<int>());
}
gives:
/home/manuel/test1/pr99.cc:8:30: error: call of overloaded ‘f(X<int>, X<int>)’
is ambiguous
return f(X<int>(), X<int>());
^
/home/manuel/test1/pr99.cc:8:30: note: candidates are:
/home/manuel/test1/pr99.cc:4:26: note: int f(X<int>, X<Q>) [with Q = int]
template<typename Q> int f(X<int>, X<Q>);
^
/home/manuel/test1/pr99.cc:5:26: note: int f(X<Q>, X<int>) [with B = int]
template<typename B> int f(X<B>, X<myint>);
^
Perhaps the only solution is to not pretty-print the candidates, which is
exactly what clang does:
pr99.cc:8:10: error: call to 'f' is ambiguous
return f(X<int>(), X<int>());
^
pr99.cc:4:26: note: candidate function [with Q = int]
template<typename Q> int f(X<int>, X<Q>);
^
pr99.cc:5:26: note: candidate function [with B = int]
template<typename B> int f(X<B>, X<myint>);
^
Dodji, as the diagnostics maintainer, would that be an acceptable fix?
>From gcc-bugs-return-448926-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 13 19:28:00 2014
Return-Path: <gcc-bugs-return-448926-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10829 invoked by alias); 13 Apr 2014 19:28:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10780 invoked by uid 48); 13 Apr 2014 19:27:54 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
Date: Sun, 13 Apr 2014 19:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.6.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50459-4-zh5Ylx56BN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00946.txt.bz2
Content-length: 517
http://gcc.gnu.org/bugzilla/show_bug.cgi?idP459
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #1)
> The problem on the C side of things is that the values of the enum are
> represented by CONST_DECL nodes and check_user_alignment doesn't look
> through it. So maybe something like the following? (Tested x86_64-linux,
> no regressions.)
Note that the problem is not restricted to this attribute, it affects all
attributes taking an integral parameter.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-04-13 19:25 ` manu at gcc dot gnu.org
@ 2021-09-06 6:14 ` pinskia at gcc dot gnu.org
2021-10-01 10:06 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-06 6:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2010-06-05 23:38:41 |2021-9-5
--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Still here:
<source>:20:21: error: call of overloaded 'ch(dummy<0>, dummy<0>)' is ambiguous
20 | return 0.5 * ch(dummy<n - 1>(), dummy<0>());
| ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:10:11: note: candidate: 'double ch(dummy<n>, dummy<m>) [with unsigned
int n = 0; unsigned int m = 0]'
10 | double ch(dummy<n>, dummy<m>)
| ^~
<source>:18:11: note: candidate: 'double ch(dummy<n>, dummy<0>) [with unsigned
int n = 0]'
18 | double ch(dummy<n>, dummy<0>)
| ^~
<source>:24:11: note: candidate: 'double ch(dummy<0>, dummy<n>) [with unsigned
int m = 0]'
24 | double ch(dummy<0>, dummy<m>)
| ^~
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/99] Bug in template type in error message.
[not found] <bug-99-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-09-06 6:14 ` pinskia at gcc dot gnu.org
@ 2021-10-01 10:06 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 20+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-10-01 10:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org,
| |egallager at gcc dot gnu.org
--- Comment #24 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #22)
> Perhaps the only solution is to not pretty-print the candidates, which is
> exactly what clang does:
>
> pr99.cc:8:10: error: call to 'f' is ambiguous
> return f(X<int>(), X<int>());
> ^
> pr99.cc:4:26: note: candidate function [with Q = int]
> template<typename Q> int f(X<int>, X<Q>);
> ^
> pr99.cc:5:26: note: candidate function [with B = int]
> template<typename B> int f(X<B>, X<myint>);
> ^
>
> Dodji, as the diagnostics maintainer, would that be an acceptable fix?
While Dodji is still technically listed as a diagnostics maintainer, David
Malcolm has been more active as such lately, so I'm cc-ing him, too, to ask
him...
^ permalink raw reply [flat|nested] 20+ messages in thread