[Bug target/35839] New: Revision 133909 breaks bootstrap on powerpc-apple-darwin

[dominiq at lps dot ens dot fr]

After revision 133909 building libgfortran is broken at:

...
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.4-work/libgfortran -I.
-iquote../../../gcc-4.4-work/libgfortran/io
-I../../../gcc-4.4-work/libgfortran/../gcc
-I../../../gcc-4.4-work/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules
-ftree-vectorize -funroll-loops -g -O2 -MT matmul_i4.lo -MD -MP -MF
.deps/matmul_i4.Tpo -c ../../../gcc-4.4-work/libgfortran/generated/matmul_i4.c 
-fno-common -DPIC -o .libs/matmul_i4.o
../../../gcc-4.4-work/libgfortran/generated/matmul_i4.c: In function
'matmul_i4':
../../../gcc-4.4-work/libgfortran/generated/matmul_i4.c:87: internal compiler
error: in rs6000_check_sdmode, at config/rs6000/rs6000.c:11229
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [matmul_i4.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libgfortran] Error 2
make: *** [all] Error 2


-- 
   Summary: Revision 133909 breaks bootstrap on powerpc-apple-darwin
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


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

[Bug libfortran/35731] libfortran should use gettext to for localized error messages

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 12:42:06
   date||


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

[Bug fortran/35732] -fbounds-check: LHS/RHS size mismatch: Misleading error message

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 12:42:30
   date||


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

[Bug fortran/35826] some (erroneous) code produces: internal compiler error

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-04-06 12:44 
---
We need more information: for each compiler that fails, what is the output of
"gfortran -v"?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 12:44:34
   date||


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

--- Comment #2 from oder at eleks dot lviv dot ua  2008-04-06 13:21 ---
(In reply to comment #1)
> You need to report this with apple or at least try a still maintained gcc
> version and provide a testcase without Mac specific headers.

Well, it's not so easy. ./configure for GCC 4.3.0 fails with "Building GCC
requires GMP 4.1+ and MPFR 2.3.0+". I don't know what these are and I'm not too
eager spending time to search for all the necessary stuff needed to build a new
version and find out that there is some problem with building I can't resolve
after all. If there are no prebuilt binaries publicly available that means
there must be some reason for it. 
I have already tried to build latest GCC once for QNX. Well, after few days and
lots of corrections to headers I succeeded. But then I found that there are
some system related settings I don't know how to specify for new compiler and
startup stubs in objs, I don't have sources for. So, even though compiler
worked I did not take a risk to use it for production binaries compilation.
As for getting rid of system-specific headers, I tried replacing
OSAtomicIncrement32Barrier(paoDestination) with increment for volatile int64_t,
but the problem can't be reproduced that way. 
This seems to be PowerPC architecture related problem and I don't have other
operating systems/machines based on PowerPC.


-- 


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

[Bug fortran/35840] New: ICE for character expression in I/O specifier

[burnus at gcc dot gnu dot org]

The following gives an ICE:

==18935== Invalid read of size 1
==18935==at 0x4C25D82: strlen (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==18935==by 0x438ABE: compare_to_allowed_values (io.c:1404)
==18935==by 0x43A892: match_io (io.c:2883)
==18935==by 0x451BA9: match_word (parse.c:64)


write(10,*, asynchronous="Y"//"E"//trim("S  "))
end

However, it is a valid initialization expression. I tried the following, but it
did not help. (It still fails at "len = strlen (value)".)


--- io.c(Revision 133959)
+++ io.c(Arbeitskopie)
@@ -1389,11 +1389,17 @@ gfc_resolve_open (gfc_open *open)
 static int
 compare_to_allowed_values (const char *specifier, const char *allowed[],
   const char *allowed_f2003[],
-  const char *allowed_gnu[], char *value,
+  const char *allowed_gnu[], gfc_expr *expr,
   const char *statement, bool warn)
 {
   int i;
   unsigned int len;
+  const char *value;
+
+  if (gfc_simplify_expr (expr, 0) == 0)
+return 1;
+
+  value = expr->value.character.string;

   len = strlen (value);
   if (len > 0)


-- 
   Summary: ICE for character expression in I/O specifier
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-06 13:57 ---
Please attach preprocessed source then, it is likely that apples
OSAtomicIncrement32Barrier implementation is simply bogus (which is why I
suggested reporting this bug to apple).


-- 


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

[Bug fortran/35826] some (erroneous) code produces: internal compiler error

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-04-06 13:51 ---
Confirmed that this works for 4.3 and 4.4.
Also, using 1 (instead of the illegal 0) as
format generates the right error in 4.2, as well:

$ gfortran-4.2 foo.f90 
foo.f90:1.10:

write(18,1) 'trtot= ',trtot
 1
Error: FORMAT label 1 at (1) not defined
$ gfortran-4.2 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Debian 4.2.3-3)

This is not a regression.

Closing as fixed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Keywords||ice-on-invalid-code
 Resolution||FIXED


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

[Bug rtl-optimization/35841] New: [ira] segfault while building libgcc

[mstein dot lists at googlemail dot com]

Hi,
during the configure run for libgcc xgcc fails with a segfault.

Here is a backtrace:

#0  0x2b9b80f4e07b in raise () from /lib/libc.so.6
(gdb) bt
#0  0x2b9b80f4e07b in raise () from /lib/libc.so.6
#1  0x2b9b80f4f84e in abort () from /lib/libc.so.6
#2  0x00511845 in diagnostic_action_after_output (context=0x2586,
diagnostic=0x2586)
at /home/mstein/svn/ira/gcc/diagnostic.c:664
#3  0x00511994 in diagnostic_report_diagnostic (context=0xcc6620,
diagnostic=0x7fff29ddfec0) at /home/mstein/svn/ira/gcc/diagnostic.c:400
#4  0x00511c46 in internal_error (gmsgid=)
at /home/mstein/svn/ira/gcc/diagnostic.c:600
#5  0x006e1c60 in crash_signal (signo=11) at
/home/mstein/svn/ira/gcc/toplev.c:602
#6  
#7  0x006e01a6 in default_secondary_reload (in_p=0 '\0', x=0x0,
reload_class=EXTRA_FP_REGS, reload_mode=QImode, sri=0x7fff29de0280)
at /home/mstein/svn/ira/gcc/targhooks.c:595
#8  0x006892cc in secondary_reload_class (in_p=0 '\0',
class=EXTRA_FP_REGS, mode=QImode,
x=0x0) at /home/mstein/svn/ira/gcc/reload.c:525
#9  0x0067cefb in memory_move_secondary_cost (mode=QImode,
class=EXTRA_FP_REGS, in=0)
at /home/mstein/svn/ira/gcc/regclass.c:748
#10 0x00986f51 in init_ira () at /home/mstein/svn/ira/gcc/ira.c:323
#11 0x006e3320 in backend_init_target () at
/home/mstein/svn/ira/gcc/toplev.c:1970
#12 0x006e3f7d in toplev_main (argc=1, argv=0x0) at
/home/mstein/svn/ira/gcc/toplev.c:2017
#13 0x2b9b80f3b4ca in __libc_start_main () from /lib/libc.so.6
#14 0x00403d1a in _start () at ../sysdeps/x86_64/elf/start.S:113

