[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE

2009-10-25 Thread janus at gcc dot gnu dot org


--- Comment #5 from janus at gcc dot gnu dot org  2009-10-25 10:24 ---
(In reply to comment #4)
> internal compiler error: in tree_annotate_all_with_location, at gimplify.c:892

This goes away with the following patchlet:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 153538)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -4888,7 +4888,10 @@ gfc_build_memcpy_call (tree dst, tree src, tree le
   /* Construct call to __builtin_memcpy.  */
   tmp = build_call_expr_loc (input_location,
 built_in_decls[BUILT_IN_MEMCPY], 3, dst, src, len);
-  return fold_convert (void_type_node, tmp);
+  if (TREE_CODE (tmp) == NOP_EXPR)
+return tmp;
+  else
+return fold_convert (void_type_node, tmp);
 }


The source of the problem was that the memcpy call

  (void) __builtin_memcpy ((void *) cp.$data, (void *) &x, 8);

is being replaced at -O1 by:

  (*(struct t2 * {ref-all}) SAVE_EXPR  = x;, (void *) SAVE_EXPR
;);

which 'gfc_build_memcpy_call' was not able to cope with. I.e. the
'fold_convert' would produce an COMPOUND_EXPR, which later on would trigger the
error in 'tree_annotate_all_with_location'.


-- 


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



[Bug libgcj/41814] ICE in jc1 during bootstrap of gcj

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-25 10:51 ---
Investigating.  Look odd.


-- 


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



[Bug libstdc++/41816] libstdc++.so.6.0.14-gdb.py is not an ELF file

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-25 10:52 ---
Of course bstdc++.so.6.0.14-gdb.py is not an ELF file.  But what is the bug?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug other/41820] cc1: error: Cannot load plugin ./selfassign.so

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-25 11:00 ---
There is configure fluff in gcc/configure.ac at the --enable-plugin handling
that should deal with this (it tries -rdynamic at the moment).  Probably
plugins should be disabled if not using GNU ld for now.


-- 


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



[Bug lto/41821] ICE in LTO when linking

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-25 11:04 ---
Can you instead launch the link command-line with -v -save-temps appended
and from the output re-run the lto1 command invocation inside gdb and do

(gdb) b internal_error
(gdb) run
(gdb) up 2

you should be at gimple.c:3488 now, if not go up/down frames until you are

(gdb) call debug_tree (t1)

and paste the output of that here?  If t1 is optimized out at that point
try going up one more frame and try again there with the proper call
argument.

Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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



[Bug c/41822] New: pdp11 code generation bug & temporary fix

2009-10-25 Thread diane dot neisius at web dot de
Hi folks,
I work on reanimation of the XINU operation system for my real "old iron"
PDP-11/03. During my work I found a bug in the gcc code generation for PDP-11
target, please find details below.

Host information:
i686 running Debian 5.0, Kernel 2.6.26-1-686,
host native gcc version 4.3.2 (Debian 4.3.2-1.1)

Crosscompiler information:
gcc-core-4.3.3.tar.gz  source file downloaded from gnu.org, built with:
/configure --target=pdp11-dec-bsd --disable-nls --without-headers
--enable-languages=c
make all-gcc
make install-gcc

Crosscompiler test:
Type "pdp11-dec-bsd-gcc -S and.c" for the following input C file:

/* and.c */

int and()
{
   int a = 0;
   int b = 0;

   return ( a & b );
}

It results in the following output assembler file:

.text

.even
.globl _and
_and:
~~and:
jsr r5, csv
/*abuse empty parameter slot for locals!*/
sub $02, sp
mov $0, 0177764(r5)
mov $0, 0177766(r5)
mov 0177764(r5), r0
bic 0177766(r5), r0
/* SP ignored by cret? */
jmp cret

This is an obvious error, for the logical "AND" is *not* equivalent to the
PDP-11 "BIC" (BIt Clear) instruction. BIC performs the operation  &=
!(), see for example "PDP 11/40 processor handbook", DEC, Maynard (Mass.)
1972, page 4-29.

Temporary fix:
A quick but not-so-nice bugfix is to uncomment the buggy "and" definitions in
the machine definition file /gcc/config/pdp11/pdp11.md (lines 1152 to
1217). The rebuilt compiler then generates function calls to ___andsi3 and
___andhi3 which the user must supply, of course.
Using this fix I was able to compile the demo.c program and standalone library
of the XINU sources and successfully ran the binary on my real old PDP-11/03.

~Diane.


-- 
   Summary: pdp11 code generation bug & temporary fix
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: diane dot neisius at web dot de
 GCC build triplet: i386-linux-gnu
  GCC host triplet: i386-linux-gnu
