[Bug bootstrap/35855] build locale not properly handled with awk scripts

2010-09-25 Thread rwild at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35855

--- Comment #2 from Ralf Wildenhues  2010-09-26 
06:07:56 UTC ---
Proposed patch at .

You don't state how exactly the build fails, and what locale you needed to set
for the failure to become apparent.  That makes it harder to find out whether a
patch fixes it.  Please state so, and also please try out the patch.  Thanks.


[Bug bootstrap/45796] New: make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree

2010-09-25 Thread rwild at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45796

   Summary: make targets info-gcc, dvi-gcc etc. should work from
unbuilt configured tree
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rw...@gcc.gnu.org


Running configure and then 'make info-gcc' currently fails with:

make[1]: Entering directory `/tmp/build/gcc'
make[1]: Circular s-tm-texi <- ../../gcc/gcc/doc/tm.texi dependency dropped.
build/genhooks \
../../gcc/gcc/doc/tm.texi.in > tmp-tm.texi
/bin/sh: line 1: build/genhooks: No such file or directory
make[1]: *** [s-tm-texi] Error 127


It should not be necessary to 'make all' before this.  Likewise for the other
toplevel doc targets.


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

--- Comment #6 from Jerry DeLisle  2010-09-26 
04:17:19 UTC ---
The patch in comment 5 regression tests fine on x86-64.

 Kazumoto Kojima, does this patch fix the problem for you?


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

--- Comment #5 from Jerry DeLisle  2010-09-26 
03:39:17 UTC ---
This patch untested gets rid of the valgrind error I was seeing.

Index: module.c
===
--- module.c(revision 164621)
+++ module.c(working copy)
@@ -5313,7 +5313,6 @@ create_int_parameter_array (const char *name, int
 {
   gfc_symtree *tmp_symtree;
   gfc_symbol *sym;
-  gfc_expr *e;

   tmp_symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
   if (tmp_symtree != NULL)
@@ -5342,8 +5341,8 @@ create_int_parameter_array (const char *name, int
   sym->as->upper[0] = gfc_get_int_expr (gfc_default_integer_kind, NULL, size); 

   sym->value = value;
-  e->shape = gfc_get_shape (1);
-  mpz_init_set_ui (e->shape[0], size);
+  sym->value->shape = gfc_get_shape (1);
+  mpz_init_set_ui (sym->value->shape[0], size);
 }

Can someone familiar with module.c see if this makes sense for the intended
purpose.  I will start regression testing.


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

--- Comment #4 from Jerry DeLisle  2010-09-26 
03:33:09 UTC ---
This is the same location I was seeing the failure before. Now I have no
segfault, but valgind shows:

==17145== 48 (32 direct, 16 indirect) bytes in 2 blocks are definitely lost in
loss record 48 of 459
==17145==at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==17145==by 0xCCBB27: xmalloc (xmalloc.c:147)
==17145==by 0x4F4504: gfc_getmem (misc.c:37)
==17145==by 0x4F6E0A: create_int_parameter_array.constprop.22
(module.c:5345)
==17145==by 0x4F7629: use_iso_fortran_env_module (iso-fortran-env.def:91)
==17145==by 0x4FBA2E: gfc_use_module (module.c:5541)
==17145==by 0x4FFCF4: accept_statement (parse.c:1574)
==17145==by 0x502A8A: parse_spec (parse.c:2588)
==17145==by 0x504818: parse_progunit (parse.c:3922)
==17145==by 0x50560B: gfc_parse_file (parse.c:4329)
==17145==by 0x53CBF7: gfc_be_parse_file (f95-lang.c:242)
==17145==by 0x83329F: toplev_main (toplev.c:955)
==17145== 

Look at the code. e is declared in the function as typr gfc_expr *
Unfortunately no pointer is ever allocated for it.  It is just luck that it is
not segfaulting!

static void
create_int_parameter_array (const char *name, int size, gfc_expr *value,
const char *modname, intmod_id module, int id)
{
  gfc_symtree *tmp_symtree;
  gfc_symbol *sym;
  gfc_expr *e;

  tmp_symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
  if (tmp_symtree != NULL)
{
  if (strcmp (modname, tmp_symtree->n.sym->module) == 0)
return;
  else
gfc_error ("Symbol '%s' already declared", name);
}

  gfc_get_sym_tree (name, gfc_current_ns, &tmp_symtree, false);
  sym = tmp_symtree->n.sym;

  sym->module = gfc_get_string (modname);
  sym->attr.flavor = FL_PARAMETER;
  sym->ts.type = BT_INTEGER;
  sym->ts.kind = gfc_default_integer_kind;
  sym->attr.use_assoc = 1;
  sym->from_intmod = module;
  sym->intmod_sym_id = id;
  sym->attr.dimension = 1;
  sym->as = gfc_get_array_spec ();
  sym->as->rank = 1;
  sym->as->type = AS_EXPLICIT;
  sym->as->lower[0] = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
  sym->as->upper[0] = gfc_get_int_expr (gfc_default_integer_kind, NULL, size); 

  sym->value = value;
  e->shape = gfc_get_shape (1);
  mpz_init_set_ui (e->shape[0], size);
}


[Bug rtl-optimization/45788] -fwhole-program causes ICE error: BB 3 can not throw but has an EH edge

2010-09-25 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45788

--- Comment #5 from Zdenek Sojka  2010-09-26 02:10:54 
UTC ---
Thank you. From my experience, I tried to upload attachment in the original
report ~3 times, once (PR45768) it failed. I wasn't sure if that was my fault
or not, so I haven't reported it.


[Bug c++/43601] Enormous increase in DLL object files size in 4.5

2010-09-25 Thread cestrauss at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601

--- Comment #28 from Cesar Strauss  2010-09-26 
01:11:57 UTC ---
(In reply to comment #25)

>   So I would like to see some proper detailed analysis on object files
> establishing exactly what constitutes all this bloat and where it comes from
> before I commit to what might be the wrong path of action.

Here is a comparison of the output of objdump -h for two compiler versions.
The source is src/common/any.cpp from wxWidgets 2.9.1.
The GCC compilers were downloaded from mingw.org.

GCC 4.5.0 (4.4.0)

Total object file size in bytes: 1,080,971 (110,037)

Total number of sections: 3,062 (318)
Number of:
LINK_ONCE_DISCARD .text$xxx sections: 2,887 (145)
LINK_ONCE_SAME_SIZE typeinfo .rdata$xxx sections: 128 (128)
LINK_ONCE_SAME_SIZE vtable .rdata$xxx sections: 36 (35)
.data$xxx sections: 3 (2)

Size of:
.text: 5,692 (5,308)
.data: 0 (0)
.bss: 72 (88)
.rdata: 2,432 (448)
.gcc_except_table: 5,232 (572)
.ctors: 4 (4)
.eh_frame: 41,996 (2,340)
.drectve: 126,440 (5,416)

Total size of:
LINK_ONCE_DISCARD .text$xxx sections: 132,344 (6,004)
LINK_ONCE_SAME_SIZE typeinfo .rdata$xxx sections: 2,552 (2,552)
LINK_ONCE_SAME_SIZE vtable .rdata$xxx sections: 1,184 (1,160)
.data$xxx sections: 76 (12)

Let me know if you need further info.

I hope this is helpful.

Thanks,
Cesar


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

Kazumoto Kojima  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2010.09.25 23:16:59
   date||
 CC||kkojima at gcc dot gnu.org
 Resolution|INVALID |
 Ever Confirmed|0   |1

--- Comment #3 from Kazumoto Kojima  2010-09-25 
23:16:59 UTC ---
I've got similar failures on cross sh4-linux.  gfortran.log says
that f951 segfaults for these tests.  gdb shows that the segfault
happens at

Program received signal SIGSEGV, Segmentation fault.
0x0811130c in create_int_parameter_array (name=, size=2, 
value=0x8b18bb0, id=22, module=, 
modname=)
at ../../ORIG/trunk/gcc/fortran/module.c:5345
5345  e->shape = gfc_get_shape (1);

When building f951, there was a warning

../trunk/gcc/fortran/module.c: In function 'create_int_parameter_array':
../trunk/gcc/fortran/module.c:5346: warning: 'e' may be used uninitialized in
this function

with my fedora environment.  It looks that there is still something wrong.


[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

2010-09-25 Thread margali at imapmail dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248

--- Comment #8 from margali at imapmail dot org 2010-09-25 22:43:38 UTC ---
(In reply to comment #5)
> At least one fink-user has reported that Jack's latest packaging that
> automatically uses --with-dwarf2 on darwin8 builds successfully (was on a G5,
> built -j4).  (My builds were aborted for other reasons, still working on it on
> my G4.)  Jack, do you plan to submit your configure{,.ac} patch, or just keep
> it only in your package patch?

I tried adding the flag directly into configure and rebuilding in a clean
directory. This doesn't get as far as the standard configure, however, because
of complaints from ld64:
libtool: link: rm -fr  .libs/libgcj.lax
libtool: link: (cd .libs/libgcj.lax/libltdlc.a && ar x
"/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libjava/./libltdl/.libs/libltdlc.a")
libtool: link: (cd .libs/libgcj.lax/libfdlibm.a && ar x
"/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libjava/classpath/native/fdlibm/.libs/libfdlibm.a")
libtool: link: (cd .libs/libgcj.lax/libffi_convenience.a && ar x
"/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libjava/../libffi/.libs/libffi_convenience.a")
libtool: link: (cd .libs/libgcj.lax/libzgcj_convenience.a && ar x
"/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libjava/../zlib/.libs/libzgcj_convenience.a")
libtool: link: (cd .libs/libgcj.lax/libgcjgc_convenience.a && ar x
"/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libjava/../boehm-gc/.libs/libgcjgc_convenience.a")
libtool: link: /Users/cfrees/Documents/src/gcc/build-gcc/./gcc/xgcc
-shared-libgcc -B/Users/cfrees/Documents/src/gcc/build-gcc/./gcc -nostdinc++
-L/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libstdc++-v3/src
-L/Users/cfrees/Documents/src/gcc/build-gcc/powerpc-apple-darwin8.11.0/ppc64/libstdc++-v3/src/.libs
-B/usr/local/powerpc-apple-darwin8.11.0/bin/
-B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem
/usr/local/powerpc-apple-darwin8.11.0/include -isystem
/usr/local/powerpc-apple-darwin8.11.0/sys-include  -m64 -dynamiclib
-Wl,-undefined -Wl,dynamic_lookup -o .libs/libgcj.11.dylib  .libs/prims.o
.libs/jni.o .libs/exception.o .libs/stacktrace.o .libs/link.o
.libs/defineclass.o .libs/verify.o .libs/jvmti.o .libs/interpret.o
gnu/classpath/jdwp/.libs/natVMFrame.o gnu/classpath/jdwp/.libs/natVMMethod.o
gnu/classpath/jdwp/.libs/natVMVirtualMachine.o
gnu/classpath/.libs/natConfiguration.o
gnu/classpath/.libs/natSystemProperties.o
gnu/classpath/.libs/natVMStackWalker.o gnu/gcj/.libs/natCore.o
gnu/gcj/convert/.libs/JIS0208_to_Unicode.o
gnu/gcj/convert/.libs/JIS0212_to_Unicode.o
gnu/gcj/convert/.libs/Unicode_to_JIS.o gnu/gcj/convert/.libs/natIconv.o
gnu/gcj/convert/.libs/natInput_EUCJIS.o gnu/gcj/convert/.libs/natInput_SJIS.o
gnu/gcj/convert/.libs/natOutput_EUCJIS.o gnu/gcj/convert/.libs/natOutput_SJIS.o
gnu/gcj/io/.libs/natSimpleSHSStream.o gnu/gcj/io/.libs/shs.o
gnu/gcj/jvmti/.libs/natBreakpoint.o gnu/gcj/jvmti/.libs/natNormalBreakpoint.o
gnu/gcj/runtime/.libs/natFinalizerThread.o
gnu/gcj/runtime/.libs/natSharedLibLoader.o
gnu/gcj/runtime/.libs/natSystemClassLoader.o
gnu/gcj/runtime/.libs/natStringBuffer.o gnu/gcj/util/.libs/natDebug.o
gnu/gcj/util/.libs/natGCInfo.o gnu/java/lang/.libs/natMainThread.o
gnu/java/lang/management/.libs/natVMClassLoadingMXBeanImpl.o
gnu/java/lang/management/.libs/natVMCompilationMXBeanImpl.o
gnu/java/lang/management/.libs/natVMGarbageCollectorMXBeanImpl.o
gnu/java/lang/management/.libs/natVMMemoryMXBeanImpl.o
gnu/java/lang/management/.libs/natVMMemoryManagerMXBeanImpl.o
gnu/java/lang/management/.libs/natVMMemoryPoolMXBeanImpl.o
gnu/java/lang/management/.libs/natVMOperatingSystemMXBeanImpl.o
gnu/java/lang/management/.libs/natVMRuntimeMXBeanImpl.o
gnu/java/lang/management/.libs/natVMThreadMXBeanImpl.o
gnu/java/net/.libs/natPlainDatagramSocketImpl.o
gnu/java/net/.libs/natPlainSocketImpl.o
gnu/java/net/protocol/core/.libs/natCoreInputStream.o
gnu/java/nio/.libs/natVMPipe.o gnu/java/nio/.libs/natVMSelector.o
gnu/java/nio/.libs/natNIOServerSocket.o gnu/java/nio/.libs/natVMChannel.o
gnu/java/nio/channels/.libs/natFileChannelImpl.o
gnu/java/security/jce/prng/.libs/natVMSecureRandom.o java/io/.libs/natFile.o
java/io/.libs/natVMObjectInputStream.o java/io/.libs/natVMObjectStreamClass.o
java/lang/.libs/natCharacter.o java/lang/.libs/natClass.o
java/lang/.libs/natClassLoader.o java/lang/.libs/natConcreteProcess.o
java/lang/.libs/natVMDouble.o java/lang/.libs/natVMFloat.o
java/lang/.libs/natMath.o java/lang/.libs/natObject.o
java/lang/.libs/natRuntime.o java/lang/.libs/natString.o
java/lang/.libs/natAbstractStringBuffer.o java/lang/.libs/natSystem.o
java/lang/.libs/natThread.o java/lang/.libs/natThreadLocal.o
java/lang/.libs/natVMClassLoader.o java/lang/.libs/natVMProcess.o
java/lang/.libs/natVMThrowable.o java/lang/ref/.libs/natReference.o
java/lang/reflect/.

[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()

2010-09-25 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569

--- Comment #4 from Tobias Burnus  2010-09-25 
22:43:13 UTC ---
Patch: http://gcc.gnu.org/ml/fortran/2010-09/msg00455.html


[Bug fortran/40568] F2008: C_SIZEOF is in the wrong scope, rejected as initialization expression

2010-09-25 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568

--- Comment #5 from Tobias Burnus  2010-09-25 
22:42:38 UTC ---
Patch for the issue in comment 0:
http://gcc.gnu.org/ml/fortran/2010-09/msg00455.html

TODO: Issue mentioned in comment 1: C_SIZEOF in init expressions.


[Bug tree-optimization/45791] Missed devirtualization

2010-09-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791

--- Comment #5 from Jan Hubicka  2010-09-25 
22:17:41 UTC ---
Another testcase where we devirtualize via folding is:
// { dg-do assemble  }
// { dg-options "-g -O2" }

//  Copyright (C) 1999 Free Software Foundation, Inc.
//  Contributed by Nathan Sidwell 21 Nov 1999 

// This causes assember relocation errors

struct X
{
  virtual ~X () {}
};

struct Y
{
  Y (){};
};

void foo ()
{
  X *x = new X;
  x->~X ();
  Y ys[2];
}

compiled with -O2 we get
  x_3 = operator new (8);
  # DEBUG this => x_3
  x_3->_vptr.X = &_ZTV1X[2];
  # DEBUG x => x_3 
  D.2142_7 = (int (*__vtbl_ptr_type) (void)) __comp_dtor ;
  OBJ_TYPE_REF(D.2142_7;x_3->0) (x_3);
that gets folded only in ccp3. We need FRE to fold:
  x_3->_vptr.X = &_ZTV1X[2];
  # DEBUG x => x_3
  D.2141_6 = &_ZTV1X[2];
  D.2142_7 = *D.2141_6;
  OBJ_TYPE_REF(D.2142_7;x_3->0) (x_3);
into
  x_3 = operator new (8);
  # DEBUG this => x_3
  x_3->_vptr.X = &_ZTV1X[2];
  # DEBUG x => x_3
  D.2141_6 = x_3->_vptr.X;
  D.2142_7 = *D.2141_6;
  OBJ_TYPE_REF(D.2142_7;x_3->0) (x_3);


[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

2010-09-25 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.25 22:14:30
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Hans-Peter Nilsson  2010-09-25 
22:14:30 UTC ---
FWIW I had a private report that it also happens with host i686-darwin9 target
cris-elf, at r165605.


[Bug tree-optimization/45791] Missed devirtualization

2010-09-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791

--- Comment #4 from Jan Hubicka  2010-09-25 
22:12:39 UTC ---
Note that the patch attached solves one indirect call in the testcase but has
no effect on mozilla.


[Bug tree-optimization/45791] Missed devirtualization

2010-09-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791

--- Comment #3 from Jan Hubicka  2010-09-25 
22:10:15 UTC ---
Hmm,
normally we should see it from COMPONENT_REF:
  while (true)
{
  if (TREE_CODE (ref) == COMPONENT_REF)
{
  tree par_type;
  tree binfo, base_binfo;
  tree field = TREE_OPERAND (ref, 1);

  if (!DECL_ARTIFICIAL (field))
{
  tree type = TREE_TYPE (field);
  if (TREE_CODE (type) == RECORD_TYPE)
return TYPE_BINFO (type);
  else
return NULL_TREE;
}
but we don't since it has DECL_ARTIFICIAL set.  What is the logic here?
Also what about i.e. ARRAY_REF and arrays of objects and COMPONENT_REFs
translated to MEM_REFs?

Honza


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jerry DeLisle  2010-09-25 
21:31:56 UTC ---
Resolved by enabling bootstrap


[Bug fortran/45783] [4.6 Regression] ICE in gfc_add_component_ref, at fortran/class.c:77

2010-09-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45783

--- Comment #3 from Dominique d'Humieres  2010-09-25 
21:21:46 UTC ---
pr45795 is very likely a duplicate of this one.


[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message

2010-09-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795

--- Comment #2 from Dominique d'Humieres  2010-09-25 
21:21:19 UTC ---
It is very likely a duplicate of pr45783.


[Bug fortran/45795] New: [OOP] ICE in in gfc_add_component_ref plus bogus error message

2010-09-25 Thread sfilippone at uniroma2 dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795

   Summary: [OOP] ICE in in gfc_add_component_ref plus bogus error
message
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sfilipp...@uniroma2.it


Created attachment 21886
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21886
test case

Hello,
This was working until a few days ago, now it's broken: the compiler gives a
bogus error message, and then ICEs. 
Trunk at r164617:

[sfili...@localhost bug24]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured)
../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran,lto --no-create
--no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100925 (experimental) (GCC) 
[sfili...@localhost bug24]$ gfortran -c bug24.f03  
bug24.f03:68.10:

call b%cp_to_foo(tmp,info)
  1
Error: Type mismatch in argument 'a' at (1); passed CLASS(base) to
CLASS(s_base)
bug24.f03:11:0: internal compiler error: in gfc_add_component_ref, at
fortran/class.c:77
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


[Bug fortran/45793] [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

--- Comment #1 from Jerry DeLisle  2010-09-25 
20:01:14 UTC ---
Others can not confirm this so I am checking local configuration.


[Bug objc++/35551] internal compiler error: in encode_gnu_bitfield, at objc/objc-act.c:8175

2010-09-25 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35551

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #2 from Nicola Pero  2010-09-25 19:57:08 
UTC ---
I can't open the attachment - gunzip complains that it is incomplete.  If you
still have it, can you resend it ?

Thanks


[Bug rtl-optimization/45788] -fwhole-program causes ICE error: BB 3 can not throw but has an EH edge

2010-09-25 Thread astrange at ithinksw dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45788

--- Comment #4 from Alexander Strange  2010-09-25 
19:50:29 UTC ---
I (probably) definitely attached it, is the attachment form in the new bugs
page not working?


[Bug fortran/45794] [4.6 Regression] ICE: Segmentation fault in gfc_conv_procedure_call

2010-09-25 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45794

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.5.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2010.09.25 19:08:10
   date||
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|internal compiler error:|[4.6 Regression] ICE:
   |Segmentation fault  |Segmentation fault in
   ||gfc_conv_procedure_call
   Target Milestone|--- |4.6.0
  Known to fail||4.6.0

--- Comment #1 from Tobias Burnus  2010-09-25 
19:08:10 UTC ---
Fails with 4.6.0 Rev. 163668 and 164548
Works with 4.5.0

==16264== Invalid read of size 4
==16264==at 0x57F655: gfc_conv_procedure_call (trans-expr.c:3119)
==16264==by 0x582FD8: gfc_conv_intrinsic_funcall (trans-intrinsic.c:1844)
==16264==by 0x58D423: gfc_conv_intrinsic_function (trans-intrinsic.c:5595)
==16264==by 0x581642: gfc_conv_function_expr (trans-expr.c:3914)
==16264==by 0x582534: gfc_trans_assignment (trans-expr.c:5370)
==16264==by 0x558B45: trans_code (trans.c:1119)

Breakpoint 1, gfc_conv_procedure_call (se=0x7fffd3f0, sym=0x144c350,
args=0x13f7d80, expr=0x144baf0, append_args=0x0)
at fortran/trans-expr.c:3119
3119   && (fsym == NULL || fsym->as->type ==
AS_ASSUMED_SHAPE
(gdb) p fsym
$1 = (gfc_symbol *) 0x1449580
(gdb) p fsym->name
$2 = 0x2d4fcf40 "mask"
(gdb) p fsym->as
$3 = (gfc_array_spec *) 0x0
(gdb) p fsym->attr.dimension 
$4 = 0


[Bug plugins/45787] r164531 breaks plugin support on x86_64-apple-darwin10

2010-09-25 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787

--- Comment #4 from Jack Howarth  2010-09-25 
19:06:18 UTC ---
Thanks! Adding...

Index: gcc/config/darwin.opt
===
--- gcc/config/darwin.opt(revision 164620)
+++ gcc/config/darwin.opt(working copy)
@@ -45,3 +45,6 @@
 iframework
 Target RejectNegative C ObjC C++ ObjC++ Joined Separate 
 -iframework Add  to the end of the system framework include path
+
+undefined
+Driver Separate

...eliminates issue with the autohost.h in all stages of the gcc build now
reporting...

/* Define to enable plugin support. */
#ifndef USED_FOR_TARGET
#define ENABLE_PLUGIN 1
#endif

...as expected and the plugin directory is once again installed in
lib/gcc/x86_64-apple-darwin10.4.0/4.6.0.


[Bug fortran/45794] New: internal compiler error: Segmentation fault

2010-09-25 Thread neil.n.carlson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45794

   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: neil.n.carl...@gmail.com


The following code causes an internal compiler error with the
current trunk:

$ gfortran --version
GNU Fortran (GCC) 4.6.0 20100924 (experimental)

subroutine foo (vector, mask)
  real :: vector(:)
  logical, optional :: mask(:)
  integer :: loc(1)
  if (present(mask)) then
loc = maxloc(vector, mask)
  end if
end subroutine

$ gfortran -c bug3.f90 
bug3.f90: In function ‘foo’:
bug3.f90:6:0: internal compiler error: Segmentation fault

Note that this bug does not exist in 4.4 (or 4.5 I think).


[Bug rtl-optimization/45394] [4.6 regression] gnat fails to build on s390, trunk 20100918

2010-09-25 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45394

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |rtl-optimization

--- Comment #6 from Eric Botcazou  2010-09-25 
17:46:49 UTC ---
The combiner swaps 2 insns.  Before:

(debug_insn 227 226 228 42 (var_location:SI D.1502 (reg:SI 85 [ D.1501 ]))
p.adb:21 -1
 (nil))

(insn 228 227 229 42 (set (mem/s/j:SI (reg/f:SI 84 [ D.1519 ]) [7
D.1519_197->BOUNDS.LB0+0 S4 A32])
(reg:SI 85 [ D.1501 ])) p.adb:21 67 {*movsi_esa}
 (expr_list:REG_DEAD (reg:SI 85 [ D.1501 ])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil

After:

(insn 228 226 227 42 (parallel [
(set (mem/s/j:SI (reg/f:SI 84 [ D.1519 ]) [7
D.1519_197->BOUNDS.LB0+0 S4 A32])
(plus:SI (reg/v:SI 63 [ p__current_parameter__B_1__TTpSP1___L
])
(const_int 1 [0x1])))
(clobber (reg:CC 33 %cc))
]) p.adb:21 250 {*addsi3}
 (expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_DEAD (reg/v:SI 63 [
p__current_parameter__B_1__TTpSP1___L ])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)

(debug_insn 227 228 229 42 (var_location:SI D.1502 (mem/s/j:SI (reg/f:SI 84 [
D.1519 ]) [7 D.1519_197->BOUNDS.LB0+0 S4 A32])) p.adb:21 -1
 (nil))


[Bug plugins/45787] r164531 breaks plugin support on x86_64-apple-darwin10

2010-09-25 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45787

--- Comment #3 from joseph at codesourcery dot com  2010-09-25 17:28:29 UTC ---
Try adding an option entry

undefined
Driver Separate

to darwin.opt.


[Bug ada/45394] [4.6 regression] gnat fails to build on s390, trunk 20100918

2010-09-25 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45394

--- Comment #5 from Eric Botcazou  2010-09-25 
17:22:21 UTC ---
The workaround is to remove -g from the command line.


[Bug fortran/45793] New: [4.6 Regressions] Numerous test-suite failures

2010-09-25 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45793

   Summary: [4.6 Regressions]  Numerous test-suite failures
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jvdeli...@gcc.gnu.org


These appear to be on x86-64.

FAIL: gfortran.dg/iso_fortran_env_3.f90  -Os  (internal compiler error)

FAIL: gfortran.dg/iso_fortran_env_4.f90  -O  (internal compiler error)

FAIL: gfortran.dg/use_3.f90  -O  (internal compiler error)

FAIL: gfortran.dg/use_rename_6.f90  -O  (internal compiler error)

FAIL: gfortran.dg/is_iostat_end_eor_1.f90  -Os  (internal compiler error)

etc


[Bug tree-optimization/45791] Missed devirtualization

2010-09-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791

Jan Hubicka  changed:

   What|Removed |Added

 Blocks||45375

--- Comment #2 from Jan Hubicka  2010-09-25 
16:52:25 UTC ---
The 800 missed devirtualizations on Mozilla seems to be mostly AddRef that I
can imagine is exactly this case of reference counting in constructor.


[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

2010-09-25 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


[Bug rtl-optimization/45792] New: [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374

2010-09-25 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792

   Summary: [4.6 Regression]: cris-elf build failure (hangs) due
to fix for PR44374
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: ber...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: cris-*-*


Created attachment 21882
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21882
Preprocessed dtoa.c

At r164551 the tree built with few regressions.
At r164560 building newlib/libc/stdlib/dtoa.c hangs (cpu-time > 38 hours) and
at r164619 the build is at a similar state (didn't wait 38 hours, but see
below).

Attaching a gdb-session to the running cc1 at r164619 shows an infinite loop in
gcc/emit-rtl.c:reorder_insns:

4027  for (x = from; x != NEXT_INSN (to); x = NEXT_INSN (x))
4028if (!BARRIER_P (x))
4029  df_insn_change_bb (x, bb);

But "x" is bogus; it seems to have been deleted or at least removed from the
insn stream:
(insn 2210 2210 2210 239 (set (cc0)
(compare (reg/v/f:SI 3 r3 [orig:95 mlo ] [95])
(reg/v/f:SI 4 r4 [orig:97 mhi ] [97])))
/tmp/hpautotest-gcc1/gcc/newlib/libc/stdlib/dtoa.c:808 11 {*cmpsi}
 (nil))

The call to df_insn_change_bb takes the (old_bb == new_bb) early return.

Author of suspect patch in revision range CC:ed.
Preprocessed dtoa.c attached.  Compile with -O2.


[Bug web/45769] Bugzilla help doesn't match actual fields

2010-09-25 Thread LpSolit at netscape dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45769

Frédéric Buclin  changed:

   What|Removed |Added

 CC||LpSolit at netscape dot net

--- Comment #3 from Frédéric Buclin  2010-09-25 
16:45:57 UTC ---
I removed the OS and platform fields (enclosed in ). I will let a @gcc
guy add the 6 custom fields to the list, because they know better than me what
these fields are used for.


[Bug web/45778] Append summary information instead of prepending the information

2010-09-25 Thread LpSolit at netscape dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778

--- Comment #7 from Frédéric Buclin  2010-09-25 
16:40:37 UTC ---
OK, signature removed for the mailing-lists.


[Bug tree-optimization/45791] New: Missed devirtualization

2010-09-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791

   Summary: Missed devirtualization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


Compiling
// PR rtl-optimization/36185
// { dg-do run }
// { dg-options "-O2 -fgcse-sm" }

struct Base {
virtual ~Base() {}
virtual void f() = 0;
};
struct Derived : Base {
Derived();
virtual void f() {}
};
struct Foo {
Foo(Base&);
};
Derived::Derived() {
Foo foo(*this);
}
Foo::Foo(Base& base) {
base.f();
}
int main() {
Derived d;
}

makes einline to produce:
  MEM[(struct Base *)&d]._vptr.Base = &_ZTV4Base[2];
  d.D.2114._vptr.Base = &_ZTV7Derived[2];
  D.2243_5 = &d.D.2114;
  D.2241_6 = MEM[(struct Base *)&d]._vptr.Base;
  D.2242_7 = MEM[(int (*__vtbl_ptr_type) (void) *)D.2241_6 + 16B];
  OBJ_TYPE_REF(D.2242_7;D.2243_5->2) (D.2243_5);
this should get devirtualized but doesn't

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug web/45778] Append summary information instead of prepending the information

2010-09-25 Thread LpSolit at netscape dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.25 15:33:31
   date||
 CC||LpSolit at netscape dot net
 Ever Confirmed|0   |1

--- Comment #6 from Frédéric Buclin  2010-09-25 
15:33:31 UTC ---
(In reply to comment #5)
> There are numerous examples of people who simply hit
> reply, add their text, and hit send without editing
> the original text.

And that's the problem. With or without the signature being present, the most
annoying part is all these useless quoted lines which are irrelevant to the
reply. Imagine someone replying to your comment 0, and leaving the quoted
message alone. The 4 lines of the signature are honestly a peanut compared to
the 50 lines or so of the original comment, and wouldn't be responsible for the
clutter.

But I'm going to remove the signature for the mailing-lists, so that people
won't complain anymore.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug web/45778] Append summary information instead of prepending the information

2010-09-25 Thread sgk at troutmask dot apl.washington.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778

--- Comment #5 from Steve Kargl  
2010-09-25 15:01:19 UTC ---
On Sat, Sep 25, 2010 at 09:04:32AM +, LpSolit at netscape dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778
> 
> --- Comment #3 from Fr??d??ric Buclin  
> 2010-09-25 09:04:24 UTC ---
> (In reply to comment #2)
> > I also think that the last four lines quoted above should 
> > go away.  Do we really need the 150+ byte message tacked
> > onto ever message posted in bugzilla?
> 
> If you are complaining about emails being 150 bytes too large, that's a pretty
> weak reason. Also, these 4 lines are in the signature of the email. Any good
> email client would display them in a less prominent way, e.g. Thunderbird.
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

So, how do I selectively strip of these signatures
with mutt and elm and leave all other signatures
that I want to see alone?

Are you saying that you do not find 

http://gcc.gnu.org/ml/gcc-bugs/2010-09/msg02740.html

to be too cluttered?.  Yes, some of us do use the 
email archive to read old threads.  With this email
there will now be 7 copies of the signature in the 
archive (not counting the 3 examples purposely included
in the text of the email for discussion).

How are you going to force people into trimming their
replies to emails to carefully remove the signature?
There are numerous examples of people who simply hit
reply, add their text, and hit send without editing
the original text.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug rtl-optimization/45788] -fwhole-program causes ICE error: BB 3 can not throw but has an EH edge

2010-09-25 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45788

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #2 from Zdenek Sojka  2010-09-25 14:47:19 
UTC ---
Please reupload the testcase, it didn't appear here. Thanks

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug fortran/45776] Full implementation of variable definition contexts (and related checks)

2010-09-25 Thread domob at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45776

--- Comment #3 from Daniel Kraft  2010-09-25 14:30:58 
UTC ---
This implemented all IO related checks (items 5-10), so only missing are now 14
and 15 which are the LOCK/UNLOCK related ones.  These depend on implementation
of locks in PR 18918, so I'm waiting for that now.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug fortran/45777] Missing temporary ?

2010-09-25 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45777

--- Comment #5 from Tobias Burnus  2010-09-25 
14:30:55 UTC ---
The issue seems to be how alias checking is implemented in trans-array.c:

gfc_could_be_alias (gfc_ss * lss, gfc_ss * rss)
[...]
  for (rref = rss->expr->ref; rref != rss->data.info.ref; rref = rref->next)
{
  if (gfc_symbols_could_alias (rref->u.c.sym, lsym))
return 1;
}

While "rss->expr->symtree->n.sym" (= "rsym") has the pointer and target
attribute, the element "rref->u.c.sym" usually has not.

Thus, the gfc_symbols_could_alias check succeeds (first argument is neither a
pointer nor a target thus it cannot alias with the second argument, unless both
symbol are the same); cf. symbol.c's

gfc_symbols_could_alias (gfc_symbol *lsym, gfc_symbol *rsym)
[...]
  if (lsym->attr.pointer
  && (rsym->attr.pointer || rsym->attr.allocatable || rsym->attr.target))
return 1;
  if (lsym->attr.target && rsym->attr.pointer)
return 1;
  if (lsym->attr.allocatable && rsym->attr.pointer)
return 1;
[...]
  return 0;

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug fortran/45776] Full implementation of variable definition contexts (and related checks)

2010-09-25 Thread domob at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45776

--- Comment #2 from Daniel Kraft  2010-09-25 14:27:27 
UTC ---
Author: domob
Date: Sat Sep 25 14:27:20 2010
New Revision: 164619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164619
Log:
2010-09-25  Daniel Kraft  

PR fortran/45776
* gfortran.h (struct gfc_dt): New member `dt_io_kind'.
* io.c (resolve_tag): F2008 check for NEWUNIT and variable
definition checks for NEWUNIT, IOSTAT, SIZE and IOMSG.
(gfc_free_dt): Correctly handle freeing of `dt_io_kind' and
`extra_comma' with changed semantics.
(gfc_resolve_dt): Check variable definitions.
(match_io_element): Remove INTENT and PURE checks here and
initialize code->ext.dt member.
(match_io): Set dt->dt_io_kind.
(gfc_resolve_inquire): Check variable definition for all tags
except UNIT, FILE and ID.
* resolve.c (resolve_transfer): Variable definition check.