gcc version 4.4.0 20080328 (experimental) [ira revision 133942] (GCC)


-- 
   Summary: [ira] segfault while building libgcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: sparc-elf


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

[Bug target/35806] Object code is bigger at -Os than at -O2

[mstein dot lists at googlemail dot com]

--- Comment #2 from mstein dot lists at googlemail dot com  2008-04-06 
14:31 ---
OK, using -Os together with -ftree-ch / -ftree-pre seem to help in some cases.

It would be nice if gcc could add/remove these flags automaticaly when 
using -Os :)


-- 

mstein dot lists at googlemail dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement
 GCC target triplet|arm-elf |


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

[Bug target/35806] Object code is bigger at -Os than at -O2

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-06 14:49 ---
The problem is that usually those options increase code size, which is why
they are disabled for -Os.  In your case while they initially increase code
size they expose optimization opportunity that in the end reduce code size ...


-- 


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

[Bug tree-optimization/35842] ICE without -fno-tree-ch

[nightstrike at gmail dot com]

--- Comment #1 from nightstrike at gmail dot com  2008-04-06 14:55 ---
Created an attachment (id=15434)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15434&action=view)
Preprocessed source

This is the preprocessed source that causes the ICE.


-- 


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

[Bug tree-optimization/35842] New: ICE without -fno-tree-ch

[nightstrike at gmail dot com]

gcc version 4.3.0 and 4.4.0 have an ICE when compiling a small piece of Firefox
code.  It happens with -O1, 2, or 3 and does not with -O0 or -Os.

The ICE is as follows:

x86_64-pc-mingw32-g++: warning: -pipe ignored because -save-temps specified
/mnt/dump/src/mozilla/mozilla/security/manager/ssl/src/nsCipherInfo.cpp: In
constructor ‘nsCipherInfo::nsCipherInfo(PRUint16)’:
/mnt/dump/src/mozilla/mozilla/security/manager/ssl/src/nsCipherInfo.cpp:73:
internal compiler error: in create_mem_ref, at tree-ssa-address.c:603


The cpp file in question is here:
http://mxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsCipherInfo.cpp


A gdb traceback is here:

(gdb) where
#0  internal_error (gmsgid=0x899e0ca "in %s, at %s:%d") at
../../gcc/gcc/diagnostic.c:598
#1  0x082bd2df in fancy_abort (file=0x89de4d4
"../../gcc/gcc/tree-ssa-address.c", line=603, function=0x89de5c8
"create_mem_ref")
at ../../gcc/gcc/diagnostic.c:654
#2  0x0856b25c in create_mem_ref (bsi=0xbfde871c, type=0xb6cfb3a8,
addr=0xbfde8660) at ../../gcc/gcc/tree-ssa-address.c:603
#3  0x085c03c7 in rewrite_use_address (data=0xbfde891c, use=0x8c499c8,
cand=0x8c2daa8) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5227
#4  0x085c3f4c in rewrite_uses (data=0xbfde891c) at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5286
#5  0x085c8659 in tree_ssa_iv_optimize_loop (data=0xbfde891c, loop=) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5485
#6  0x085c8c75 in tree_ssa_iv_optimize () at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5518
#7  0x085d7295 in tree_ssa_loop_ivopts () at
../../gcc/gcc/tree-ssa-loop.c:580
#8  0x084276ef in execute_one_pass (pass=0x8ae7680) at
../../gcc/gcc/passes.c:1127
#9  0x084278f7 in execute_pass_list (pass=0x8ae7680) at
../../gcc/gcc/passes.c:1180
#10 0x0842790a in execute_pass_list (pass=0x8ae72c0) at
../../gcc/gcc/passes.c:1181
#11 0x0842790a in execute_pass_list (pass=0x8ae6b00) at
../../gcc/gcc/passes.c:1181
#12 0x08523dec in tree_rest_of_compilation (fndecl=0xb749e7e0) at
../../gcc/gcc/tree-optimize.c:420
#13 0x08715b98 in cgraph_expand_function (node=0xb6d17410) at
../../gcc/gcc/cgraphunit.c:1157
#14 0x0871817e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220
#15 0x0810c285 in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:3471
#16 0x084b192c in toplev_main (argc=13, argv=0xbfde8bf4) at
../../gcc/gcc/toplev.c:971
#17 0x08225792 in main (argc=1634296879, argv=0x736f6e67) at
../../gcc/gcc/main.c:35



I will upload the preprocessed source.


-- 
   Summary: ICE without -fno-tree-ch
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nightstrike at gmail dot com
  GCC host triplet: i686-pc-linux
GCC target triplet: x86_64-pc-mingw32


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

[Bug libfortran/35731] libfortran should use gettext to for localized error messages

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-04-06 15:04 
---
(In reply to comment #0)
> c) In configure.ac
> ZW_GNU_GETTEXT_SISTER_DIR

No, the configury is probably going to be more tricky than that. The macro
above (defined in config/gettext-sister.m4) relates to host, and is used in
libcpp/ and gcc/ to peek at configury info from intl/. The is currently no GCC
target library that supports localisation, so that is useless.

I think the right thing to use is AM_GNU_GETTEXT, defined in config/gettext.m4.

As for the po/ directory, the place to start is to grep for POSUB in
gcc/Makefile.in.


-- 


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

