gfortran error: Statement order error: declaration after DATA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am trying to compile the cactuscode package and can not get past the error : Statement order error: declaration after DATA can you point me in the direction of a fix. I included offending file as an attachment. Dave kb9qhd Amateur Radio Service Technician class Licence Grid EN43 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQWuTeAAoJEIHvsckbl2dBYosH/RSFXD4+rz/C+Yd9Viow5hO2 f6HHhiWNT3EzUdmjddvbGaJPDdRjr/hbDElO+NmYf5eSJqMeqnpNYcLOOFaQJoWe GCyTgOz0OZ3nLmZmK0XF33FqRB6I13KAxNH+idHiXRQSNGWXMmMM/LctWst/77dZ BxFP5x8uoudjeVTr38SBCgO8ne5HF3V3G686gYKHtBwnlqR4QDQ4FCIhtYJaiVIs E0+VFtIrmYbWB9UxKTHyletEbEYQEowFm7PuyRId3QMApSYSAvSHgAgys9bXbvZJ WkeRQJL+G5i+DyAOOFtrIhNnimRLTjGwbS0kw/d8k1oaoU9jnTPjidK3KMcInlY= =/srW -END PGP SIGNATURE-
GCC 4.7.2 Released
The GNU Compiler Collection version 4.7.2 has been released. GCC 4.7.2 is the first bug-fix release containing important fixes for regressions and serious bugs in GCC 4.7.1 with over 70 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html A notable change in GCC 4.7.2 compared to 4.7.1 are ABI bug fixes related to some C++11 templates (std::list and std::pair). As a result, code using those templates in C++11 mode is again ABI compatible with code in C++03/C++98 mode or C++11 mode of GCC 4.6 and earlier, but might be ABI incompatible with code compiled by GCC 4.7.1 or 4.7.0 in C++11 mode. See http://gcc.gnu.org/gcc-4.7/changes.html for more details. Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 4.7.3 Status Report (2012-09-20)
Status == The GCC 4.7.2 release tarballs have been created and were uploaded to ftp.gnu.org. The GCC 4.7 branch is thus open again for regression and documentation fixes. Quality Data Priority # Change from Last Report --- --- P10 P2 84 + 10 P3 18 + 4 --- --- Total 102 + 14 Previous Report === http://gcc.gnu.org/ml/gcc/2012-09/msg00151.html
Compiler crash with block numbers
Hi Dehao, I suspect that your recent patch changing block handling has
broken bootstrap with --enable-languages=go. I reduced the test case
to this C++ code:
#include
std::string
f(bool is_string, bool is_constant)
{
if (is_string)
{
std::string left_string;
std::string right_string;
if (is_constant)
{
return left_string + right_string;
}
}
return "";
}
When I compile that with current mainline with -O -g I get a crash
(the backtrace is a local patch of mine):
foo.cc: In function ‘std::string f(bool, bool)’:
foo.cc:17:1: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.c:1544
}
^
0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*, ...)
../../trunk/gcc/tree.c:8892
0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3659
0x9372a1 change_scope
../../trunk/gcc/final.c:1544
0x937646 reemit_insn_block_notes
../../trunk/gcc/final.c:1613
0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
../../trunk/gcc/final.c:1670
0x93c6ad rest_of_handle_final
../../trunk/gcc/final.c:4291
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
At first glance the bug is that the block obtained from insn_scope
(insn), called from reemit_insn_block_notes, has a block number of 0.
That leads to the crash in insn_scope.
It's interesting that it only occurs with -g. I'm not sure what that means.
Could you take a look at this and see if it is due to your patch?
Thanks.
Ian
Re: Compiler crash with block numbers
Sure, I'll look into this problem today.
Thanks,
Dehao
On Fri, Sep 21, 2012 at 2:25 AM, Ian Lance Taylor wrote:
> Hi Dehao, I suspect that your recent patch changing block handling has
> broken bootstrap with --enable-languages=go. I reduced the test case
> to this C++ code:
>
> #include
>
> std::string
> f(bool is_string, bool is_constant)
> {
> if (is_string)
> {
> std::string left_string;
> std::string right_string;
> if (is_constant)
> {
> return left_string + right_string;
> }
> }
>
> return "";
> }
>
> When I compile that with current mainline with -O -g I get a crash
> (the backtrace is a local patch of mine):
>
> foo.cc: In function ‘std::string f(bool, bool)’:
> foo.cc:17:1: internal compiler error: tree check: expected block, have
> function_decl in change_scope, at final.c:1544
> }
> ^
> 0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
> ../../trunk/gcc/tree.c:8892
> 0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
> ../../trunk/gcc/tree.h:3659
> 0x9372a1 change_scope
> ../../trunk/gcc/final.c:1544
> 0x937646 reemit_insn_block_notes
> ../../trunk/gcc/final.c:1613
> 0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
> ../../trunk/gcc/final.c:1670
> 0x93c6ad rest_of_handle_final
> ../../trunk/gcc/final.c:4291
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
>
>
> At first glance the bug is that the block obtained from insn_scope
> (insn), called from reemit_insn_block_notes, has a block number of 0.
> That leads to the crash in insn_scope.
>
> It's interesting that it only occurs with -g. I'm not sure what that means.
>
> Could you take a look at this and see if it is due to your patch?
>
> Thanks.
>
> Ian
Re: Compiler crash with block numbers
On Thu, Sep 20, 2012 at 11:46 AM, Dehao Chen wrote:
> Sure, I'll look into this problem today.
>
> Thanks,
> Dehao
>
> On Fri, Sep 21, 2012 at 2:25 AM, Ian Lance Taylor wrote:
>> Hi Dehao, I suspect that your recent patch changing block handling has
>> broken bootstrap with --enable-languages=go. I reduced the test case
>> to this C++ code:
>>
>> #include
>>
>> std::string
>> f(bool is_string, bool is_constant)
>> {
>> if (is_string)
>> {
>> std::string left_string;
>> std::string right_string;
>> if (is_constant)
>> {
>> return left_string + right_string;
>> }
>> }
>>
>> return "";
>> }
>>
>> When I compile that with current mainline with -O -g I get a crash
>> (the backtrace is a local patch of mine):
>>
>> foo.cc: In function ‘std::string f(bool, bool)’:
>> foo.cc:17:1: internal compiler error: tree check: expected block, have
>> function_decl in change_scope, at final.c:1544
>> }
>> ^
>> 0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*,
>> ...)
>> ../../trunk/gcc/tree.c:8892
>> 0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
>> ../../trunk/gcc/tree.h:3659
>> 0x9372a1 change_scope
>> ../../trunk/gcc/final.c:1544
>> 0x937646 reemit_insn_block_notes
>> ../../trunk/gcc/final.c:1613
>> 0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
>> ../../trunk/gcc/final.c:1670
>> 0x93c6ad rest_of_handle_final
>> ../../trunk/gcc/final.c:4291
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See for instructions.
>>
>>
>> At first glance the bug is that the block obtained from insn_scope
>> (insn), called from reemit_insn_block_notes, has a block number of 0.
>> That leads to the crash in insn_scope.
>>
>> It's interesting that it only occurs with -g. I'm not sure what that means.
>>
>> Could you take a look at this and see if it is due to your patch?
>>
>> Thanks.
>>
>> Ian
It may also cause:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
--
H.J.
Re: Compiler crash with block numbers
The bug is in tree-eh.c. IS_UNKNOWN_LOCATION is mistakenly used, thus
the block info for a call stmt is cleared.
A patch to fix the problem is atached:
gcc/ChangeLog:
tree-eh.c (lower_try_finally_dup_block): Use correct way to
check unknown location.
Index: tree-eh.c
===
--- tree-eh.c (revision 191494)
+++ tree-eh.c (working copy)
@@ -883,7 +883,7 @@ lower_try_finally_dup_block (gimple_seq seq, struc
new_seq = copy_gimple_seq_and_replace_locals (seq);
for (gsi = gsi_start (new_seq); !gsi_end_p (gsi); gsi_next (&gsi))
-if (IS_UNKNOWN_LOCATION (gimple_location (gsi_stmt (gsi
+if (gimple_location (gsi_stmt (gsi)) == UNKNOWN_LOCATION)
gimple_set_location (gsi_stmt (gsi), loc);
if (outer_state->tf)
Is it ok for trunk?
Thanks,
Dehao
On Fri, Sep 21, 2012 at 3:47 AM, H.J. Lu wrote:
> On Thu, Sep 20, 2012 at 11:46 AM, Dehao Chen wrote:
>> Sure, I'll look into this problem today.
>>
>> Thanks,
>> Dehao
>>
>> On Fri, Sep 21, 2012 at 2:25 AM, Ian Lance Taylor wrote:
>>> Hi Dehao, I suspect that your recent patch changing block handling has
>>> broken bootstrap with --enable-languages=go. I reduced the test case
>>> to this C++ code:
>>>
>>> #include
>>>
>>> std::string
>>> f(bool is_string, bool is_constant)
>>> {
>>> if (is_string)
>>> {
>>> std::string left_string;
>>> std::string right_string;
>>> if (is_constant)
>>> {
>>> return left_string + right_string;
>>> }
>>> }
>>>
>>> return "";
>>> }
>>>
>>> When I compile that with current mainline with -O -g I get a crash
>>> (the backtrace is a local patch of mine):
>>>
>>> foo.cc: In function ‘std::string f(bool, bool)’:
>>> foo.cc:17:1: internal compiler error: tree check: expected block, have
>>> function_decl in change_scope, at final.c:1544
>>> }
>>> ^
>>> 0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*,
>>> ...)
>>> ../../trunk/gcc/tree.c:8892
>>> 0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
>>> ../../trunk/gcc/tree.h:3659
>>> 0x9372a1 change_scope
>>> ../../trunk/gcc/final.c:1544
>>> 0x937646 reemit_insn_block_notes
>>> ../../trunk/gcc/final.c:1613
>>> 0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
>>> ../../trunk/gcc/final.c:1670
>>> 0x93c6ad rest_of_handle_final
>>> ../../trunk/gcc/final.c:4291
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> Please include the complete backtrace with any bug report.
>>> See for instructions.
>>>
>>>
>>> At first glance the bug is that the block obtained from insn_scope
>>> (insn), called from reemit_insn_block_notes, has a block number of 0.
>>> That leads to the crash in insn_scope.
>>>
>>> It's interesting that it only occurs with -g. I'm not sure what that means.
>>>
>>> Could you take a look at this and see if it is due to your patch?
>>>
>>> Thanks.
>>>
>>> Ian
>
> It may also cause:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
>
> --
> H.J.
Re: Compiler crash with block numbers
On Thu, Sep 20, 2012 at 12:59 PM, Dehao Chen wrote: > The bug is in tree-eh.c. IS_UNKNOWN_LOCATION is mistakenly used, thus > the block info for a call stmt is cleared. > > A patch to fix the problem is atached: > > gcc/ChangeLog: > tree-eh.c (lower_try_finally_dup_block): Use correct way to > check unknown location. > > Index: tree-eh.c > === > --- tree-eh.c (revision 191494) > +++ tree-eh.c (working copy) > @@ -883,7 +883,7 @@ lower_try_finally_dup_block (gimple_seq seq, struc >new_seq = copy_gimple_seq_and_replace_locals (seq); > >for (gsi = gsi_start (new_seq); !gsi_end_p (gsi); gsi_next (&gsi)) > -if (IS_UNKNOWN_LOCATION (gimple_location (gsi_stmt (gsi > +if (gimple_location (gsi_stmt (gsi)) == UNKNOWN_LOCATION) >gimple_set_location (gsi_stmt (gsi), loc); > >if (outer_state->tf) > > Is it ok for trunk? Without much background on this, this seems far too error-prone. What is the difference between IS_UNKNOWN_LOCATION (x) and x == UNKNOWN_LOCATION? Where is that difference documented? How can we avoid similar errors in the future? Ian
Re: Compiler crash with block numbers
On Thu, Sep 20, 2012 at 12:59 PM, Dehao Chen wrote: > > gcc/ChangeLog: > tree-eh.c (lower_try_finally_dup_block): Use correct way to > check unknown location. While you think about my questions, let's fix the bootstrap. This patch is OK if it passes bootstrap and a gcc and libstdc++ testsuite run. If it does fix the problem in http://gcc.gnu.org/PR54645 , then please add PR rtl-optimization/54645 to the ChangeLog entry Thanks for the quick turnaround. Ian
Re: Compiler crash with block numbers
IS_UNKNOWN_LOCATION checks if the source location is unknown. == UNKNONW_LOCATION checks if source location is unknown and the block is NULL. Yes, they are error-prone, I'll have a separate patch to clean up IS_UNKNOWN_LOCATION later. On Fri, Sep 21, 2012 at 4:17 AM, Ian Lance Taylor wrote: > On Thu, Sep 20, 2012 at 12:59 PM, Dehao Chen wrote: >> >> gcc/ChangeLog: >> tree-eh.c (lower_try_finally_dup_block): Use correct way to >> check unknown location. > > While you think about my questions, let's fix the bootstrap. This > patch is OK if it passes bootstrap and a gcc and libstdc++ testsuite > run. Okay, I'll check it in if the tests are passed. Thanks, Dehao > > If it does fix the problem in http://gcc.gnu.org/PR54645 , then please add > PR rtl-optimization/54645 > to the ChangeLog entry > > Thanks for the quick turnaround. > > Ian
MELT plugin 0.9.7 release candidate 1 for GCC 4.6, 4.7 and future 4.8
Dear All,
It is my pleasure to announce the MELT plugin 0.9.7 release candidate 1
for GCC 4.6, 4.7 and future 4.8 available on
http://gcc-melt.org/melt-0.9.7-rc1-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
MELT is a high-level domain specific language to extend GCC and the
[meta-]plugin
providing it. That plugin should work with GCC-4.6, 4.7 and probably the future
version
(unreleased in september 2012) 4.7
Please read more on http://gcc-melt.org/ about MELT.
Notice that MELT is a language translated to C provding a lot of hooks to GCC.
Notice also that you can mix MELT and C code in your GCC extensions written in
MELT.
MELT is free software GPLv3+ licensed and FSF copyrighted.
It needs a GCC with plugin enabled to be usable as a plugin.
It is developped on Debian/Linux (amd64).
NEWS for 0.9.7 MELT plugin for GCC 4.6 & 4.7 & future 4.8
[[september, XXth, 2012]]
Language improvement
When creating an instance with definstance or instance, the
translator checks that fields are filled with values. Previous
versions of MELT could crash in that case.
(CHEADER ...) constructs are working as documented.
The Parma Polyhedra Library is removed from MELT.
String values know their length, so safe access to some byte inside
is possible.
Added a lot of cmatchers (and implicit primitives) like
tree_boolean_false_node, tree_boolean_true_node,
tree_boolean_type_node, tree_char_type_node,
tree_const_ptr_type_node, tree_double_type_node,
tree_float_type_node, tree_int128_integer_type_node,
tree_int128_unsigned_type_node, tree_integer_minus_one_node,
tree_integer_one_node, tree_integer_type_node,
tree_integer_zero_node, tree_long_double_type_node,
tree_long_integer_type_node, tree_long_long_integer_type_node,
tree_long_long_unsigned_type_node,
tree_long_unsigned_type_node, tree_null_pointer_node,
tree_ptr_type_node, tree_short_integer_type_node,
tree_short_unsigned_type_node, tree_signed_char_type_node,
tree_size_type_node, tree_unsigned_char_type_node,
tree_unsigned_type_node, tree_void_type_node
to access the very built-in trees known to GCC.
Added more tree & gimple related matchers and primitives.
Less spurious warnings when building MELT.
Runtime improvements
Add a runtime expression evaluation function
TRANSLATE_RUN_MELT_EXPRESSIONS with a mode eval for initial
evaluation of a sequence of expressions, and a mode repl for
read-eval-print-loop. (Works by translating these to C code and dlopen-ing
it).
The building procedure has been revamped. Advanced users could
define their GCCMELT_BUILD_NOTIFICATION environment variable to
e.g. a script meltbuild-notification like
#! /bin/bash
# first arg title, second arg message
if [ "$DISPLAY" = ":0.0" -a -n "$DESKTOP_SESSION" -a $(which notify-send)
]; then
notify-send -t 3500 -i info "MELT BUILD: $1" "$2"
else
logger -t meltbuild -p user.info "$1=" "$2"
fi
and they will have a nice bubble notification under most Linux
desktops of the major steps of the build. The building procedure is
now quicker than before.
Advanved MELT users can set their MELTGCC_NO_CHECK_RUNTIME to
disable checking of the MELT runtime. This is notably needed when
the MELT plugin is compiled for a cross compiler.
Advanced MELT users willing to debug with gdb could set the
melt_alptr_1 and melt_objhash_1 in their gdb debugger to track
allocation or changes of MELT values or objects.
The -fmelt-debugging=all option works as expected in the MELT branch
and so does -fplugin-arg-melt-debugging=all in the MELT plugin.
Numerous bug fixes. The probe has still naughty behavior on large C
source. Consider using Alexandre Lissy's replacement (Python/Qt
based) of the probe.
Your comments and bug reports (and build successes) about this MELT 0.9.7 rc1
are welcome
on gcc-m...@googlegroups.com
You can download the MELT .9.7 rc1 plugin for GCC 4.6, 4.7 and future 4.8 on
http://gcc-melt.org/melt-0.9.7-rc1-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
a Gnu-zipped tar source archive of 5145526 bytes of md5sum
000b7b84772e6b85f178e8a23b906797
extracted from the MELT branch of GCC svn rev. 191572 on september 20th 2012
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Compiler crash with block numbers
Hi, Ian, This patch fixed the bootstrap problem, as well as the problem posted in http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01441.html However, the libstdc++ problem is not fixed, they are related to the my line_table implementation for PCH. I'll send another patch later for that. Shall I still check in this patch to fix the bootstrap problem? Thanks, Dehao On Fri, Sep 21, 2012 at 4:30 AM, Dehao Chen wrote: > IS_UNKNOWN_LOCATION checks if the source location is unknown. > == UNKNONW_LOCATION checks if source location is unknown and the block is > NULL. > > Yes, they are error-prone, I'll have a separate patch to clean up > IS_UNKNOWN_LOCATION later. > > On Fri, Sep 21, 2012 at 4:17 AM, Ian Lance Taylor wrote: >> On Thu, Sep 20, 2012 at 12:59 PM, Dehao Chen wrote: >>> >>> gcc/ChangeLog: >>> tree-eh.c (lower_try_finally_dup_block): Use correct way to >>> check unknown location. >> >> While you think about my questions, let's fix the bootstrap. This >> patch is OK if it passes bootstrap and a gcc and libstdc++ testsuite >> run. > > Okay, I'll check it in if the tests are passed. > > Thanks, > Dehao > >> >> If it does fix the problem in http://gcc.gnu.org/PR54645 , then please add >> PR rtl-optimization/54645 >> to the ChangeLog entry >> >> Thanks for the quick turnaround. >> >> Ian
Re: GCC 4.7.2 Released
On Thu, Sep 20, 2012 at 8:27 AM, Jakub Jelinek wrote: > The GNU Compiler Collection version 4.7.2 has been released. > > GCC 4.7.2 is the first bug-fix release containing important fixes > for regressions and serious bugs in GCC 4.7.1 with over 70 bugs > fixed since the previous release. This release is available from > the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > A notable change in GCC 4.7.2 compared to 4.7.1 are ABI bug fixes > related to some C++11 templates (std::list and std::pair). As a result, > code using those templates in C++11 mode is again ABI compatible with > code in C++03/C++98 mode or C++11 mode of GCC 4.6 and earlier, but might > be ABI incompatible with code compiled by GCC 4.7.1 or 4.7.0 in C++11 > mode. See http://gcc.gnu.org/gcc-4.7/changes.html for more details. > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! I got -rw---1 3003 3002 82884636 Sep 20 10:40 gcc-4.7.2.tar.bz2 -rw---1 3003 3002 65 Sep 20 10:40 gcc-4.7.2.tar.bz2.sig -rw---1 3003 3002 106514345 Sep 20 10:41 gcc-4.7.2.tar.gz -rw---1 3003 3002 65 Sep 20 10:41 gcc-4.7.2.tar.gz.sig lftp ftp.gnu.org:/pub/gnu/gcc/gcc-4.7.2> get gcc-4.7.2.tar.bz2 get: Access failed: 550 Failed to open file. (gcc-4.7.2.tar.bz2) lftp ftp.gnu.org:/pub/gnu/gcc/gcc-4.7.2> -- H.J.
Tree loop if conversion at O2
Hi All! Is there any particular reason why tree loop if conversion (tree-if-conv.c) isn't enabled by default on O2 (as far as I can see it's true for any platforms)? Thanks, Igor
Re: GCC 4.7.2 Released
On Thu, Sep 20, 2012 at 08:13:02PM -0700, H.J. Lu wrote: > On Thu, Sep 20, 2012 at 8:27 AM, Jakub Jelinek wrote: > > The GNU Compiler Collection version 4.7.2 has been released. > > > > GCC 4.7.2 is the first bug-fix release containing important fixes > > for regressions and serious bugs in GCC 4.7.1 with over 70 bugs > > fixed since the previous release. This release is available from > > the FTP servers listed at: > > > > http://www.gnu.org/order/ftp.html > > > > A notable change in GCC 4.7.2 compared to 4.7.1 are ABI bug fixes > > related to some C++11 templates (std::list and std::pair). As a result, > > code using those templates in C++11 mode is again ABI compatible with > > code in C++03/C++98 mode or C++11 mode of GCC 4.6 and earlier, but might > > be ABI incompatible with code compiled by GCC 4.7.1 or 4.7.0 in C++11 > > mode. See http://gcc.gnu.org/gcc-4.7/changes.html for more details. > > > > Please do not contact me directly regarding questions or comments > > about this release. Instead, use the resources available from > > http://gcc.gnu.org. > > > > As always, a vast number of people contributed to this GCC release > > -- far too many to thank them individually! > > I got > > -rw---1 3003 3002 82884636 Sep 20 10:40 gcc-4.7.2.tar.bz2 > -rw---1 3003 3002 65 Sep 20 10:40 gcc-4.7.2.tar.bz2.sig > -rw---1 3003 3002 106514345 Sep 20 10:41 gcc-4.7.2.tar.gz > -rw---1 3003 3002 65 Sep 20 10:41 gcc-4.7.2.tar.gz.sig > lftp ftp.gnu.org:/pub/gnu/gcc/gcc-4.7.2> get gcc-4.7.2.tar.bz2 > get: Access failed: 550 Failed to open file. (gcc-4.7.2.tar.bz2) > lftp ftp.gnu.org:/pub/gnu/gcc/gcc-4.7.2> I get this via HTTP: $ wget http://ftp.gnu.org/pub/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2 --2012-09-21 08:41:27-- http://ftp.gnu.org/pub/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2 Resolving ftp.gnu.org... 208.118.235.20, 2001:4830:134:3::b Connecting to ftp.gnu.org|208.118.235.20|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2012-09-21 08:41:27 ERROR 403: Forbidden. Thierry pgpxBJWJQ74dt.pgp Description: PGP signature