2010-09-25  Daniel Kraft  

PR fortran/45776
* gfortran.dg/io_constraints_6.f03: New test.
* gfortran.dg/io_constraints_7.f03: New test.
* gfortran.dg/newunit_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/io_constraints_6.f03
trunk/gcc/testsuite/gfortran.dg/io_constraints_7.f03
trunk/gcc/testsuite/gfortran.dg/newunit_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()

2010-09-25 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569

--- Comment #3 from Tobias Burnus  2010-09-25 
12:34:38 UTC ---
First part of an implementation.

TODO: (a) Use a module rather than the normal name space. (b) Get the command
line options; cf. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02006.html

--- intrinsic.c (Revision 164618)
+++ intrinsic.c (Arbeitskopie)
@@ -2613,0 +2615,6 @@ add_functions (void)
+
+/* MOVE TO MODULE: ISO_FORTRAN_ENV.  */
+  add_sym_0 ("compiler_options", GFC_ISYM_COMPILER_VERSION, CLASS_IMPURE,
ACTUAL_NO, BT_CHARACTER,
+1, GFC_STD_F2008, NULL, gfc_simplify_compiler_options, NULL);
+  add_sym_0 ("compiler_version", GFC_ISYM_COMPILER_VERSION, CLASS_IMPURE,
ACTUAL_NO, BT_CHARACTER,
+1, GFC_STD_F2008, NULL, gfc_simplify_compiler_version, NULL);
--- simplify.c  (Revision 164618)
+++ simplify.c
@@ -29,2 +29,3 @@ along with GCC; see the file COPYING3.
 #include "constructor.h"