[Bug testsuite/35843] [4.4 Regression]: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-04-06 15:16 ---
They were introduced by 133930:

http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00154.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|gcc.dg/pr30957-1.c and  |[4.4 Regression]:
   |gcc.dg/var-expand1.c don't  |gcc.dg/pr30957-1.c and
   |work|gcc.dg/var-expand1.c don't
   ||work


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[d at domob dot eu]

--- Comment #21 from d at domob dot eu  2008-04-06 15:28 ---
Created an attachment (id=15435)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15435&action=view)
Handles bounds checking and fixes regressions.

This patch handles the bounds checking correctly, adds a test case if -std=f95
rejects array constructors with typespec, and fixes all regression failures,
i.e., this makes the testsuite pass cleanly including all my own new test
cases.

However, I'm not quite sure about some things I did and if this is really the
right way (although it seems to work), marked them mostly with XXX:.  I'd be
glad if someone could have a look at the patch and those places especially to
see if all is ok or give comments how it should be done.

And last but not least I'm not sure if I hit the right code style, I mostly
doubt I did correctly insert the tab characters where they belong (as I'm used
to indent with spaces only) ;)


-- 

d at domob dot eu changed:

   What|Removed |Added

  Attachment #15429|0   |1
is obsolete||


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

[Bug tree-optimization/35842] ICE without -fno-tree-ch

[nightstrike at gmail dot com]

--- Comment #2 from nightstrike at gmail dot com  2008-04-06 15:07 ---
To clarify the title, the ICE goes away with all optimization levels when
-fno-tree-ch is used.


-- 


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

[Bug testsuite/35843] New: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work

[hjl dot tools at gmail dot com]

From

http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00420.html

ERROR: gcc.dg/pr30957-1.c: no files matched glob pattern
"hard_float9950.c.[0-9][0-9][0-9]r.expand" for " dg-require-effective-target 8
hard_float "
UNRESOLVED: gcc.dg/pr30957-1.c: no files matched glob pattern
"hard_float9950.c.[0-9][0-9][0-9]r.expand" for " dg-require-effective-target 8
hard_float "
ERROR: gcc.dg/var-expand1.c: can't read "et_cache(hard_float,value)": no such
element in array for " dg-require-effective-target 4 hard_float "
UNRESOLVED: gcc.dg/var-expand1.c: can't read "et_cache(hard_float,value)": no
such element in array for " dg-require-effective-target 4 hard_float "

On Linux/Intel64, I got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ hard_float1773.c 
-fdump-rtl-expand -fno-show-column -S  -m32 -o hard_float1773.s(timeout =
300)
cc1: error: unrecognized command line option "-fdump-rtl-expand"^M
compiler exited with status 1
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/va-arg-pack-len-2.c   -O2
-fno-show-column -S  -m32 -o va-arg-pack-len-2.s(timeout = 300)
In function 'myopen',^M
inlined from 'main' at
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/va-arg-pack-len-2.c:39:^M
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/va-arg-pack-len-2.c:24: error:
call to 'error_open_missing_mode' declared with attribute error: open with
O_CREAT needs 3 arguments, only 2 were given^M
In function 'myopen',^M
inlined from 'main' at
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/va-arg-pack-len-2.c:40:^M
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/va-arg-pack-len-2.c:18: warning:
call to 'warn_open_too_many_arguments' declared with attribute warning: open
called with more than 3 arguments^M
compiler exited with status 1


-- 
   Summary: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug fortran/35844] New: RFC: Environment variable for overwritting the -std= for libgfortran

[burnus at gcc dot gnu dot org]

I think it makes sense to be able to overwrite the Fortran standard passed to
the library (f95, f2003, f2008, gnu, legacy). The reason is that we have
several cases where with -std=f95 GNU extensions are rejected. I think not all
users are aware of this and combining a compliant Fortran program with
libraries which are not can potentially cause problems. And if the source code
is not available ...

I therefore think it makes sense to:

a) Note the fact that -std= can change the library behaviour, esp. -std=f95 can
reject F2003 or GNU features.

b) Allow the user to overwrite it using an environment variable


-- 
   Summary: RFC: Environment variable for overwritting the -
std= for libgfortran
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug testsuite/28870] [4.2/4.3/4.4 Regression] configuring, over-riding timeout values in testsuite

[nightstrike at gmail dot com]

--- Comment #18 from nightstrike at gmail dot com  2008-04-06 16:03 ---
What is the status on this?  I am having a lot of test timeouts when testing
the x86_64-pc-mingw cross compiler, as sometimes there are slow programd and
annoying ssh network delays.  Extending the timeout in a robust way would be
very helpful.


-- 


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[burnus at gcc dot gnu dot org]

--- Comment #22 from burnus at gcc dot gnu dot org  2008-04-06 16:22 ---
> Created an attachment (id=15435)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15435&action=view) [edit]
> Handles bounds checking and fixes regressions.

Great.

> However, I'm not quite sure about some things I did [...]

I think your patch is in a good enough shape to post it to [EMAIL PROTECTED]
and ask there for comments; this ensures that all gfortraners read it (and not
only three Fortraners) and it makes discussing easier than a in a bugreport.

I think one could also submit it for review, which means that you need to write
a changelog and should CC the email to [EMAIL PROTECTED]  (The reason is that 
then
also developers of the middle end can glance at it and give comments.)

+/* XXX: Ok as global or does bounds-checking need to be reentrant for things
+   like nested constructors?  */

I think it is OK for now, but we need to fix it later. I found a test case
which crashes gfortran (ICE, internal compiler error) for nested character
constructors - even without typespec or bounds checks. See PR 35846. I think
this should be fixed together with the rest.


-- 


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

[Bug c++/35838] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-04-06 16:27 ---
Running under gdb, I see