GCC target triplet: pdp11-dec-bsd


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



[Bug fortran/41823] New: gcc/fortran/trans-openmp.c: possible null pointer dereference

2009-10-25 Thread dcb314 at hotmail dot com
I just had a look at the source code file
gcc/fortran/trans-openmp.c,
function gfc_trans_omp_do.

I notice the following code

  gfc_omp_clauses *clauses = code->ext.omp_clauses;
  gfc_code *outermost;
  int i, collapse = clauses->collapse;

where the assumption is made that local variable "clauses" is non-NULL
and so local variable "collapse" can be assigned to ok.

Later code is

  for (i = 0; i < collapse; i++)
{
  int simple = 0;
  int dovar_found = 0;

  if (clauses)

where a test is made for local variable "clauses" to be NULL or not.

Suggest code rework to cope with clauses being NULL. Maybe the following
untested code would be enough

  int i, collapse = (clauses ? clauses->collapse : 0);


-- 
   Summary: gcc/fortran/trans-openmp.c: possible null pointer
dereference
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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



[Bug libgcj/41814] ICE in jc1 during bootstrap of gcj

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-25 11:52 ---
Confirmed.  The java FE overloads the BINFO_VIRTUALS field incompatible to what
the middle-end specifies:

java/java-tree.h:#define TYPE_NVIRTUALS(TYPE) BINFO_VIRTUALS (TYPE_BINFO
(TYPE))

  TYPE_NVIRTUALS (this_class) = dtable_count;

I'll deal with this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-25 11:52:28
   date||


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



[Bug tree-optimization/41498] ICE with graphite flags on trunk

2009-10-25 Thread eres at il dot ibm dot com