+#include "version.h"  /* For version_string.  */

@@ -6735 +6736,17 @@ gfc_convert_char_constant (gfc_expr *e,
 }
+
+
+gfc_expr *
+gfc_simplify_compiler_options (void)
+{
+  return NULL;
+}
+
+
+gfc_expr *
+gfc_simplify_compiler_version (void)
+{
+  return gfc_get_character_expr (gfc_default_character_kind,
+&gfc_current_locus, version_string,
+strlen (version_string));
+}

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811

2010-09-25 Thread mikpe at it dot uu.se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557

--- Comment #7 from Mikael Pettersson  2010-09-25 
11:51:17 UTC ---
The default_secondary_reload ICE still triggers on trunk (4.6 r164610) if you
target Thumb-1:

> objdir/gcc/xgcc -Bobjdir/gcc -march=armv7-a -mthumb -O1 
> -fno-omit-frame-pointer -fno-forward-propagate -S pr44557.i
> objdir/gcc/xgcc -Bobjdir/gcc -march=armv5te -mthumb -O1 
> -fno-omit-frame-pointer -fno-forward-propagate -S pr44557.i
omDefault.c: In function '_XmbDefaultTextPerCharExtents':
omDefault.c:272:1: internal compiler error: in default_secondary_reload, at
targhooks.c:907
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
> uname -a
Linux brewer 2.6.36-rc5 #1 SMP Thu Sep 23 12:39:05 CEST 2010 i686 i686 i386
GNU/Linux
> objdir/gcc/xgcc -v
> Using built-in specs.
COLLECT_GCC=objdir/gcc/xgcc
Target: armv5tel-unknown-linux-gnueabi
Configured with: /tmp/gcc-4.6-r164610/configure
--target=armv5tel-unknown-linux-gnueabi --with-arch=armv5te --with-tune=xscale
--prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugins --disable-lto
--disable-nls --disable-shared --disable-libmudflap --disable-multilib
--enable-threads=posix --enable-checking=release --enable-languages=c
Thread model: posix
gcc version 4.6.0 20100924 (experimental) (GCC)

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-25 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #58 from Paolo Carlini  2010-09-25 
11:09:20 UTC ---
Fixed for 4.6.0.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug lto/45790] New: 1308 new GCC h...@164592 regressions

