From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27524 invoked by alias); 1 Jun 2002 22:46:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 27465 invoked by uid 71); 1 Jun 2002 22:46:01 -0000 Resent-Date: 1 Jun 2002 22:46:01 -0000 Resent-Message-ID: <20020601224601.27464.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, Ian Jackson Resent-Reply-To: gcc-gnats@gcc.gnu.org, 12253@bugs.debian.org Received:(qmail 27023 invoked from network); 1 Jun 2002 22:41:50 -0000 Received: from unknown (HELO hirsch.in-berlin.de) (192.109.42.6) by sources.redhat.com with SMTP; 1 Jun 2002 22:41:50 -0000 Received: from gate.local (mail@dsl-213-023-043-164.arcor-ip.net [213.23.43.164]) by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with ESMTP id g51MNhFR008884; Sun, 2 Jun 2002 00:23:43 +0200 Received: from doko by gate.local with local (Exim 3.35 #1 (Debian)) id 17EHF4-0007BQ-00; Sun, 02 Jun 2002 00:20:58 +0200 Message-Id: Date: Sat, 01 Jun 2002 15:46:00 -0000 From: Matthias Klose Reply-To: 12253@bugs.debian.org To: gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org X-Send-Pr-Version:3.113 X-GNATS-Notify:Ian Jackson Subject: c/6904: GCC attribute syntax X-SW-Source: 2002-06/txt/msg00022.txt.bz2 List-Id: >Number: 6904 >Category: c >Synopsis: GCC attribute syntax >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Sat Jun 01 15:46:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Ian Jackson >Release: 3.1 (Debian) (Debian unstable) >Organization: The Debian Project >Environment: System: Debian GNU/Linux (unstable) Architecture: i686 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii gcc-3.1 3.1-2 The GNU C compiler. ii binutils 2.12.90.0.7-1 The GNU assembler, linker and binary utiliti ii libc6 2.2.5-6 GNU C Library: Shared libraries and Timezone host: i386-linux configured with: /mnt/data/gcc-3.1/gcc-3.1-3.1ds2/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=$\(prefix\)/share/man --infodir=$\(prefix\)/share/info --with-gxx-include-dir=$\(prefix\)/include/g++-v3-3.1 --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --enable-clocale=gnu --enable-threads=posix --enable-java-gc=boehm --enable-objc-gc i386-linux >Description: [ Reported to the Debian BTS as report #12253. Please CC 12253@bugs.debian.org on replies. Log of report can be found at http://bugs.debian.org/12253 ] [ The documentation has been updated: http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01683.html The "obvious" syntax isn't accepted. ] The function __attribute__((...)) extension in GCC is very useful. However, it has something of a niggle in its use. If the relevant declaration of a function is also its definition then you cannot use __attribute__ in the way suggested by the examples in the GCC manual; GCC rejects the `obvious' usage with a syntax error. The manual does not give a formal definition of where function attributes may appear, but the examples are all like int square (int) __attribute__ ((const)); suggesting that in a definition it should appear between the argument list and the opening brace. However, GCC does not accept that syntax. Experimenting shows that it _does_ accept a syntax where the attributes appear immediately before the function name (at least for functions with return values not of a pointer type). I think it would be useful to accept the `obvious' syntax (e.g., u.c in my transcript below). I also think the syntax which is accepted should be specified; in particular, the locations where the __attribute__ may appear should be specified. Thanks, Ian. -davenant:~/junk> cat t.c static void f(void) __attribute__((noreturn)); static void f(void) { } -davenant:~/junk> gcc -Wall -O3 -c t.c t.c: In function `f': t.c:2: warning: `noreturn' function does return -davenant:~/junk> cat u.c static void f(void) __attribute__((noreturn)) { } -davenant:~/junk> gcc -Wall -O3 -c u.c u.c:1: parse error before `{' u.c:1: warning: `f' declared `static' but never defined -davenant:~/junk> cat v.c static void __attribute__((noreturn)) f(void) { } -davenant:~/junk> gcc -Wall -O3 -c v.c v.c: In function `f': v.c:1: warning: `noreturn' function does return -davenant:~/junk> >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: