The following source code, extracted from FTensor, is rejected by gcc 3.1. KCC supports this feature, an array of restricted pointers. Is this a gcc flaw or a KCC extension? Release: 3.1 20020418 (prerelease) Environment: System: Linux kiste 2.4.18 #8 Sat Mar 9 15:33:15 CET 2002 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc How-To-Repeat: source code restrict.C struct A { int* __restrict__ data[10]; }; g++ -v -c restrict.C -W -Wall Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc Thread model: posix gcc version 3.1 20020418 (prerelease) GNU CPP version 3.1 20020418 (prerelease) (cpplib) (i386 Linux/ELF) GNU C++ version 3.1 20020418 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.1 20020418 (prerelease). ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include/g++-v3 /usr/local/include/g++-v3/i686-pc-linux-gnu /usr/local/include/g++-v3/backward /usr/local/include /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include /usr/include End of search list. restrict.C:3: `__restrict' qualifiers cannot be applied to `int*[10]' restrict.C:3: invalid use of `restrict'
From: Daniel Berlin <dberlin@dberlin.org> To: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de> Cc: gcc-gnats@gcc.gnu.org, <nobody@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org> Subject: Re: c++/6392: Problems with __restrict__ type qualifier (array) Date: Sun, 21 Apr 2002 17:44:17 -0400 (EDT) It's a gcc flaw. I analyzed this and asked what the right approach to fixing it was. No response. See http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00147.html On Sun, 21 Apr 2002, Peter Schmid wrote: > > >Number: 6392 > >Category: c++ > >Synopsis: Problems with __restrict__ type qualifier (array) > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: unassigned > >State: open > >Class: rejects-legal > >Submitter-Id: net > >Arrival-Date: Sun Apr 21 06:16:00 PDT 2002 > >Closed-Date: > >Last-Modified: > >Originator: Peter Schmid > >Release: 3.1 20020418 (prerelease) > >Organization: > TU Darmstadt > >Environment: > System: Linux kiste 2.4.18 #8 Sat Mar 9 15:33:15 CET 2002 i686 unknown > Architecture: i686 > host: i686-pc-linux-gnu > build: i686-pc-linux-gnu > target: i686-pc-linux-gnu > configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc > >Description: > The following source code, extracted from FTensor, is rejected by gcc > 3.1. KCC supports this feature, an array of restricted pointers. Is > this a gcc flaw or a KCC extension? > > >How-To-Repeat: > source code restrict.C > > struct A > { > int* __restrict__ data[10]; > }; > > g++ -v -c restrict.C -W -Wall > Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs > Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc > Thread model: posix > gcc version 3.1 20020418 (prerelease) > GNU CPP version 3.1 20020418 (prerelease) (cpplib) (i386 Linux/ELF) > GNU C++ version 3.1 20020418 (prerelease) (i686-pc-linux-gnu) > compiled by GNU C version 3.1 20020418 (prerelease). > ignoring nonexistent directory "NONE/include" > ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include/g++-v3 > /usr/local/include/g++-v3/i686-pc-linux-gnu > /usr/local/include/g++-v3/backward > /usr/local/include > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include > /usr/include > End of search list. > restrict.C:3: `__restrict' qualifiers cannot be applied to `int*[10]' > restrict.C:3: invalid use of `restrict' > > >Fix: > > >Release-Note: > >Audit-Trail: > >Unformatted: >
State-Changed-From-To: open->analyzed State-Changed-Why: confirmed.
Responsible-Changed-From-To: unassigned->jason Responsible-Changed-Why: got it
From: Jason Merrill <jason@redhat.com> To: gcc-bugs@gcc.gnu.org, Daniel Berlin <dberlin@dberlin.org> Cc: schmid@snake.iap.physik.tu-darmstadt.de, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: c++/6392: [PATCH] Problems with __restrict__ type qualifier (array) Date: Fri, 03 May 2002 17:21:16 +0100 --=-=-= This seems like the right fix; there's no reason to apply the bizarre array cv-qual handling to restrict. Tested i686-pc-linux-gnu, applied trunk only. I put Daniel's test in g++.dg/template/restrict1.C. 2002-05-03 Jason Merrill <jason@redhat.com> * tree.c (build_cplus_array_type): Only const and volatile get special handling. --=-=-= Content-Type: text/x-patch Content-Disposition: inline *** tree.c.~1~ Fri May 3 13:15:44 2002 --- tree.c Thu May 2 17:01:44 2002 *************** build_cplus_array_type (elt_type, index_ *** 495,508 **** { tree t; int type_quals = cp_type_quals (elt_type); ! if (type_quals != TYPE_UNQUALIFIED) ! elt_type = cp_build_qualified_type (elt_type, TYPE_UNQUALIFIED); t = build_cplus_array_type_1 (elt_type, index_type); ! if (type_quals != TYPE_UNQUALIFIED) ! t = cp_build_qualified_type (t, type_quals); return t; } --- 495,510 ---- { tree t; int type_quals = cp_type_quals (elt_type); + int cv_quals = type_quals & (TYPE_QUAL_CONST|TYPE_QUAL_VOLATILE); + int other_quals = type_quals & ~(TYPE_QUAL_CONST|TYPE_QUAL_VOLATILE); ! if (cv_quals) ! elt_type = cp_build_qualified_type (elt_type, other_quals); t = build_cplus_array_type_1 (elt_type, index_type); ! if (cv_quals) ! t = cp_build_qualified_type (t, cv_quals); return t; } --=-=-=--
State-Changed-From-To: analyzed->feedback State-Changed-Why: Jason, you had a patch that was also applied to CVS, but the code still doesn't compile. The error message used to be x.cc:3: `int*[10]' cannot be `restrict'-qualified x.cc:3: invalid use of `restrict' but the first line is now missing. I don't know what the expected behavior, but either a) this is expected behavior, in which case the report should be closed, or b) this has been broken again in the meantime. Can you take a look? Thanks Wolfgang
Should not be in waiting as it is analysised and confirmed as a bug on the mainline already and the waiting use is only for waiting for response from the submitter and this is waiting from a developer.
Subject: Bug 6392 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2003-10-09 08:38:46 Modified files: gcc : ChangeLog c-common.c gcc/cp : ChangeLog tree.c Log message: PR c++/6392 * cp/tree.c (build_cplus_array_type): Handle all quals the same. (cp_build_qualified_type_real): Look through arrays first. * c-common.c (c_build_qualified_type): Look through arrays first. (c_apply_type_quals_to_decl): Look through arrays. * c-common.c (c_apply_type_quals_to_decl): Unset TREE_READONLY for types with constructors. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1346&r2=2.1347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&r1=1.461&r2=1.462 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3721&r2=1.3722 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.349&r2=1.350
Subject: Bug 6392 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2003-10-09 08:39:34 Added files: gcc/testsuite/g++.dg/ext: restrict1.C Log message: PR c++/6392 * cp/tree.c (build_cplus_array_type): Handle all quals the same. (cp_build_qualified_type_real): Look through arrays first. * c-common.c (c_build_qualified_type): Look through arrays first. (c_apply_type_quals_to_decl): Look through arrays. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/restrict1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Now only causes pessimizes-code.
I think we should just close this PR. In comment #9 Andrew suggests that this should be a pessimizes-code, but there is no test case for that and no reason to think that we do pessimize the code. If there is some problem with the implementation of an array of restrict qualified elements, I think we should put that in a new PR with a test case.
(In reply to comment #10) There is a fixme in the code right now: /* Allow 'restrict' on arrays of pointers. FIXME currently we just ignore it. */
Closing the rejects-valid bug, will open a new missed-optimization bug.