public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/57671] New: Compile Error: When  declared a pointer const TYPE const *p ; (p is name of pointer)
@ 2013-06-21 15:36 vlad94009277 at gmail dot com
  2013-06-21 16:09 ` [Bug c++/57671] " schwab@linux-m68k.org
  0 siblings, 1 reply; 2+ messages in thread
From: vlad94009277 at gmail dot com @ 2013-06-21 15:36 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57671

            Bug ID: 57671
           Summary: Compile Error: When  declared a pointer const TYPE
                    const *p ; (p is name of pointer)
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vlad94009277 at gmail dot com

Compile Error: When declared the pointer const int const *p ;

Actual result:
               error: duplicate ‘const’
               const int const *p ;

expected result: 
               Must be declared the pointer p:
>From gcc-bugs-return-424795-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 21 15:40:05 2013
Return-Path: <gcc-bugs-return-424795-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12107 invoked by alias); 21 Jun 2013 15:40:05 -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 11524 invoked by uid 48); 21 Jun 2013 15:40:00 -0000
From: "pebbles at riseup dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
Date: Fri, 21 Jun 2013 15:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: pebbles at riseup dot net
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57631-4-5zR0yp2IsI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57631-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57631-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: 2013-06/txt/msg01174.txt.bz2
Content-length: 3552

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW631

--- Comment #6 from pebbles at riseup dot net ---
You seem to be speaking from an assumption that this warning code should not
change.  Is there a reason for not adding this small patch, which makes gcc
more extendable and accurate?

(In reply to Georg-Johann Lay from comment #5)
> The ISR macro is defined by AVR-LibC. It adds extern "C" to ISR if compiled
> for C++.  Thus, the handlers are not mangled and names like __vector_<num>
> are used even if compiled for C++.
>
> Moreover, you should not use __vector_<num> firectly, use the support macros
> from avr/io.h and avr/interrupt.h.  They work for C++.  If not, please file
> a bug report against AVR-LibC.

extern "C" does not work inside a class.  I'm glad to file a bug report with
AVR-LibC for this, but generally it is not expected that C macros work inside
classes.  The signal and interrupt attributes are described in the gcc
attribute documentation.  I would like to use them.

I am trying to create a way for unknown code using my library to define event
handlers.  It's true, I can handle this "at runtime" by calling back to them
from for example INT0_vect, relying on GCC to inline the call if it is known at
compile time.  If it is indeed known, it is more efficient and brings the user
closer to the hardware to call it straight from the interrupt vector table,
which can only be set up by the linker.

Right now gcc restricts my interface specification in such a way that if I
allow code to define a static event handler, and I want it to be an interrupt
in the interrupt vector table, it must be named __vectorABC or declared with
ISR(ABC_vect) and be file scoped.

If things become more complex and this static event handler will be called from
inside another interrupt handler, the ISR(ABC_vect) convention will no longer
work; the interface specification and all code must be updated.  If I can give
the handler a non-AVR-LibC name, then all that needs to change is the attribute
in the header file.  Code becomes maintainable, and self-documenting too.

I can do this right now, gcc just issues a warning if that name does not start
with __vector.

I do really appreciate as many alternative solutions as there are, but I am
actually going to do this, warning or no, because I am trying to both
accurately represent the hardware and abstract it.

> >> You can name the function __vectorFOO or __vector_my_ISR_function or
> >> whatever without raising a warning.
> >
> > But that requires reading the source of GCC, which I have begun doing but is
> > usually not a prerequisite for coding.  The warning should tell me that
> > straight out.
>
> You should read the documentation of AVR-LibC, of course.  You can add
> documentation parts to the GCC documentation if you find it helpful.
> However, users typically read the AVR-LibC manual because ISR and the vector
> names are supplyied by AVR-LibC's av/io.h and avr/interrupt.h.

As you state earlier, AVR-LibC does not intend us to be aware of the
__vector_NN naming convention; I don't believe it's mentioned in the docs.
Solving my problem by artificially prefixing my function names with __vector,
which works but restricts what I can name them in an unpleasant way, involves
finding the warning check in the GCC source to understand that that is a
solution.

This seems like a very small patch that makes GCC more extendable and accurate.
 I am not too attached to these things changing, although I am curious what the
reason is for not considering the patch.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug c++/57671] Compile Error: When  declared a pointer const TYPE const *p ; (p is name of pointer)
  2013-06-21 15:36 [Bug c++/57671] New: Compile Error: When declared a pointer const TYPE const *p ; (p is name of pointer) vlad94009277 at gmail dot com
@ 2013-06-21 16:09 ` schwab@linux-m68k.org
  0 siblings, 0 replies; 2+ messages in thread
From: schwab@linux-m68k.org @ 2013-06-21 16:09 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57671

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
           Severity|blocker                     |normal

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Unlike C, C++ does not allow to directly specify a cv-qualifier twice.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-06-21 16:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-21 15:36 [Bug c++/57671] New: Compile Error: When declared a pointer const TYPE const *p ; (p is name of pointer) vlad94009277 at gmail dot com
2013-06-21 16:09 ` [Bug c++/57671] " schwab@linux-m68k.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).