Bug 49724 - [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test
Summary: [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.2
: P3 normal
Target Milestone: 4.6.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-13 01:34 UTC by John David Anglin
Modified: 2011-07-16 16:40 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-07-14 08:39:48


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2011-07-13 01:34:57 UTC
Executing on host: /mnt/gnu/gcc/objdir-test/gcc/gnatmake --GCC=/mnt/gnu/gcc/objdir-test/gcc/xgcc --GNATBIND=/mnt/gnu/gcc/objdir-test/gcc/gnatbind --GNATLINK=/mnt/gnu/gcc/objdir-test/gcc/gnatlink -cargs -B/mnt/gnu/gcc/objdir-test/gcc -largs --GCC=/mnt/gnu/gcc/objdir-test/gcc/xgcc\ -B/mnt/gnu/gcc/objdir-test/gcc\  -margs --RTS=/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libada -q -f /mnt/gnu/gc
c/gcc/gcc/testsuite/gnat.dg/socket1.adb     -lm   -o ./socket1.exe    (timeout = 300)
Executing on host: /mnt/gnu/gcc/objdir-test/gcc/gnatclean -c -q -n ./socket1   (
timeout = 300)
./socket1.ali
./socket1.oPASS: gnat.dg/socket1.adb (test for excess errors)Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gccraised GNAT.SOCKETS.HOST_ERROR : [0] Unknown errorFAIL: gnat.dg/socket1.adb execution test

Revision 176070 was ok.
Comment 1 Eric Botcazou 2011-07-14 08:39:48 UTC
Can you confirm that this also comes from Martin's patch on the 4.6 branch?
Comment 2 Eric Botcazou 2011-07-14 09:13:19 UTC
Based on Martin's comment in the other PR, I wonder whether this isn't rather a temporary failure because of a glitch on the host.  Can you reproduce it?
Comment 3 dave.anglin 2011-07-14 11:54:32 UTC
On 14-Jul-11, at 4:40 AM, ebotcazou at gcc dot gnu.org wrote:

> Can you confirm that this also comes from Martin's patch on the 4.6  
> branch?


No, it doesn't come from Martin's change.  Rather, it appears to come  
from a change to resolv.conf
that I made last weekend.  There was a problem with accessing on of  
NRC's nameservers and I
changed the lookup order.  It appears going back to previous  
configuration fixes things.  Will
recheck.

Dave
--
John David Anglin	dave.anglin@bell.net
Comment 4 John David Anglin 2011-07-16 16:40:26 UTC
Caused by incorrect name server configuration.