From patchwork Tue Apr 21 13:14:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Georg-Johann Lay X-Patchwork-Id: 463124 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 97D621400A0 for ; Tue, 21 Apr 2015 23:14:54 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=AVLze1s8; dkim-adsp=none (unprotected policy); dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=dksdtpRPGmw7VR55Y A0VOSjIX7TFp+ZqoVhJXwuDveaQKQf+0aFLTkwcJuhvUzP4s4PEYb/XFElcWH4HW bZndjJe71BJD+uBY6jAjaquvvhGp9qgVNnkEeWIZU0WJryJgvm6o92aW9wrTlE0i x6qk/9hlFsv74EXubkK90rvokE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=qZT1xE45ySqiHZHOmCQ/lpv ohks=; b=AVLze1s8upDginQ9nh5LySAIFMHkoiHbc/6WeMBYvlXTcfIfa2qqfDt YB6azqYrNgKOG7JO2ZsYXkMnhXM/OQJcfwGHp5Hyma8ykvyiaQ0TcG4tYdNOcpSD tOfD5SnSu/lPTrbXOK/S8D0C3HPfe8sZoa/nx8LQQK1axAeWJiZM= Received: (qmail 45275 invoked by alias); 21 Apr 2015 13:14:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 45260 invoked by uid 89); 21 Apr 2015 13:14:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mo4-p00-ob.smtp.rzone.de Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (81.169.146.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 21 Apr 2015 13:14:42 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT3ol15ykJcYwTPbBBR62PQx1xqvTHw== X-RZG-CLASS-ID: mo00 Received: from [192.168.0.22] (ip5b43a95f.dynamic.kabel-deutschland.de [91.67.169.95]) by smtp.strato.de (RZmta 37.5 DYNA|AUTH) with ESMTPSA id 200e2ar3LDEbFRF (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 21 Apr 2015 15:14:37 +0200 (CEST) Message-ID: <55364D3D.6040108@gjlay.de> Date: Tue, 21 Apr 2015 15:14:37 +0200 From: Georg-Johann Lay User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gerald Pfeifer CC: gcc-patches@gcc.gnu.org, Denis Chertykov Subject: Re: [patch,wwwdocs] Add gcc-5 caveats for avr. References: <5534D76F.2060503@gjlay.de> In-Reply-To: X-IsSubscribed: yes Am 04/20/2015 um 09:02 PM schrieb Gerald Pfeifer: > Hi Johann, > > On Mon, 20 Apr 2015, Georg-Johann Lay wrote: >> Okay to install? > > +
  • The AVR port uses a new scheme to describe supported devices: > + For each supported device the compiler provides a device-specific > + spec > file. > + If the compiler is used together with AVR-LibC, this requires at > + least GCC 5.2 and a version of AVR-LibC which implements > + #44574.
    • > > Can you please make the two links https-links? (Especially the > one to gcc.gnu.org actually redirects.) > > Just using "#44574" for a reference, may that be a little confusing, > or is it sufficiently clear to AVR users? > > +
  • A new command option -nodevicelib has been added. > > "command-line option" > > + If this option is turned on the compiler won't link against AVR-LibC's > + device-specific library libdevice.a by omitting > + -ldevice from the linker's command line. > > How about making this "...-nodevicelib prevents the compiler > from linking against...."? > > + If the compiler had not been > + configured > + to be used with AVR-LibC, the compiler will not link against that > + library and the option has no effect.
    • > > "was not" (or "is") instead of "had not", and can you please use > https here as well? > > Though, really, could this be just simplified to "If the compiler is > not configured for use with AVR-LibC to begin with, this option has no effect"? > > > Your patch is fine with the above changes or considering them and > deciding not go for one or the other. > > Gerald Thanks for your support. The new entry also contains more topics. Index: gcc-5/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.109 diff -u -p -r1.109 changes.html --- gcc-5/changes.html 20 Apr 2015 08:22:35 -0000 1.109 +++ gcc-5/changes.html 21 Apr 2015 13:00:11 -0000 @@ -28,6 +28,14 @@ is_trivially_default_constructible, is_trivially_copy_constructible and is_trivially_copy_assignable should be used instead. +
  • On AVR, support has been added for the devices ATtiny4/5/9/10/20/40. + This requires Binutils 2.25 or newer.
    • +
  • The AVR port uses a new scheme to describe supported devices: + For each supported device the compiler provides a device-specific + spec file. + If the compiler is used together with AVR-LibC, this requires at + least GCC 5.2 and a version of AVR-LibC which implements + feature #44574.

    • General Optimizer Improvements

    @@ -690,6 +698,57 @@ here.

    +

    AVR

    +
      +
    • The compiler no more supports individual devices like ATmega8. + Specifying, say, -mmcu=atmega8 triggers the usage of the + device-specific + spec file + specs-atmega8 which is part of the installation and describes + options for the sub-processes like compiler proper, assembler and linker. + You can add support for a new device -mmcu=mydevice as follows: +
        +
      1. In an empty directory /someplace, create a new + directory device-specs.
        2. +
      2. Copy a device spec file from the installed device-specs + folder, follow the comments in that file and then save it as + /someplace/device-specs/specs-mydevice. +
      3. Add -B /someplace -mmcu=mydevice to the + compiler's command-line options. Notice that /someplace + must specify an absolute path and that mydevice must + not start with "avr".
        4. +
      4. Provided you have a device-specific library + libmydevice.a available, you can put it at + /someplace, dito for a device-specific startup + file crtmydevice.o.
        5. +
      + The contents of the device spec files depend on the compiler's + configuration, in particular on --with-avrlibc=no and + whether or not it is configured for RTEMS. +
      • +
    • A new command-line option -nodevicelib has been added. + It prevents the compiler from linking against AVR-LibC's + device-specific library libdevice.a.
      • +
    • The following three command-line options have been added: +
      +
      -mrmw
      +
      Set if the device supports the read-modify-write instructions + LAC, LAS, LAT + and XCH.
      +
      -mn-flash=size
      +
      Specify the flash size of the device in units of 64 KiB, + rounded up to the next integer as needed. This option affects the + availability of the + AVR + address-spaces.
      +
      -mskip-bug
      +
      Set if the device is affected by the respective silicon bug.
      +
      + In general, you don't need to set these options by hand. The new + device-specific spec file will set them as needed. +
      • +
    +

    IA-32/x86-64

    • New ISA extensions support