16.xg:
/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/16.cc:57:
void test01(): Assertion `err == ios_base::eofbit' failed.

Program received signal SIGABRT, Aborted.

err has the value 6.


-- 


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

[Bug tree-optimization/35842] ICE without -fno-tree-ch

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-06 16:06 ---
-fno-tree-ch probably just hides the bug.  -linux targets work for me.

(gdb) call debug_generic_expr (tmp)
&SSL_ImplementedCiphers
(gdb) call is_gimple_min_invariant (tmp)
$1 = 0 '\0'

which is the problem.

static bool
fixed_address_object_p (tree obj)
{
  return (TREE_CODE (obj) == VAR_DECL
  && (TREE_STATIC (obj)
  || DECL_EXTERNAL (obj)));
}

doesn't match what is_gimple_invariant_address checks for, in this
case probably the DECL_DLLIMPORT_P part of

case VAR_DECL:
  if (((TREE_STATIC (op) || DECL_EXTERNAL (op))
   && ! DECL_DLLIMPORT_P (op))
  || DECL_THREAD_LOCAL_P (op)
  || DECL_CONTEXT (op) == current_function_decl
  || decl_function_context (op) == current_function_decl)
return true;

is at fault.  Fixing that mismatch with the obvious

Index: tree-ssa-address.c
===
--- tree-ssa-address.c  (revision 133961)
+++ tree-ssa-address.c  (working copy)
@@ -345,7 +345,8 @@ fixed_address_object_p (tree obj)
 {
   return (TREE_CODE (obj) == VAR_DECL
  && (TREE_STATIC (obj)
- || DECL_EXTERNAL (obj)));
+ || DECL_EXTERNAL (obj))
+ && ! DECL_DLLIMPORT_P (obj));
 }

 /* If ADDR contains an address of object that is a link time constant,

leaves us with

./cc1plus -quiet t.ii -O
/mnt/dump/src/mozilla/mozilla/security/manager/ssl/src/nsCipherInfo.cpp: In
constructor ‘nsCipherInfo::nsCipherInfo(PRUint16)’:
/mnt/dump/src/mozilla/mozilla/security/manager/ssl/src/nsCipherInfo.cpp:73:
internal compiler error: in legitimize_pic_address, at config/i386/i386.c:7666
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

  /* Given that we've already handled dllimport variables separately
 in legitimize_address, and all other variables should satisfy
 legitimate_pic_address_disp_p, we should never arrive here.  */
  gcc_assert (!TARGET_64BIT_MS_ABI);


Can you bootstrap & test the tree-ssa-address.c change?  It is correct
nevetheless.


-- 


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

[Bug fortran/35846] New: ICE on nested character constructors

[burnus at gcc dot gnu dot org]

The following program gives an ICE. One reason could be the global variables.
(cf. PR27997 comment 21).

implicit none
integer i
character(len=2) :: c(3)
c = 'a'
c = [ [ trim(c(1)), 'a' ]//'c', 'cd' ]
print *, c
end

Variants to check (or combinations of those):
- Compile with -fbounds-check
- Use  c = '' or  c = 'ab'
- Use typespec after PR27997 has been fixed, either on the inner or on the
outer loop. E.g.
  c = [ [ character(1):: trim(c(1)), 'a' ]//'c', 'cd' ]
etc.


-- 
   Summary: ICE on nested character constructors
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/35842] ICE without -fno-tree-ch

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-06 16:37 ---
Reduced C testcase:

extern __attribute__((dllimport)) const int SSL_ImplementedCiphers[];
extern void SSL_GetCipherSuiteInfo(int cipherSuite);
void nsCipherInfo(int SSL_NumImplementedCiphers)
{
 int i;
 for (i = 0; i < SSL_NumImplementedCiphers; ++i) {
   const int i_id = SSL_ImplementedCiphers[i];
   SSL_GetCipherSuiteInfo(i_id);
 }
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 16:37:12
   date||


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

[Bug target/35847] New: unrecognized option `-march=score7'

[mstein dot lists at googlemail dot com]

Hi,
building score-elf fails with
configure:2398: /home/mstein/inst/trunk/score-elf/./gcc/xgcc
-B/home/mstein/inst/trunk/score-elf/./
gcc/ -B/home/mstein/cross-install/score-elf-trunk/score-elf/bin/
-B/home/mstein/cross-install/score
-elf-trunk/score-elf/lib/ -isystem
/home/mstein/cross-install/score-elf-trunk/score-elf/include -is
ystem /home/mstein/cross-install/score-elf-trunk/score-elf/sys-include -o
conftest -g -O2 conft
est.c  >&5
/home/mstein/cross-local/score-elf/usr/bin/as: unrecognized option
`-march=score7'

gcc version 4.4.0 20080405 (experimental) [trunk revision 133942] (GCC)
binutils-cvs is from today


-- 
   Summary: unrecognized option `-march=score7'
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: score-elf


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

[Bug other/35848] New: Missing port entry in MAINTAINERS file

[mstein dot lists at googlemail dot com]

Hi,
the entry for the port "score" is missing in the MAINTAINERS file.


-- 
   Summary: Missing port entry in MAINTAINERS file
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com


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

[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666

[ktietz at gcc dot gnu dot org]

--- Comment #7 from ktietz at gcc dot gnu dot org  2008-04-06 18:20 ---
Created an attachment (id=15436)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15436&action=view)
Patch for i386.c:7666 fixing dllimport symbol handling

This patch is a try for fixing the new ICE.
It is currently be tested.
If works, I will post a patch for this to gcc-patches


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-06 18:05 ---
This is now a target issue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |target
Summary|ICE without -fno-tree-ch|ICE in
   ||legitimize_pic_address, at
   ||config/i386/i386.c:7666


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

[Bug tree-optimization/35842] ICE without -fno-tree-ch

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-06 18:05 ---
Subject: Bug 35842

Author: rguenth
Date: Sun Apr  6 18:04:47 2008
New Revision: 133963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133963
Log:
2008-04-06  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/35842
* tree-ssa-address.c (fixed_address_object_p): Adjust to match
is_gimple_invariant_address.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-address.c


-- 


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