--- Comment #3 from eres at il dot ibm dot com  2009-10-25 11:55 ---
(In reply to comment #2)
> Works for me on amd64-linux and graphite branch.  See daily reports on
> http://groups.google.com/group/gcc-graphite-test 
> No testcase was provided anyways.
> Sebastian

I just tried trunk -r153538 on powerpc64-suse-linux and it still fails with the
same error on SPEC2006/436.cactusADM.
I'll try to create a testcase.


-- 


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



[Bug libgcj/41814] ICE in jc1 during bootstrap of gcj

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-10-25 12:03 ---
Subject: Bug 41814

Author: rguenth
Date: Sun Oct 25 12:03:07 2009
New Revision: 153539

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153539
Log:
2009-10-25  Richard Guenther  

PR middle-end/41814
* tree.c (find_decls_types_r): Deal with Java overloading
BINFO_VIRTUALS for its own purpose.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c


-- 


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



[Bug libgcj/41814] ICE in jc1 during bootstrap of gcj

2009-10-25 Thread dl9pf at gmx dot de


--- Comment #6 from dl9pf at gmx dot de  2009-10-25 12:14 ---
(In reply to comment #5)
Tnx for the quick reply - testing .


-- 


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



[Bug middle-end/41814] [4.5 Regression] ICE in jc1 during bootstrap of gcj

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2009-10-25 12:21 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|libgcj  |middle-end
 Resolution||FIXED
Summary|ICE in jc1 during bootstrap |[4.5 Regression] ICE in jc1
   |of gcj  |during bootstrap of gcj
   Target Milestone|--- |4.5.0


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



[Bug target/40648] misaligned store vectorizer patch introduced 10% runtime regression on Polyhedron test_fpu

2009-10-25 Thread eres at il dot ibm dot com


--- Comment #10 from eres at il dot ibm dot com  2009-10-25 12:41 ---
(In reply to comment #0)
> Hello!
> The "[patch, vectorizer] misaligned store support" patch [1] resulted in more
> than 10% longer execution time for Polyhedron test_fpu test on Core2.
> The test is compiled with "-march=x86-64 -ffast-math -funroll-loops -O3",

This patch changes wrongly the decision of when to peel the loop which causes
the negative effect on the performance.
I am preparing a patch to fix this.


-- 


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



[Bug target/41762] internal compiler error when compiling xorg-server

2009-10-25 Thread zsojka at seznam dot cz


--- Comment #11 from zsojka at seznam dot cz  2009-10-25 12:54 ---
(In reply to comment #8)
> > However, I was testing against original testcase from #1, with crash in:
> > xkbInit.c: In function 'XkbWriteRulesProp':
> > xkbInit.c:231:1: internal compiler error: Segmentation fault
> 
> This is fixed by revision 148718:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00701.html
> 

I am receiving the same error in r151451, disappears in r151453 (20090905)
(trunk).
gcc 4.4 branch (r153538, 20091025) still has this problem, but needs adding of
-freorder-blocks-and-partition

This error appears only with testcase from #1, testcase #2 crashes only in 4.4
branch.
Testcase #4 crashes also only in 4.4 branch, but without
-freorder-blocks-and-partition

gcc trunk r151451 (20090905), testcase #1
/mnt/svn/gcc-trunk/build/bin/gcc -O2 -ftracer -fsched2-use-superblocks -c
xkbInit.i -fpic -o xkbInit.o -m32 -v

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090905 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-ftracer' '-fsched2-use-superblocks' '-c' '-fpic'
'-o' 'xkbInit.o' '-m32' '-v' '-mtune=generic'
 /mnt/svn/gcc-trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-fpreprocessed xkbInit.i -quiet -dumpbase xkbInit.i -m32 -mtune=generic
-auxbase-strip xkbInit.o -O2 -version -ftracer -fsched2-use-superblocks -fpic
-o /tmp/cc2DknNP.s
GNU C (GCC) version 4.5.0 20090905 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090905 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20090905 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090905 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8a1e9afda3419227dd015b7092d5e6db
xkbInit.c: In function 'XkbWriteRulesProp':
xkbInit.c:231:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


gcc 4.4 branch r153536 (20091025), testcase #1
 /mnt/svn/gcc-4_4/build/bin/gcc -O2 -ftracer -fsched2-use-superblocks
-freorder-blocks-and-partition -c xkbInit.i -fpic -o xkbInit.o -m32 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-4_4/build/
Thread model: posix
gcc version 4.4.3 20091025 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-ftracer' '-fsched2-use-superblocks'
'-freorder-blocks-and-partition' '-c' '-fpic' '-o' 'xkbInit.o' '-m32' '-v'
'-mtune=generic'
 /mnt/svn/gcc-4_4/build/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/cc1
-fpreprocessed xkbInit.i -quiet -dumpbase xkbInit.i -m32 -mtune=generic
-auxbase-strip xkbInit.o -O2 -version -ftracer -fsched2-use-superblocks
-freorder-blocks-and-partition -fpic -o /tmp/cceIygE0.s
GNU C (GCC) version 4.4.3 20091025 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.3 20091025 (prerelease), GMP version
4.3.1, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1fae2d693de11f22248ae1044a6b14dd
xkbInit.c: In function 'XkbWriteRulesProp':
xkbInit.c:231: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I hope this info is useful.


-- 


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



[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE

2009-10-25 Thread dominiq at lps dot ens dot fr


--- Comment #6 from dominiq at lps dot ens dot fr  2009-10-25 13:55 ---
The patches in comment #1 and #5 seem to work as advertized (currently
regtesting).

After having looked at the f2003 standard draft, I understand that

allocate(a, source=t2(1,2))

is equivalent to

allocate(t2::a)
a%i=1
a%j=2

With this change the compilation fails with:

pr41714_db.f90:12.3:

a%j=2
   1
Error: 'j' at (1) is not a member of the 't' structure

Did I missed something in the standard or is this a bug?


-- 


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



[Bug tree-optimization/41498] ICE with graphite flags on trunk

2009-10-25 Thread eres at il dot ibm dot com


--- Comment #4 from eres at il dot ibm dot com  2009-10-25 14:31 ---
Created an attachment (id=18890)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18890&action=view)
A testcase to reproduce the ICE

Here is the command line and the error message for the testcase attached (using
trunk -r153538 on ppc):
 /home/eres/mainline_45/build/bin/gfortran -c   -m64 -O3 -mcpu=power6
-ffast-math -maltivec  -fno-loop-parallelize-all -fgraphite -fno-loop-block
-fno-loop-interchange -fno-loop-strip-mine -fgraphite-identity -ftree-vectorize
 test.f
test.f: In function âfoo_â:
test.f:1:0: internal compiler error: in sese_adjust_liveout_phis, at sese.c:496
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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



[Bug fortran/41777] Wrong-code with POINTER-returning GENERIC function

2009-10-25 Thread burnus at gcc dot gnu dot org


--- Comment #5 from burnus at gcc dot gnu dot org  2009-10-25 14:33 ---
  print *, associated(a,f(a)) ! Valid, but error

If one steps in the debugger, one see that the TARGET= argument of associate
but "f", i.e. target->expr_type == EXPR_FUNCTION, target->symtree->n.sym->name
"f" and target->value.function->esym->name == "f".

Patch - not regtested, but seems to work.

--- resolve.c   (Revision 153537)
+++ resolve.c
@@ -1867,6 +1867,11 @@ resolve_generic_f0 (gfc_expr *expr, gfc_
{  
  expr->value.function.name = s->name;
  expr->value.function.esym = s;
+ /* Copy attributes such that checking attr.pointer works, but keep
+attr.generic as we do not (want to) copy all the other properties
+of the specific.  */
+ expr->symtree->n.sym->attr = s->attr;
+ expr->symtree->n.sym->attr.generic = 1;
  if (s->ts.type != BT_UNKNOWN)
expr->ts = s->ts;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-25 14:33:13
   date||


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



[Bug fortran/41777] Wrong-code with POINTER-returning GENERIC function

2009-10-25 Thread burnus at gcc dot gnu dot org


--- Comment #6 from burnus at gcc dot gnu dot org  2009-10-25 14:44 ---
TODO: Check whether the patch does the right thing. One overrides the symbol
settings of the generic, which should be harmless, but might lead to problems
if one uses different specifics which share the same "sym" pointer. On the
other hand, all the code assumes that accessing "symtree->n.sym->attr" gives
the correct result for exec_type == EXEC_FUNCTION.


-- 


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



[Bug tree-optimization/41498] ICE with graphite flags on trunk

2009-10-25 Thread spop at gcc dot gnu dot org


--- Comment #5 from spop at gcc dot gnu dot org  2009-10-25 15:31 ---
test.f works on amd64-linux on the graphite branch.
I am doing the merge of the graphite branch to trunk,
and this should be fixed then.


-- 


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



[Bug fortran/37829] ICE in resolve_symbol

2009-10-25 Thread dominiq at lps dot ens dot fr


--- Comment #9 from dominiq at lps dot ens dot fr  2009-10-25 15:34 ---
(In reply to comment #8)
> > It seems that the patch in comment #2 has been silently applied 
> Not exactly silently. It was pr38672

Thanks for the pointer. This PR has not been marked as a duplicate of pr38672
and while the later refers to this one, the converse was not true.

> The whole iso_c_binding is messy because it doesn't look like normal modules.

I have also noticed that!-)

> It hijacks functions everywhere to take care of iso_c_binding cases and 
> doesn't
> benefit from the general code. Here, the derived type of the function c_funloc
> is given a mangled name because it is not wanted by the user.
> This seems to fix it :
> ...

I think the patch just papers over the problem. With it, the following (weird,
but legal?) code:

module b
  use iso_c_binding, only:c_funloc!,c_funptr
end module b

program c
  use b
  implicit none
  type c_funptr
 integer :: i
  end type
  type (c_funptr) :: d 
  d = c_funptr(1)
end

now gives errors:

pr37829_2_red_1.f90:8.15:

  type c_funptr
   1
Error: Derived type name 'c_funptr' at (1) already has a basic type of
TYPE(c_funptr)
pr37829_2_red_1.f90:10.5:

  end type
 1
Error: Expecting END PROGRAM statement at (1)
pr37829_2_red_1.f90:12.6:

  d = c_funptr(1)
  1
Error: Components of structure constructor 'c_funptr' at (1) are PRIVATE

This is coherent if the mangling is used to hide symbols not wanted by the
user.
In my opinion the question is how to remove the mangling done in module b, when
the symbol is used in module a. From the little I understand that does seem
obvious for me.

Indeed using c_funloc in one module and defining the return type in another one
is asking for trouble.
Nevertheless if it is legal it should be accepted by gfortran. So either we
change the summary of this pr or close it, opening a new one for this use of
modules. It both cases the pr can be marked with a low priority and as an
enhancement.


-- 


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



[Bug lto/41821] ICE in LTO when linking

2009-10-25 Thread mckelvey at maskull dot com


--- Comment #3 from mckelvey at maskull dot com  2009-10-25 16:32 ---
(In reply to comment #2)
> Can you instead launch the link command-line with -v -save-temps appended
> and from the output re-run the lto1 command invocation inside gdb and do
> 
> (gdb) b internal_error
> (gdb) run
> (gdb) up 2
> 
> you should be at gimple.c:3488 now, if not go up/down frames until you are
> 
> (gdb) call debug_tree (t1)
> 
> and paste the output of that here?  If t1 is optimized out at that point
> try going up one more frame and try again there with the proper call
> argument.

t1 is not available anywhere. Should I rebuild gcc with CFLAGS set to -g -O0?


-- 


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



[Bug lto/41821] ICE in LTO when linking

2009-10-25 Thread rguenther at suse dot de


--- Comment #4 from rguenther at suse dot de  2009-10-25 16:39 ---
Subject: Re:  ICE in LTO when linking

On Sun, 25 Oct 2009, mckelvey at maskull dot com wrote:

> 
> 
> --- Comment #3 from mckelvey at maskull dot com  2009-10-25 16:32 ---
> (In reply to comment #2)
> > Can you instead launch the link command-line with -v -save-temps appended
> > and from the output re-run the lto1 command invocation inside gdb and do
> > 
> > (gdb) b internal_error
> > (gdb) run
> > (gdb) up 2
> > 
> > you should be at gimple.c:3488 now, if not go up/down frames until you are
> > 
> > (gdb) call debug_tree (t1)
> > 
> > and paste the output of that here?  If t1 is optimized out at that point
> > try going up one more frame and try again there with the proper call
> > argument.
> 
> t1 is not available anywhere. Should I rebuild gcc with CFLAGS set to -g -O0?

that would be nice! (remember to use --disable-bootstrap)

thanks.


-- 


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



[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE

2009-10-25 Thread dominiq at lps dot ens dot fr


--- Comment #7 from dominiq at lps dot ens dot fr  2009-10-25 17:20 ---
(In reply to comment #6)
> Did I missed something in the standard or is this a bug?

Probably the former!-(If I move

a%j=2

inside the "type is (t2)" block, the code compiles without error).


-- 


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



[Bug libstdc++/41816] libstdc++.so.6.0.14-gdb.py is not an ELF file

2009-10-25 Thread joseph at codesourcery dot com


--- Comment #2 from joseph at codesourcery dot com  2009-10-25 17:43 ---
Subject: Re:  libstdc++.so.6.0.14-gdb.py is not an ELF
 file

Some people dislike a few warnings from ldconfig.  I think having this as 
a text file alongside the library is much better than alternative 
suggestions of embedding it in the library in some way; for one thing, a 
separate text file is much easier to adjust when libraries from a native 
build are being used in a cross environment, or from a cross build are 
being used in a native environment, and the relative positions of 
pythondir and libdir need changing.


-- 


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



[Bug c++/41785] [4.5 Regression] [C++0x] ICE on canonical types with variadic templates and CRTP

2009-10-25 Thread dodji at redhat dot com


--- Comment #5 from dodji at gcc dot gnu dot org  2009-10-25 17:47 ---
Subject: Re:   New: ICE on canonical types with variadic
templates and CRTP


During the instantiation of the base class of "derived" we are trying to
instantiate derived in the argument list of base.

lookup_template_class should find the specialization derived
in the type_specialization hash table because that specialization has been
hashed when we encountered the "derived instance;" declaration in main.

But the specialization is not found, leading to another derived type being
created and inserted into the type_specialization - which causes type
comparison issues later.

The reason why the derived specialization is not found by
lookup_template_class has to do with ARGUMENT_PACK_SELECT nodes.

At some point during pack expansion substituting in tsubst_pack_expansion
the pack argument "a" is temporarily replaced by an ARGUMENT_PACK_SELECT node.
So in type_specialization, the argument we have for the "derived"
specialization
is no more the TYPE_ARGUMENT_PACK "a", but an ARGUMENT_PACK_SELECT node that
references that TYPE_ARGUMENT_PACK.

But then we indirectly hit lookup_template_class from within
tsubst_pack_expansion
asking for the specialization of "derived" with the "a" argument. We
fail to find the specialization because we compare the TYPE_ARGUMENT_PACK "a"
with the ARGUMENT_PACK_SELECT present in the hash table.

I am testing the patch below which seems to address the issue.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 084ad1c..e80bc30 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5818,6 +5818,18 @@ template_args_equal (tree ot, tree nt)
  return 0;
   return 1;
 }
+  else if (ot && TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
+{
+  /* We get here probably because we are in the middle of substituting
+ into the pattern of a pack expansion. In that case the
+ARGUMENT_PACK_SELECT temporarily replaces the pack argument we are
+interested in. So we want to use the initial pack argument for
+the comparison.  */
+  ot = ARGUMENT_PACK_SELECT_FROM_PACK (ot);
+  if (nt && TREE_CODE (nt) == ARGUMENT_PACK_SELECT)
+   nt = ARGUMENT_PACK_SELECT_FROM_PACK (nt);
+  return template_args_equal (ot, nt);
+}
   else if (TYPE_P (nt))
 return TYPE_P (ot) && same_type_p (ot, nt);
   else if (TREE_CODE (ot) == TREE_VEC || TYPE_P (ot))


-- 


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



[Bug c/41824] New: Value not reread from stack frame

2009-10-25 Thread ktreichel at web dot de
Build command line: gcc -O2 -g -o test test.c

test.c:

#include 
#include 

static inline int ILInterlockedCompareAndExchangeI4_Full(volatile int *dest,
   
 int value,
   
 int comparand)
{
int retval;

__asm__ __volatile__
(
"lock;"
"cmpxchgl %2, %0"
: "=m" (*dest), "=a" (retval)
: "r" (value), "m" (*dest), "a" (comparand)
: "memory"
);

return retval;
}

static inline float ILInterlockedCompareAndExchangeR4_Full(volatile float
*dest,
   
float value,
   
float comparand)
{
int temp;
void *valuePtr = (void *)&value;
void *comparandPtr = (void *)&comparand;
void *tempPtr = (void *)&temp;

temp = ILInterlockedCompareAndExchangeI4_Full((volatile int *)dest,
   
  *(int *)valuePtr,
   
  *(int *)comparandPtr);
return *(float *)tempPtr;
}

float CompareExchangeFloat(float *location1, float value, float comparand)
{
return ILInterlockedCompareAndExchangeR4_Full(location1, value,
comparand);
}

int main(int argc, char** argv)
{
float testValue;
float returnValue;

testValue = 1.0;
returnValue = CompareExchangeFloat(&testValue, 2.0, 1.0);

return (returnValue == 1.0);
}

Function where the code is not genereted correcltly: CompareExchangeFloat

objdump output of the function:

004004f0 :
  4004f0:   8b 54 24 f8 mov-0x8(%rsp),%edx   <-- value
is read to register
  4004f4:   f3 0f 11 44 24 fc   movss  %xmm0,-0x4(%rsp)
  4004fa:   8b 4c 24 fc mov-0x4(%rsp),%ecx
  4004fe:   f3 0f 11 4c 24 f8   movss  %xmm1,-0x8(%rsp)  <-- value
is written to the stack location
  400504:   89 d0   mov%edx,%eax <-- value
is used from register instead of new value from stack location
  400506:   f0 0f b1 0f lock cmpxchg %ecx,(%rdi)
  40050a:   89 44 24 f4 mov%eax,-0xc(%rsp)
  40050e:   f3 0f 10 44 24 f4   movss  -0xc(%rsp),%xmm0
  400514:   c3  retq
  400515:   66 66 2e 0f 1f 84 00nopw   %cs:0x0(%rax,%rax,1)
  40051c:   00 00 00 00


-- 
   Summary: Value not reread from stack frame
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktreichel at web dot de
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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



[Bug c/41824] Value not reread from stack frame

2009-10-25 Thread ktreichel at web dot de


--- Comment #1 from ktreichel at web dot de  2009-10-25 18:23 ---
Created an attachment (id=18891)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18891&action=view)
Testcase to reproduce the bug


-- 


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



[Bug fortran/41777] Wrong-code with POINTER-returning GENERIC function

2009-10-25 Thread dominiq at lps dot ens dot fr


--- Comment #7 from dominiq at lps dot ens dot fr  2009-10-25 18:34 ---
With the patch in comment #5 I got two extra errors for my tests:

modification of pr30793 (comment #7)

pr30793_red.f90:151.10:

  mshp => msh_(quality)
  1
Error: Function 'msh_' at (1) has no IMPLICIT type

and the pr40440, both the file requiring iso_varying_string.f95 and the one
including it:

pr40440.f90:69.42:

call ifile_append_from_string (ifile, var_str (trim (char)))
  1
Error: Function 'var_str' at (1) has no IMPLICIT type
pr40440.f90:116.62:

  use ifiles, only: line_p, line_init, line_get_string_advance
  1
Fatal Error: Can't open module file 'ifiles.mod' for reading at (1): No such
file or directory


-- 


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



[Bug c/41824] Value not reread from stack frame

2009-10-25 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-25 18:46 ---
You are violating C type-based aliasing rules.  Use -fno-strict-aliasing.


-- 

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=41824



[Bug c++/41825] New: useless -Wshadow warning on function argument in local class

2009-10-25 Thread msebor at gmail dot com
The warning on the code below isn't useful since the formal argument of foo()
named i cannot be referenced in the body of the local struct. I.e., there is
no potential for referring to it by mistake since doing so would be a hard
error.

$ cat t.cpp && g++ -c -Wshadow t.cpp
int foo (int i)
{
struct {
int bar (int i) { return i; }
} s;

return s.bar (i);
};
t.cpp: In member function ‘int foo(int)bar(int)’:
t.cpp:4: warning: declaration of ‘int i’ shadows a parameter
t.cpp:1: warning: shadowed declaration is here


-- 
   Summary: useless -Wshadow warning on function argument in local
class
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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



[Bug bootstrap/41345] bootstrap comparison failure with --disable-checking

2009-10-25 Thread cadaker at gmail dot com


--- Comment #4 from cadaker at gmail dot com  2009-10-25 20:14 ---
This is still present in -r153539, along with some more comparison failures
(gcc/tree-vrp.o, gcc/tree-complex.o, gcc/sese.o, gcc/sel-sched.o, gcc/bitmap.o,
gcc/lto/lto-lang.o, gcc/cp/class.o).

Could this be of any help? This is a heavily reduced case of one failure in
bitmap.o. It fails with 'gcc -c -O2 -fcompare-debug' (but not with -O1) for me
on x86_64:

unsigned
bitmap_first_set_bit (unsigned long* bits)
{
  unsigned bit_no = 0;
  unsigned ix = 0;

  for (ix = 0; ix != 1u; ix++)
  if (bits[ix])
goto found_bit;
  __builtin_unreachable();
 found_bit:

 return bit_no;
}


-- 


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



[Bug bootstrap/41345] [4.5 Regression] bootstrap comparison failure with --disable-checking

2009-10-25 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
   Priority|P3  |P1
Summary|bootstrap comparison failure|[4.5 Regression] bootstrap
   |with --disable-checking |comparison failure with --
   ||disable-checking
   Target Milestone|--- |4.5.0


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



[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile

2009-10-25 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-25 21:00 ---
@if gcc-bootstrap
$(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@endif gcc-bootstrap


That is only happens when doing a native bootstrap and never when doing a cross
build.  


-- 


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



[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile

2009-10-25 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-25 21:01 ---
Actually, wait:
$(RPATH_ENVVAR)=`echo
"$(HOST_LIB_PATH)$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR);

For BASE_TARGET_EXPORTS.


-- 


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



[Bug target/41813] [4.5 Regression] SH: delay slot is filled with a wrong insn

2009-10-25 Thread kkojima at gcc dot gnu dot org


--- Comment #2 from kkojima at gcc dot gnu dot org  2009-10-25 23:10 ---
Subject: Bug 41813

Author: kkojima
Date: Sun Oct 25 23:10:22 2009
New Revision: 153543

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153543
Log:
PR target/41813
* config/sh/sh.md (stuff_delay_slot): Don't set T_REG in pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md


-- 


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



[Bug target/41813] [4.5 Regression] SH: delay slot is filled with a wrong insn

2009-10-25 Thread kkojima at gcc dot gnu dot org


--- Comment #3 from kkojima at gcc dot gnu dot org  2009-10-25 23:14 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/41826] New: invalid read in get_constraint_for_ptr_offset

2009-10-25 Thread zsojka at seznam dot cz
+++ This bug was initially created as a clone of Bug #41762 +++

Found in r153542. r151451 seems to be affected as well, 4.4 branch doesn't seem
to be.

$ valgrind
/mnt/svn/gcc-trunk/build-153542/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-m32 -O2 -o testcase.s testcase.i -version
==26448== Memcheck, a memory error detector 
==26448== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.   
==26448== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==26448== Command:
/mnt/svn/gcc-trunk/build-153542/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-m32 -O2 -o testcase.s testcase.i -version 
==26448==   
GNU C (GCC) version 4.5.0 20091025 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091025 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7   
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
GNU C (GCC) version 4.5.0 20091025 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091025 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7   
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
options passed:  -m32 -O2 testcase.i
options enabled:  -falign-labels -falign-loops -fargument-alias 
 -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcommon  
 -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop
 -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining 
 -feliminate-unused-debug-types -fexpensive-optimizations   
 -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 -findirect-inlining -finline -finline-functions-called-once
 -finline-small-functions -fipa-cp -fipa-pure-const -fipa-reference 
 -fipa-sra -fira-share-save-slots -fira-share-spill-slots -fivopts  
 -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants   
 -fmerge-debug-strings -fmove-loop-invariants -foptimize-register-move  
 -foptimize-sibling-calls -fpcc-struct-return -fpeephole -fpeephole2
 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop  
 -fsched-critical-path-heuristic -fsched-dep-count-heuristic
 -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic 
 -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic
 -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column -fsigned-zeros   
 -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing   
 -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
 -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop  
 -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts   
 -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-im -ftree-loop-ivcanon   
 -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre   
 -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink
 -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter
 -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fvar-tracking
 -fvar-tracking-assignments -fvect-cost-model -fzero-initialized-in-bss 
 -m32 -m80387 -m96bit-long-double -maccumulate-outgoing-args
 -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mglibc -mieee-fp   
 -mno-red-zone -mno-sse4 -mpush-args -msahf -mtls-direct-seg-refs   
Compiler executable checksum: e3f8774dea091f6c29da5b8842041488  
 getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked
putc_unlocked putchar_unlocked getline feof_unlocked ferror_unlocked sprintf
vsprintf snprintf vsnprintf fprintf printf vprintf vfprintf asprintf __asprintf
dprintf obstack_printf vasprintf vdprintf obstack_vprintf gets fgets fread
fgets_unlocked fread_unlocked atof atoi atol atoll gnu_dev_major gnu_dev_minor
gnu_dev_makedev realpath ptsname_r wctomb mbstowcs wcstombs tolower toupper
read pread pread64 readlink readlinkat getcwd getwd confstr getgroups ttyname_r
getlogin_r gethostname getdomainname __signbitf __signbit __signbitl __sgn
__sgnf __sgnl __atan2l fabs fabsf fabsl __fabsl __sgn1l floor floorf floorl
ceil ceilf ceill lrintf lrint lrintl llrintf llrint llrintl __finite
__strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3
__strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c
memcpy memmove mempcpy me

[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset

2009-10-25 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2009-10-26 00:30 ---
Created an attachment (id=18892)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18892&action=view)
partially reduced testcase


-- 


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



[Bug middle-end/41817] elfutils triggers bogus "may be uninitialized" with -O3 -mtune=k8

2009-10-25 Thread marti at juffo dot org


--- Comment #3 from marti at juffo dot org  2009-10-26 03:26 ---
Created an attachment (id=18893)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18893&action=view)
test-resizing.i

Another instance of the same bug. This time from GNOME mutter 2.28.0

http://ftp.gnome.org/pub/gnome/sources/mutter/2.28/

gcc -save-temps -DHAVE_CONFIG_H -I. -I../.. -DORBIT2=1 -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/gconf/2 -I/usr/include/orbit-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
-I/usr/include/startup-notification-1.0 -I/usr/include/clutter-1.0
-I/usr/include/drm -I/usr/include/gobject-introspection-1.0 
-march=amdfam10 -fstack-protector -O3 -pipe -Wall -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-Wcast-align -Wsign-compare -Wall -Werror -ansi -MT test-resizing.o -MD -MP -MF
.deps/test-resizing.Tpo -c -o test-resizing.o test-resizing.c   
gcc: warning: -pipe ignored because -save-temps specified
cc1: warnings being treated as errors
test-resizing.c: In function ‘main’:
test-resizing.c:82: error: ‘height’ is used uninitialized in this function
test-resizing.c:94: note: ‘height’ was declared here


-- 


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



[Bug middle-end/41817] elfutils triggers bogus "may be uninitialized" with -O3 -mtune=k8

2009-10-25 Thread marti at juffo dot org


--- Comment #4 from marti at juffo dot org  2009-10-26 03:35 ---
Created an attachment (id=18894)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18894&action=view)
st-theme-node.i.gz

And yet another in gnome-shell from
http://ftp.gnome.org/pub/GNOME/sources/gnome-shell/2.28/

gcc -save-temps -DHAVE_CONFIG_H -I. -I.. -I../src -DPREFIX=\"/usr\"
-DLIBDIR=\"/usr/lib\" -DG_DISABLE_DEPRECATED -DG_LOG_DOMAIN=\"St\"
-DST_COMPILATION -DPACKAGE_DATA_DIR=\"/usr/share/gnome-shell\" -pthread
-I/usr/include/clutter-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/gtk-2.0 -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/drm -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/libcroco-0.6 -I/usr/include/libxml2 -march=k8 -fstack-protector
-O3 -pipe -Wall -Wmissing-prototypes -Werror -MT libst_1_0_la-st-theme-node.lo
-MD -MP -MF .deps/libst_1_0_la-st-theme-node.Tpo -c st/st-theme-node.c  -fPIC
-DPIC -o .libs/libst_1_0_la-st-theme-node.o
gcc: warning: -pipe ignored because -save-temps specified
cc1: warnings being treated as errors
st/st-theme-node.c: In function ‘st_theme_node_get_font’:
st/st-theme-node.c:1661: error: ‘font_style’ may be used uninitialized in this
function
st/st-theme-node.c:1663: error: ‘variant’ may be used uninitialized in this
function


-- 


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



[Bug c++/41825] useless -Wshadow warning on function argument in local class

2009-10-25 Thread bangerth at gmail dot com


--- Comment #1 from bangerth at gmail dot com  2009-10-26 04:52 ---
Confirmed. Though I'd note that if this was a *nested* function (not a function
in a *nested structure*) -- or a lambda function--, then the warning would make
sense.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||bangerth at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-26 04:52:41
   date||


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