2010-09-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790

   Summary: 1308 new GCC h...@164592 regressions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


On powerpc-apple-darwin9 at revision 164592, most (all?) the tests with -flto
of -fwhopr fail with

lto1: fatal error: target specific builtin not available

(see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02251.html ).

Last known working revision is r164531 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02113.html ).

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug web/45778] Append summary information instead of prepending the information

2010-09-25 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  2010-09-25 
10:34:23 UTC ---
the web archive doesn't show signatures in a less prominent way, and the "you
are receiving this mail because" and the userprefs URL are misleading on the
archived mails

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug web/45778] Append summary information instead of prepending the information

2010-09-25 Thread LpSolit at netscape dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778

--- Comment #3 from Frédéric Buclin  2010-09-25 
09:04:24 UTC ---
(In reply to comment #2)
> I also think that the last four lines quoted above should 
> go away.  Do we really need the 150+ byte message tacked
> onto ever message posted in bugzilla?

If you are complaining about emails being 150 bytes too large, that's a pretty
weak reason. Also, these 4 lines are in the signature of the email. Any good
email client would display them in a less prominent way, e.g. Thunderbird.

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


[Bug lto/45789] New: [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()

2010-09-25 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789

   Summary: [4.6 Regression] ICE: tree code 'lang_type' is not
supported in gimple streams with -flto when using
__builtin_printf()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Compiler output:
$ gcc -flto testcase.C   
testcase.C:6:19: internal compiler error: tree code 'lang_type' is not
supported in gimple streams
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gcc -fwhopr testcase.C
testcase.C:6:19: internal compiler error: tree code 'lang_type' is not
supported in gimple streams
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

- testcase.C -
void foo ()
{
  __builtin_printf (0);
}
typedef int format;
--

Tested revisions:
r164561 - crash
r163636 - crash
r161659 - OK
r159696 - OK
4.5 r163761 - OK

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.