[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666

[ktietz at gcc dot gnu dot org]

--- Comment #8 from ktietz at gcc dot gnu dot org  2008-04-06 18:29 ---
Ok, the patch fixes the ICE by test without any regressions.


-- 


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

[Bug fortran/35832] Better error message for wrong arguments to I/O statements

[tobi at gcc dot gnu dot org]

--- Comment #2 from tobi at gcc dot gnu dot org  2008-04-06 18:59 ---
Subject: Bug 35832

Author: tobi
Date: Sun Apr  6 18:58:34 2008
New Revision: 133964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133964
Log:
2008-04-06  Tobias Schlter  <[EMAIL PROTECTED]>

PR fortran/35832
fortran/
* io.c (io_tag): Add field 'value'.  Split 'spec' field in
existing io_tags.
(match_etag, match_vtag, match_ltag): Split parsing in two steps
to give better error messages.
testsuite/
* gfortran.dg/io_constraints_2.f90: Adapt to new error message.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/io_constraints_2.f90


-- 


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

[Bug target/35839] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-06 19:19 ---
Since powerpc-apple-darwin9 enables Altivec by default, the vectorizer happens
in libgfortran.

Almost all the vectorizer tests are now failing too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|powerpc-apple-darwin9   |
   GCC host triplet|powerpc-apple-darwin9   |
 GCC target triplet|powerpc-apple-darwin9   |powerpc*-*-*
   Keywords||build, ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 19:19:04
   date||
Summary|Revision 133909 breaks  |Altivec with the vectorizer
   |bootstrap on powerpc-apple- |causes an ICE in
   |darwin  |rs6000_check_sdmode
   Target Milestone|--- |4.4.0


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

[Bug fortran/35832] Better error message for wrong arguments to I/O statements

[tobi at gcc dot gnu dot org]

--- Comment #3 from tobi at gcc dot gnu dot org  2008-04-06 19:27 ---
Fixed on the trunk.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug target/35839] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-06 19:32 ---
Simple testcase:
void
foo (float a[32], float b[2][32])
{
  int i;
  for (i = 0; i < 32; i++)
a[i] = (b[0][i] > b[1][i]) ? b[0][i] : b[1][i];
}

Compile with -O2 -maltivec -ftree-vectorize and you get the failure.
We have a ALIGN_INDIRECT_REF here.


-- 


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[brian at dessent dot net]

--- Comment #4 from brian at dessent dot net  2008-04-06 19:49 ---
Subject: Re:  Wrong instruction generated for comparison with zero 
 on PPC 64 bit

> after all. If there are no prebuilt binaries publicly available that means
> there must be some reason for it.

Where in the world do you get that idea?  Both Fink and Macports have
gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot.


-- 


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

--- Comment #5 from oder at eleks dot lviv dot ua  2008-04-06 20:14 ---
(In reply to comment #4)
> Both Fink and Macports have
> gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot.

Could you please provide a link to gcc archive?
On gcc.gnu.org there is no MacOS in Download->Binaries
Fink webpage offers binary installer for download. But I don't like it, since,
as I already mentioned, I don't have root access and would not like to install
anything outside my home folder on a computer I've been let in just to have a
try if my sources could be compiled on MacOS.
As for Macports, I can't browse that site with IE7. It attempts to download
some XML file all the time instead of browsing the pages.


-- 


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

[Bug fortran/35849] New: "wrong" line shown in error message for parameter

[burnus at gcc dot gnu dot org]

The following prints:

  INTEGER, PARAMETER, DIMENSION(10) ::  A = [(i, i = 1,10)]
  1
Error: Magnitude of second argument of ISHFTC exceeds third argument at (1)

However, the error actually occurs in the second line.


NAG f95 gets this right:
  Error: fhj.f90, line 2: Element 6 of SHIFT array (6) to intrinsic ISHFTC out
of range (-5:5)


  INTEGER, PARAMETER, DIMENSION(10) ::  A = [(i, i = 1,10)]
  INTEGER, PARAMETER, DIMENSION(10)  :: B = ISHFTC(3, A, 5)   !ICE
  end


-- 
   Summary: "wrong" line shown in error message for parameter
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/35849] "wrong" line shown in error message for parameter

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-06 20:38 ---
With the following patch, the message shown is:

  INTEGER, PARAMETER, DIMENSION(10)  :: B = ISHFTC(3, A, 5)   !ICE
  1
Error: Magnitude of second argument of ISHFTC exceeds third argument at (1)

I think there are more places were one should use expr->where instead of
sym->where; however, I do not see ad hoc whether this causes a less helpful
message for variables (as opposed to PARAMETERs); in this case it is simple as
the message states that it is the "second" and the "third" argument, which
makes the possition of the "1" less crutial.


Index: simplify.c
===
--- simplify.c  (revision 133965)
+++ simplify.c  (working copy)
@@ -1878,37 +1878,37 @@ gfc_expr *
 gfc_simplify_ishft (gfc_expr *e, gfc_expr *s)
 {
   gfc_expr *result;
   int shift, ashift, isize, k, *bits, i;

   if (e->expr_type != EXPR_CONSTANT || s->expr_type != EXPR_CONSTANT)
 return NULL;

   if (gfc_extract_int (s, &shift) != NULL)
 {
-  gfc_error ("Invalid second argument of ISHFT at %L", &s->where);
+  gfc_error ("Invalid second argument of ISHFT at %L", &e->where);


-- 


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[brian at dessent dot net]

--- Comment #6 from brian at dessent dot net  2008-04-06 20:44 ---
Subject: Re:  Wrong instruction generated for comparison with zero 
 on PPC 64 bit

> Could you please provide a link to gcc archive?
> On gcc.gnu.org there is no MacOS in Download->Binaries

gcc.gnu.org doesn't supply any binaries, only source.  If you want
binaries you get them from a third party like Debian, SuSE, Fedora,
Fink, MinGW, whatever.  gcc supports something like three dozen
architectures, each with numerous variants/configurations -- there's no
way that any one organization could maintain binaries for those hundreds
of resulting target combinations.


-- 


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

[Bug middle-end/35400] [4.4 Regression] -Wtype-limits -O2 causes ICE tree check: expected ssa_name, have addr_expr in get_value_range, at tree-vrp.c:469

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-04-06 21:21 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35400] [4.4 Regression] -Wtype-limits -O2 causes ICE tree check: expected ssa_name, have addr_expr in get_value_range, at tree-vrp.c:469

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-06 21:21 
---
Subject: Bug 35400

Author: rguenth
Date: Sun Apr  6 21:20:49 2008
New Revision: 133967

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133967
Log:
2008-04-06  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/35400
* tree-vrp.c (vrp_evaluate_conditional): Only query value-range
information from SSA_NAMEs.

* gcc.dg/torture/pr35400.c: New testcase.
* g++.dg/torture/pr35400.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr35400.C
trunk/gcc/testsuite/gcc.dg/torture/pr35400.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug fortran/35850] New: Possibly rejects valid problem with dummy procedure

