[Bug ada/66525] New: Implicit function declarations

[Bug ada/66525] New: Implicit function declarations

[pini_os at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66525

            Bug ID: 66525
           Summary: Implicit function declarations
           Product: gcc
           Version: 4.7.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pini_os at yahoo dot fr
  Target Milestone: ---

Compiling the Ada frontend with -Wimplicit-function-declaration on x86_64
reports the following warnings:

gcc/ada/cal.c:108:3: warning: implicit declaration of function ‘time’
-> include should be on time.h rather than sys/time.h

gcc/ada/socket.c:150:3: warning: implicit declaration of function ‘pipe’
-> include of unistd.h is missing
>From gcc-bugs-return-488899-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 12 20:08:20 2015
Return-Path: <gcc-bugs-return-488899-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28645 invoked by alias); 12 Jun 2015 20:08: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 28601 invoked by uid 48); 12 Jun 2015 20:08:17 -0000
From: "pini_os at yahoo dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/66526] New: Use of uninitialized variable
Date: Fri, 12 Jun 2015 20:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.7.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pini_os at yahoo dot fr
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66526-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: 2015-06/txt/msg01231.txt.bz2
Content-length: 1190

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66526

            Bug ID: 66526
           Summary: Use of uninitialized variable
           Product: gcc
           Version: 4.7.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pini_os at yahoo dot fr
  Target Milestone: ---

Compiling Ada frontend with -Wuninitialized reports the following warning:

gcc/ada/g-expect.adb:1338:7: warning: ‘INPUT’ is used uninitialized in this
function
gcc/ada/g-expect.adb:1339:7: warning: ‘OUTPUT’ is used uninitialized in this
function
gcc/ada/g-expect.adb:1340:7: warning: ‘ERROR’ is used uninitialized in this
function

In function ‘Set_Up_Child_Communications’, these local variables are only
initialized within the ‘if No_Fork_On_Target’ but each is used twice outside of
it.

The uses are following an execvp call, so no harm on *nix systems, but the
source is still oddly shaped. The uses of these variables should be controlled
by the same condition as their initialization.
>From gcc-bugs-return-488900-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 12 22:14:59 2015
Return-Path: <gcc-bugs-return-488900-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 80367 invoked by alias); 12 Jun 2015 22:14:59 -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 80300 invoked by uid 48); 12 Jun 2015 22:14:54 -0000
From: "wilson at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/66203] aarch64-none-elf does not automatically find librdimon
Date: Fri, 12 Jun 2015 22:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wilson at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-66203-4-gUQ7075aTH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66203-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66203-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: 2015-06/txt/msg01232.txt.bz2
Content-length: 3152

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf203

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
This is more an arm newlib bug than a gcc aarch64 bug.

Most embedded ports support more than one rom monitor.  libgloss provides more
than one set of start files and libraries for these different rom monitors.
Users are expected to supply a --specs option when linking to choose the right
support files for the rom monitor in use.  This is how the aarch64 port works.

However, arm works differently.  There is a single set of start files and
libraries provided by newlib that override libgloss.  These are compiled for
rdimon.  If you want to compile for a different rom monitor, then you either
need to add a newlib configure option --disable-newlib-supplied-syscalls or
else you need to hand edit newlib/libc/configure.host to enable a different
choice.

This was probably done to make this easier for end users.  If you make one rom
monitor the default, then they don't have to read docs to figure out how to
link.  Though this also means that by default the support for the other rom
monitors is broken unless you rebuild the toolchain.

This probably hasn't been done for aarch64 yet simply because there aren't
enough people doing bare target work for aarch64, and hence people haven't yet
noticed that the arm and aarch64 ports are working differently.

I do see a number of problems with the arm support here though.

There are two copies of the syscalls.c file, one in newlib/libc/sys/arm and one
in libgloss/arm.  It appears that they were the same file originally, but lack
of cross-maintenance means that they have accidentally diverged.  There may
also be some other files that have diverged.  I haven't checked them all.

The newlib/README file says --disable-newlib-supplied-syscalls is the default.
But the configure code makes --enable-newlib-supplied-syscalls the default.

The libgloss arm specs files could perhaps be changed to put libgloss libraries
in front of newlib libraries, which may allow alternative rom monitors to work
without rebuilding the toolchain.  I haven't tried that.  Currently, they
include -lc first and then the monitor library, which won't work unless newlib
is configured to disable the syscall support.

There is also a related problem here that some of the specs files are
redefining link spec to add -l$(monitorlib).  That causes the archive file to
be included before any input files on the link line, which means it will get
ignored.  The correct specs files are using link_gcc_c_sequence.  It is OK to
put a -T*.ld linker script file in link spec, but libraries need to go into
link_gcc_c_sequence.

And of course, arm supports this but aarch64 does not, and it seems to be
general policy that things should work similarly for the two targets.

So I count 5 inter-related newlib arm/aarch64 problems that need to be fixed.

[Bug ada/66525] Implicit function declarations

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66525

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|WAITING                     |RESOLVED

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
.