[burnus at gcc dot gnu dot org]

It might by that gfortran wrongly rejects the following program. Or it might be
that it is invalid. This PR is mostly about checking whether the program is
valid. It can be found at:

http://groups.google.com/group/comp.lang.fortran/msg/077a30ae15edd3cc



Compiling only the MODULE - with [ ] replaced by (/ /):

- It complies with: ifort 9.1, openf95, g95

- Sunf95:
  "call C(qsub, 2)": ERROR: The type of the actual argument, "LOGICAL", does
 not match "INTEGER", the type of the dummy argument.
- Lahey: column 18: In the reference to procedure 'C', the type of actual
argument must be the same as that of the corresponding dummy argument.

- NAG f95, gfortran: "Type/rank mismatch", respectively
  Error: line 16: Scalar supplied for array argument SUB (no. 1) of B
  Error: line 19: Incorrect data type for argument SUB (no. 1) of C


Compiling the whole program:
- Works with g95 and openf95
- Fails with ifort: line 97: The shape matching rules of actual arguments and
dummy arguments have been violated.   [SUBB]


Compiling the whole program, but with "call C" commented out in "callthru":
- Works with sunf95 and Lahey.


Thus:
- Is "call C" correct or not?
- Is "call B" correct or not?
- Is "call B" in the module valid, but "call callthru(subB,n)" is not?


-- 
   Summary: Possibly rejects valid problem with dummy procedure
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/35851] New: gcc should report an error and not a warning if fstack-protector is not supported

[g dot esp at free dot fr]

glibc-2.7 test for ssp support and use ssp if no error is reported

configure:6449: gcc -B/tools_alpha/bin/ -g -O2   -fstack-protector
-o conftest conftest.c 1>&5
conftest.c:1: warning: -fstack-protector not supported for this target
configure:6452: $? = 0
configure:6461: result: yes

If warning is changed to error, glibc configure now work

I look in gcc-4.2.3 and gcc-4.3 code at gcc/toplev.c
  /* Targets must be able to place spill slots at lower addresses.  If the
 target already uses a soft frame pointer, the transition is trivial.  */
  if (!FRAME_GROWS_DOWNWARD && flag_stack_protect)
{
  warning (0, "-fstack-protector not supported for this target");
  flag_stack_protect = 0;
}
  if (!flag_stack_protect)
warn_stack_protect = 0;

So with only a warning emittted by gcc, configure receive 0 and report that ssp
work.
I try changing the warning to an error on gcc-4.2.3 and now glib-2.7 configure
on alpha rightfully find
checking for -fstack-protector... no
--- gcc-4.2.3/gcc/toplev.c.old  2007-09-01 17:28:30.0 +0200
+++ gcc-4.2.3/gcc/toplev.c  2008-04-06 17:08:14.0 +0200
@@ -1834,7 +1834,7 @@
  target already uses a soft frame pointer, the transition is trivial.  */
   if (!FRAME_GROWS_DOWNWARD && flag_stack_protect)
 {
-  warning (0, "-fstack-protector not supported for this target");
+  error ("-fstack-protector not supported for this target");
   flag_stack_protect = 0;
 }
   if (!flag_stack_protect)


-- 
   Summary: gcc should report an error and not a warning if fstack-
protector is not supported
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: g dot esp at free dot fr
  GCC host triplet: alpha-linux-gnu


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

[Bug c/35851] gcc should report an error and not a warning if fstack-protector is not supported

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-06 21:28 ---
Use -Werror.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/35840] ICE for character expression in I/O specifier

[tobi at gcc dot gnu dot org]

--- Comment #1 from tobi at gcc dot gnu dot org  2008-04-06 21:03 ---
I'm on it.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tobi at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-06 21:03:01
   date||


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

[Bug fortran/35850] Possibly rejects valid problem with dummy procedure

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-06 21:45 ---
Simplified test case.

gfortran: "external f" -> function or procedure; "call callSub(f)" -> f :=
subroutine. And thus: "call callFunc(f)" => error.

NAG f95 & sunf95: Without the "implicit integer(f)": missmatch real <->
integer.

g95, ifort, openf95: OK, even without the implicit statement.


module m
  implicit none
contains
  subroutine callit(f, n)
! implicit integer(f)
integer :: n
external f
if(n == 1) then
  call callSub(f)
else
  call callFunc(f)
endif
  end subroutine callit

  subroutine callSub(sub)
interface
  subroutine sub(a)
  end subroutine sub
end interface
  end subroutine callSub

  subroutine callFunc(func)
interface
  integer function func()
  end function func
end interface
  end subroutine callFunc
end module m


-- 


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

[Bug fortran/35850] Possibly rejects valid problem with dummy procedure

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-04-06 21:51 ---
Hmm, I think gfortran is right:

"12.4.1.3 Actual arguments associated with dummy procedure entities"
[...]
"If the interface of the dummy argument is implicit and either the name of the
dummy argument is explicitly typed or it is referenced as a function, the dummy
argument shall not be referenced as a subroutine"


-- 


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

[Bug fortran/35850] Possibly rejects valid problem with dummy procedure

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-04-06 22:03 ---
Close as invalid.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35852] New: -Wconversion rejects bitwise negation and assignment, cannot cast around

[fang at csl dot cornell dot edu]

g++-4.3.0 -ansi -pedantic-errors -std=c++0x -Wall -Wconversion
issues the following diagnostic on the following code:

// test case:
typedef unsigned short  ushort;

enum {
FOO = 0x13
};

template 
inline
void
andnot(T& lv, T&& rv) {
lv &= ~rv;
}

template 
inline
void
andnot(T& lv, const T& rv) {
lv &= ~rv;
}

int
main(int, char*[]) {
ushort x = 99;
x = ~FOO;
x &= ~FOO;  // -Wconversion
x = x & ~FOO;   // -Wconversion
x = x & ushort(~FOO);   // -Wconversion
x = x & ushort(~ushort(FOO));   // -Wconversion
x &= static_cast(~FOO); // -Wconversion
x &= ~x;
// andnot(x, FOO);  // no match
andnot(x, ushort(FOO)); // -Wconversion
return x;
}
// end test case.

../../../src/conv.cc: In function 'int main(int, char**)':
../../../src/conv.cc:25: warning: conversion to 'ushort' from 'int' may alter
its value
../../../src/conv.cc:26: warning: conversion to 'ushort' from 'int' may alter
its value
../../../src/conv.cc:27: warning: conversion to 'ushort' from 'int' may alter
its value
../../../src/conv.cc:28: warning: conversion to 'ushort' from 'int' may alter
its value
../../../src/conv.cc:29: warning: conversion to 'ushort' from 'int' may alter
its value
../../../src/conv.cc: In function 'void andnot(T&, T&&) [with T = ushort]':
../../../src/conv.cc:32:   instantiated from here
../../../src/conv.cc:11: warning: conversion to 'short unsigned int' from 'int'
may alter its value

All warnings disappear if -Wconversion is omitted.  
I don't understand the rationale why some of the above lines are diagnostic
free (assignments), and others trigger the diagnostic, so I cannot claim which
are valid w.r.t. -Wconversion.  I did however expect a function-style
(ctor-style) cast or static_cast to suppress the diagnostic.  
Is there a bug, or proper "workaround" to locally suppress the diagnostic?

keywords: diagnostic


-- 
   Summary: -Wconversion rejects bitwise negation and assignment,
cannot cast around
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu


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

[Bug middle-end/35843] [4.4 Regression]: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-07 01:13 ---
-fdump-rtl-expand no longer works, -fdump-tree-expand does though.

We do document -fdump-rtl-expand and not -fdump-tree-expand:
-fdump-rtl-expand
Dump after RTL generation, to file.104r.expand. 

Thanks,
Andrew Pinski


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|testsuite   |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-07 01:13:56
   date||
   Target Milestone|--- |4.4.0


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

[Bug middle-end/35853] New: [4.4 Regression] -d is still referenced in some cases (documentation)

[pinskia at gcc dot gnu dot org]

When I noticed PR 35843, I saw that some -dletter was still referenced in some
cases:
-dv
For each of the other indicated dump files (either with -d or -fdump-rtl-pass),
dump a representation of the control flow graph suitable for viewing with VCG
to file.pass.vcg. 
-dx
Just generate RTL for a function instead of compiling it. Usually used with `r'
(-fdump-rtl-expand). 

Also the sentence above this list is incorrect as the long options don't have a
-d letter any more:
Most debug dumps can be enabled either passing a letter to the -d option, or
with a long -fdump-rtl switch; here are the possible letters for use in letters
and pass, and their meanings:


-- 
   Summary: [4.4 Regression] -d is still referenced in some cases
(documentation)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug middle-end/35854] New: [4.3/4.4 Regression] life passes dump option still documented

[pinskia at gcc dot gnu dot org]

When looking into the documentation for the other two bugs which I just
confirmed/filed, I noticed that we still document the life passes dump option
but the life pass was removed when dataflow branch was merged in:
-fdump-rtl-cfg
-fdump-rtl-life
-fdump-rtl-cfg enable dumping after control and data flow analysis, to
file.116r.cfg. -fdump-rtl-cfg enable dumping dump after life analysis, to
file.128r.life1 and file.135r.life2.


-- 
   Summary: [4.3/4.4 Regression] life passes dump option still
documented
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.1


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

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-04-07 01:22 ---
Can you provide the .ii file which is generated when you add the -save-temps
option.  I want to say this is a bug in Apple's header's inline-asm.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/35853] [4.4 Regression] -d is still referenced in some cases (documentation)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.4.0


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

[Bug middle-end/35853] [4.4 Regression] -d is still referenced in some cases (documentation)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-07 01:24 ---
The removal of -d letter support for the RTL passes was done by:
2008-04-05  Jan Hubicka  <[EMAIL PROTECTED]>


-- 


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-07 01:28 ---
Hmm, if we change r to be an array, fre does the correct thing but shouldn't it
do the correct thing for the non array case too?


-- 


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

[Bug tree-optimization/2480] aliasing problem with global structures

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-04-07 01:32 
---
Hmm, we do get something different on the trunk:
bar ()
{
  struct example * ex1.0;

:
  ex1.0 = ex1;
  ex1.0->a = 1;
  ex1.0->b = 2;
  ex1.0->c = 3;
  if (ex1.0->b != 2)
goto ;
  else
goto ;

:
  link_error ();
  if (ex1->c != 3)
goto ;
  else
goto ;

:
Invalid sum of incoming frequencies 5123, should be 6216
  link_error () [tail call];

:
Invalid sum of incoming frequencies 11093, should be 1
  return;

}


-- 


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

[Bug rtl-optimization/35309] Late struct expansion leads to missing PRE

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-07 01:36 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-07 01:36:07
   date||


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

[Bug middle-end/35346] Scalar replacement -- handling of conditional generator -- missing

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-07 01:37 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-07 01:37:59
   date||


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

[Bug middle-end/35345] Scalar replacement to handle output dependence

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-07 01:38 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-07 01:38:45
   date||


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

[Bug middle-end/35286] Missing PRE for globals

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-04-07 01:40 ---
Yes this is the same as PR  23455.

*** This bug has been marked as a duplicate of 23455 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/23455] tree load PRE is not working for global variables

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2008-04-07 01:40 
---
*** Bug 35286 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com


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

[Bug tree-optimization/25553] Missed removal of load

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-04-07 01:44 ---
This turns out to be PRE for global decl issue as the following is done
correctly (at least on the trunk):
int g(int);
int f(int tt, int *t)
{
  if (tt)
*t = 2;
  else
*t = 3;
  return g(*t);
}
--- CUT ---
f (tt, t)
{
  int prephitmp.9;
  int D.1182;

:
  if (tt != 0)
goto ;
  else
goto ;

:
  *t = 2;
  prephitmp.9 = 2;
  goto ;

:
  *t = 3;
  prephitmp.9 = 3;

:
  D.1182 = g (prephitmp.9) [tail call];
  return D.1182;

}


*** This bug has been marked as a duplicate of 23455 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/23455] tree load PRE is not working for global variables

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2008-04-07 01:44 
---
*** Bug 25553 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/35287] Missing PRE for indirect load

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-07 01:46 ---
(In reply to comment #1)
> Confirmed.  I think this is the same issue as PRE of globals.

It is as if you change the source to be:
int g, g2;
int foo(int p, int *gp)
{
   int t = 0;
   if (p)
  t = *gp + 1;

   return (*gp + t);
}
--- CUT ---
We get the correct optimization:
foo (p, gp)
{
  int prephitmp.9;
  int t;

:
  if (p != 0)
goto ;
  else
goto ;

:
  prephitmp.9 = *gp;
  t = 0;
  goto ;

:
  prephitmp.9 = *gp;
  t = prephitmp.9 + 1;

:
  return prephitmp.9 + t;

}


*** This bug has been marked as a duplicate of 23455 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/23455] tree load PRE is not working for global variables

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-04-07 01:46 
---
*** Bug 35287 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|heisenbug in tree vectorizer|[4.4 Regression] heisenbug
   ||in tree vectorizer
   Target Milestone|--- |4.4.0


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

[Bug target/35661] __attribute__((cold)) generates wrong code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-07 02:00:23
   date||


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

[Bug libmudflap/35755] [4.4 Regression]: libmudflap.cth/pass39-frag.c

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

Conversion failure : Recipients-Information is not available.

[Superuser]

This report relates to your message:


of Mon, 7 Apr 2008 11:14:32 +0900


Your message was not delivered to: [EMAIL PROTECTED]
for the following reason: unable-to-transfer
and the following diagonostic: recipient-reassignment-prohibited

* The following information is directed towards the local administrator
Reporting-MTA: x400; smtpgw.matsuzakaya-dept.co.jp
Arrival-Date: Mon, 7 Apr 2008 11:14:32 +0900
DSN-Gateway: dns; smtpgw.matsuzakaya-dept.co.jp

Final-Recipient: RFC822; gustafson4vigil@matsuzakaya.co.jp
Action: failed
Status: 5.4.0
Last-Attempt-Date: Mon, 7 Apr 2008 11:14:32 +0900

Received: from SN90013.matsuzakaya.co.jp ([100.90.4.251])
	by sn90210.matsuzakaya.co.jp (Switch-3.1.2/Switch-3.1.2) with ESMTP id 03720ENC12498
	for <[EMAIL PROTECTED]>; Mon, 07 Apr 2008 11:14:23 +0900
Received: from 125.245.147.186 ([125.245.147.186])
	by SN90013.matsuzakaya.co.jp (Build 103 8.9.3p2/NT-8.9.3) with ESMTP id LAA32387
	for <[EMAIL PROTECTED]>; Mon, 07 Apr 2008 11:14:11 +0900
Message-ID: <[EMAIL PROTECTED]>
From: "Watch Dealer Online" <[EMAIL PROTECTED]>
To: "Replica Handbags" <[EMAIL PROTECTED]>
Subject: Replica Pens
Date: Mon, 07 Apr 2008 00:26:48 +
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=_NextPart_000_0006_01C89855.06F280A4"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

Your e-mail could not be delivered

[scm]

eTrust Secure Content Manager SMTPMAIL could not deliver the e-mail below 
because at least one of recipients was rejected by the mail server
Please check the recipients e-mail address before you try again:
[EMAIL PROTECTED]

Original message header:
===

X-eSCM-MailFrom: <[EMAIL PROTECTED]>
X-eSCM-FileID: smtp_47F98599_2F65_.inb
Received: from 201.223.239.79 (201.223.239.79)
by mail.miteni.it (192.100.100.240);
Mon, 07 Apr 2008 04:23:21 +0100
Message-ID: <[EMAIL PROTECTED]>
From: "everett boleslaw" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: =?UTF-8?Q?+++_SPAM_+++__+++_SPAM_+++__New_Britney_pussy_shot?=
Date: Mon, 07 Apr 2008 03:34:13 +
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0007_01C8986F.059D6D64"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

[Bug target/35661] __attribute__((cold)) generates wrong code

[zuxy dot meng at gmail dot com]

--- Comment #3 from zuxy dot meng at gmail dot com  2008-04-07 06:00 ---
Created an attachment (id=15437)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15437&action=view)
Proposed patch against 4.3.0, marking .text.unlikely as executable.


-- 


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

[Bug target/34787] fix -shared + -pthread for mips/linux

[vapier at gentoo dot org]

--- Comment #3 from vapier at gentoo dot org  2008-04-07 06:00 ---
this is in gcc-4.3.0 and that's fine by me


-- 

vapier at gentoo dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug other/35855] New: build locale not properly handled with awk scripts

[vapier at gentoo dot org]

the gcc build system has some awk scripts that use unsafe character ranges:
$ grep a-z gcc/*.awk
gcc/optc-gen.awk:   gsub( "[^A-Za-z0-9_]", "X", macros[i] )
gcc/optc-gen.awk:   gsub ("[^A-Za-z0-9]", "_", enum)
gcc/opt-functions.awk:  gsub ("[^A-Za-z0-9]", "_", name)
gcc/opth-gen.awk:   gsub( "[^A-Za-z0-9_]", "X", macros[i] )
gcc/opth-gen.awk:   gsub ("[^A-Za-z0-9]", "_", enum)

A-Z will not match the expected alphabet (the range as defined by the "C"
locale) in all locales.  while this has always been a problem, it went
unnoticed as the incorrect munging is consistent in nature.  with gcc-4.3, the
incorrect munging results in a conflict of symbols and triggers a build
failure.

i cant seem to find any precedent as to the correct fix.  i would personally
just change everything to [:alnum:], but the only use of such character classes
that i can find via a quick grep is in the lex files.  another solution would
be to execute the awk stuff via configure as it sets up a clean environment. 
or you can prepend "env LC_ALL=C" to the AWK variable setup via configure, but
this ignores the problems that configure solves automatically.


-- 
   Summary: build locale not properly handled with awk scripts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vapier at gentoo dot org


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

gcc-4.3.0 configure can't identify ld 2.18 version

[Yevgeniy Litvinenko]

Hello.

I have binutils 2.18
   $ ld --version
   GNU ld (GNU Binutils) 2.18
   ...

But during compilation of gcc-4.3.0 I get following:

configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING: === You would need to upgrade your binutils to version
configure: WARNING: === 21400 or later and rebuild GCC.
configure: WARNING: === Symbol versioning will be disabled.

I've found out that two configure scripts can not determine the linker
version. These scripts are:
gcc-4.3.0/libstdc++-v3/configure
and
gcc-4.3.0/libgomp/configure

Thanks