[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  2011-01-09 
08:45:01 UTC ---
> For reference ACATS is now clean on arm-linux as well:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00648.html
> 
> LAST_UPDATED: Fri Jan  7 00:49:12 UTC 2011 (revision 168562)
> Native configuration is armv7l-unknown-linux-gnueabi
> === acats Summary ===
> # of expected passes2321
> # of unexpected failures0
> 
> Thanks Eric :).

You're welcome.  Thanks for reporting the problem.

[Bug fortran/47224] ICE with procedure pointer component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 09:46:33
 CC||janus at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2011-01-09 09:46:33 UTC ---
Confirmed. Thanks for reporting. Here is a slightly reduced/modified test case:

  abstract interface
real function dum_vfunc ( x )
  real, dimension(:) :: x
end function
  end interface

  type coefficients_t
procedure (dum_vfunc), pointer, nopass :: vfunc
  end type

  type(coefficients_t) :: coeff
  real, dimension(3) :: x
  print *, abs ( coeff%vfunc ( x(:) ) )

end

[Bug objc/47229] New: Objective C and C++ compiler frontends

[rwild at gcc dot gnu.org]

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

   Summary: Objective C and C++ compiler frontends
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rw...@gcc.gnu.org


It would be nice to have gobjc and gobjc++ compiler driver binaries that would
only be installed if Objective C or C++, respectively, were enabled at build
time.  This would very much simplify configure tests addressing the question
"do I have an Objective C(++) compiler, possibly cross-compiling, and possibly
not yet able to link successfully".

Thanks,
Ralf

[Bug fortran/46313] [OOP] class container naming collisions

[janus at gcc dot gnu.org]

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

--- Comment #23 from janus at gcc dot gnu.org 2011-01-09 10:35:56 UTC ---
Author: janus
Date: Sun Jan  9 10:35:50 2011
New Revision: 168610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168610
Log:
2011-01-09  Janus Weil  

PR fortran/46313
* class.c (get_unique_type_string): Make type name start with upper
case letter.


2011-01-09  Janus Weil  

PR fortran/46313
* gfortran.dg/class_35.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_35.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46313] [OOP] class container naming collisions

[janus at gcc dot gnu.org]

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

--- Comment #24 from janus at gcc dot gnu.org 2011-01-09 10:43:24 UTC ---
r168610 contains the patch from comment #20 which fixes comment #19.

Is there anything left to do here, or should we finally close this one?

[Bug objc/25361] structures containing vectors are not encoded correctly

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  2011-01-09 
11:19:53 UTC ---
objc.dg-struct-layout-encoding-1/t026_main.m seems to pass on all platforms I
have looked at. The other tests pass on several platforms, except Intel/AMD
ones (see pr45989).

[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  2011-01-09 
11:24:59 UTC ---
Created attachment 22934
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22934
updated patch

> Indeed, had forgotten about that. In that case, we should do as
> everywhere else in the testsuite and explicitly list i?86-*-* and
> x86_64-*-*.

I am attaching an updated patch using a more canonical list for *86*-*-* and
references to pr25361 and this one. I have tested it on powerpc-apple-darwin9
and x86_64-apple-darwin10.6.0 (further testing welcome;-). Please feel free to
do the change you deem suitable and to commit it.

[Bug objc/47229] Objective C and C++ compiler frontends

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  2011-01-09 12:07:57 
UTC ---
To test for an Objective-C compiler, I think you can use something like --

echo "int main (void) { return 0; }" > test.m
gcc -x objective-c test.m -o test.o

if gcc was built without objective-c support, you should get an error.

For objective-c++, you should be able to use

gcc -x objective-c++ test.m -o test.o

The advantage of doing this is that it should work with all versions of gcc
that support objective-c (and btw with other compilers as well).

Let me know if I missed the point completely! ;-)

Thanks

[Bug fortran/46313] [OOP] class container naming collisions

[burnus at gcc dot gnu.org]

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

--- Comment #25 from Tobias Burnus  2011-01-09 
12:34:08 UTC ---
(In reply to comment #24)
> r168610 contains the patch from comment #20 which fixes comment #19.
> 
> Is there anything left to do here, or should we finally close this one?

I think we might need to revisit the issue when submodules are implemented -
but until then everything should work - even the program below works - thus
closing as FIXED should be OK.

The following program has a name clash - but as the internal procedure is
internal, it does not leak out into global name space and works:

module mm
type t
end type t
end module mm

subroutine outer
call mm
contains
  subroutine mm
type t
end type t
class(t),allocatable :: a2
allocate( t :: a2)
  end subroutine mm
end 

use mm
class(t),allocatable :: a1
allocate( t :: a1)
call outer
end

[Bug testsuite/46912] [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  2011-01-09 12:41:37 
UTC ---
Author: iains
Date: Sun Jan  9 12:41:33 2011
New Revision: 168611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168611
Log:

PR gcc/46902
PR testsuite/46912
* plugin.c: Move include of dlfcn.h from here...
* system.h: ... to here.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/plugin.c
trunk/gcc/system.h

[Bug c/46902] [4.6 Regression] gcc.dg/plugin/plugindir*.c gives ICEs on powerpc-apple-darwin9

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  2011-01-09 12:41:37 
UTC ---
Author: iains
Date: Sun Jan  9 12:41:33 2011
New Revision: 168611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168611
Log:

PR gcc/46902
PR testsuite/46912
* plugin.c: Move include of dlfcn.h from here...
* system.h: ... to here.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/plugin.c
trunk/gcc/system.h

[Bug c/46902] [4.6 Regression] gcc.dg/plugin/plugindir*.c gives ICEs on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #20 from Dominique d'Humieres  
2011-01-09 13:01:40 UTC ---
Closing as fixed, thanks for the patch.

[Bug testsuite/46912] [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Dominique d'Humieres  
2011-01-09 13:02:32 UTC ---
Closing as fixed, thanks for the patch.

[Bug bootstrap/47230] New: gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[ubizjak at gmail dot com]

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

   Summary: gcc fails to bootstrap on alpha in stage2 with
"relocation truncated to fit: GPREL16 against ..."
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com


GCC fails to bootstrap on alphaev68-unknown-linux-gnu in stage2 with:

/home/uros/gcc-build/./prev-gcc/xgcc -B/home/uros/gcc-build/./prev-gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include  -g -O2 -gtoggle
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o
lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c
-lppl -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
libbackend.a(cfgbuild.o): In function `find_many_sub_basic_blocks':
(.text+0x450): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(cfgbuild.o): In function `find_many_sub_basic_blocks':
(.text+0xdc4): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(cfgcleanup.o): In function `mark_effect':
(.text+0x3e4): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(cfgcleanup.o): In function `try_crossjump_to_edge.isra.24':
(.text+0x1f98): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(cfgcleanup.o): In function `cleanup_cfg':
(.text+0x4870): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(cfgcleanup.o): In function `cleanup_cfg':
(.text+0x4f94): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(combine.o): In function `can_combine_p.isra.17':
(.text+0xae28): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(combine.o): In function `combine_simplify_rtx':
(.text+0x10204): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(combine.o): In function `combine_simplify_rtx':
(.text+0x12640): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(combine.o): In function `simplify_if_then_else':
(.text+0x138f8): relocation truncated to fit: GPREL16 against symbol
`default_target_rtl' defined in .bss section in libbackend.a(emit-rtl.o)
libbackend.a(combine.o): In function `simplify_if_then_else':
(.text+0x13d08): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
gmake[3]: *** [lto1] Error 1
gmake[3]: Leaving directory `/space/uros/gcc-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/space/uros/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/space/uros/gcc-build'
gmake: *** [all] Error 2

It looks that "default_target_rtl" symbol can not be reached with GP relative
relocation anymore.

[Bug bootstrap/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Target||alphaev68-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 13:11:00
   Host||alphaev68-unknown-linux-gnu
 Ever Confirmed|0   |1
Summary|gcc fails to bootstrap on   |[4.6 Regression] gcc fails
   |alpha in stage2 with|to bootstrap on alpha in
   |"relocation truncated to|stage2 with "relocation
   |fit: GPREL16 against ..."   |truncated to fit: GPREL16
   ||against ..."
   Target Milestone|--- |4.6.0
  Build||alphaev68-unknown-linux-gnu

--- Comment #1 from Uros Bizjak  2011-01-09 13:11:00 
UTC ---
4.6 regression.

[Bug testsuite/29057] gcc.target/powerpc/ppc64-abi-1.c fails to compile on powerpc-apple-darwin8 at -m64

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  2011-01-09 13:17:30 
UTC ---

the test is now skipped for darwin
/* { dg-skip-if "" { *-*-darwin* } { "*" } { "" } } */

(darwin has its own test : gcc.target/powerpc/darwin64-abi.c )

This is fixed on trunk, if you want to back-port, then remember to add
gcc.target/powerpc/darwin64-abi.c at the same time).

[Bug objc/47231] New: Commas inside ObjC method invocation can confuse compiler

[nicola at gcc dot gnu.org]

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

   Summary: Commas inside ObjC method invocation can confuse
compiler
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


GCC accepts the invalid code

 [receiver firstArgument: a, b secondArgument: c];

and seems to (mis)compile it as if 

 [receiver firstArgument:a  secondArgument: b];

had been typed.

This is not a regression; it seems that GCC has always behaved like that (which
also suggests it's not such a high priority since nobody ever noticed or
reported it; presumably few people accidentally put commas in there).

I tried out clang 2.8, and it rejects the invalid syntax; we should improve
GCC to reject it too! ;-)

Here is a more complete testcase, with the lines that have undetected syntax
errors marked --

/* Contributed by Nicola Pero , January 2011. 
*/
/* { dg-do compile } */

@interface MyClass
- (void) method: (id)x;
- (void) method2: (id)x : (id)y;
@end

void test (MyClass *o)
{
  [o method:];  /* { dg-error "syntax error" } */
  [o method: o];/* Ok */
  [o method: o, o]; /* { dg-error "too many arguments" } */

  [o method2::];   /* { dg-error "syntax error" } */
  [o method2: o :];/* { dg-error "syntax error" } */
  [o method2: o, o :]; /* { dg-error "syntax error" } */
  [o method2: o, o :o];/* { dg-error "too many arguments" } */ /* Missing
error */
  [o method2: o:o];/* Ok */
  [o method2: o, o :o, o]; /* { dg-error "too many arguments" } */ /* Missing
error */
  [o method2: o:o, o]; /* { dg-error "too many arguments" } */
}

Thanks

[Bug objc/47232] New: Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

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

   Summary: Confusing ObjC error message "attributes may not be
specified before before ‘class’"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


The following ObjC testcase:

__attribute__ ((deprecated)) @class A;

triggers the error

test5.m:1:30: error: attributes may not be specified before before ‘class’

which is clumsy.  It is due to c-parser.c producing the error "attributes may
not be specified before" which is then joined with "before 'class'".

Thanks

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 14:21:22
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-09 14:21:22 
UTC ---
I was looking at the other parser messages; maybe we could simply replace
"attributes may not be specified before" with "unexpected attribute".

Then, the error message would become

 unexpected attribute before 'class'

which is quite consistent with the other error messages.

Thanks

[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  2011-01-09 
14:34:44 UTC ---
Author: hubicka
Date: Sun Jan  9 14:34:41 2011
New Revision: 168612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168612
Log:

PR lto/47225
* Makefile.in: Regenerate.
* Makefile.def (lto-plugin): Always pass enable-shared to the plugin
configure.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug tree-optimization/47233] New: IPA reference tends to explode in memory use with -fprofile-generate

[hubicka at gcc dot gnu.org]

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

   Summary: IPA reference tends to explode in memory use with
-fprofile-generate
   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 Mozilla, IPA reference OOMs for me after allocating about 9GB of
bitmaps.  It is because the counters inserted to every function by
profile-generate are especially bad for the datastructure used by
IPA-reference.

As a temporary workaround, I will probably disable IPA reference with profiling
is active.

[Bug objc/47229] Objective C and C++ compiler frontends

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2011-01-09 14:47:10 UTC ---
See discussions on gcc-patches in Aug/Sep 2010 of patches that attempted 
to add such drivers but duplicated too much code instead of carefully 
refactoring with incremental changes without changing behavior except 
where explicitly intended and explained.

Note that the drivers can now use VECs which may make some of the things 
discussed in those threads simpler to do

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  2011-01-09 
15:21:11 UTC ---
(In reply to comment #10)
> Can this be closed? Is there something left to do here?

The first test case of comment 0 seems to be still unfixed (accepts-invalid -
expected error not printed).


The test case from comment 6 gives an ICE (segfault) in
gfc_conv_procedure_call's check for
  f = (fsym != NULL)
&& !(fsym->attr.pointer || fsym->attr.allocatable)
&& fsym->as->type != AS_ASSUMED_SHAPE;
(guess: "fsym->as" is NULL)


Comment 7 fails - but that's seems to be fixed by the patch of comment 12 (cf.
also below).

 * * *

(In reply to comment #12)
> > Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1
> This might be sufficient to fix it.

Thomas posted his patch at: http://gcc.gnu.org/ml/fortran/2011-01/msg00067.html

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  
2011-01-09 15:31:09 UTC ---
> Thomas posted his patch at: 
> http://gcc.gnu.org/ml/fortran/2011-01/msg00067.html

With this patch, the test in comment #6 still gives an ICE: Segmentation fault.
The backtrace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0008
0x0001000dd18d in gfc_conv_procedure_call (se=0x7fff5fbfd650,
sym=0x141a21640, args=0x141a23000, expr=0x141a24680, append_args=0x0) at
../../work/gcc/fortran/trans-expr.c:2682
2682&& fsym->as->type != AS_ASSUMED_SHAPE;
(gdb) bt
#0  0x0001000dd18d in gfc_conv_procedure_call (se=0x7fff5fbfd650,
sym=0x141a21640, args=0x141a23000, expr=0x141a24680, append_args=0x0) at
../../work/gcc/fortran/trans-expr.c:2682
#1  0x0001000de004 in gfc_conv_function_expr (se=0x7fff5fbfd650,
expr=) at
../../work/gcc/fortran/trans-expr.c:4036
Previous frame inner to this frame (gdb could not unwind past this frame)

No further testing yet.

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  2011-01-09 
15:33:02 UTC ---
(In reply to comment #13)
> The test case from comment 6 gives an ICE (segfault) in
> gfc_conv_procedure_call's check for
> && fsym->as->type != AS_ASSUMED_SHAPE;
> (guess: "fsym->as" is NULL)

Actually, it's in conv_isocbinding_procedure (which got inlined). The issue
seems to be that the code assumes that arg->expr->rank != 0 implies that
arg->expr->symtree->n.sym->as is set. However, the assumption fails for:
  p = c_loc(tt%t%i(1))
as "tt" is a scalar.

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  2011-01-09 
15:37:50 UTC ---
Author: tkoenig
Date: Sun Jan  9 15:37:47 2011
New Revision: 168614

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168614
Log:
2011-01-09  Thomas Koenig  

PR fortran/38536
* resolve.c (is_scalar_expr_ptr):  For a substring reference,
use gfc_dep_compare_expr to compare start and end expession.
Add FIXME for using gfc_deb_compare_expr elsewhere.

2011-01-09  Thomas Koenig  

PR fortran/38536
* gfortran.dg/iso_c_binding_c_loc_char_1.f03:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_c_loc_char_1.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/44240] r159321 causes FAIL: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jack Howarth  2011-01-09 
15:59:54 UTC ---
Closing since this bug is still absent at r168608.

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[tkoenig at netcologne dot de]

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

--- Comment #17 from tkoenig at netcologne dot de  2011-01-09 16:00:14 UTC ---
Am 09.01.2011 16:33, schrieb burnus at gcc dot gnu.org:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
> 
> --- Comment #15 from Tobias Burnus  2011-01-09 
> 15:33:02 UTC ---
> (In reply to comment #13)
>> The test case from comment 6 gives an ICE (segfault) in
>> gfc_conv_procedure_call's check for
>> && fsym->as->type != AS_ASSUMED_SHAPE;
>> (guess: "fsym->as" is NULL)
> 
> Actually, it's in conv_isocbinding_procedure (which got inlined). The issue
> seems to be that the code assumes that arg->expr->rank != 0 implies that
> arg->expr->symtree->n.sym->as is set. However, the assumption fails for:
>   p = c_loc(tt%t%i(1))
> as "tt" is a scalar.
> 

I'm looking at this.

[Bug lto/45302] g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -flto/-fwhopr ICE

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jack Howarth  2011-01-09 
16:01:31 UTC ---
Closing since this bug is still absent at r168608.

[Bug libffi/34311] libffi.call/nested_struct5.c execution tests fail under darwin9 on powerpc

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #2 from Iain Sandoe  2011-01-09 16:02:41 
UTC ---
As I wrote in:
 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00804.html

(after applying the other fixes along with the m64 implementation)

nested-struct5.c (still) fails for the 32 bit implementation. This is because
the testcase casts void * pointers to structure pointers -- the compiler thence
assumes that those structure pointers are appropriately aligned - and issues
vector instructions. 

However, there is no guarantee in the Darwin m32 ABI that the stacked version
of the structs will be appropriately aligned.   So, either the testcase is
wrong code - or the process for passing structures in the closure needs to be
refined (significant re-write, since the structs are currently passed
in-place).

Anyway, IMO we should either XFAIL this - or declare that the structs should be
mem-moved from the (void *) source.

[Bug c++/45646] ld: in partition2.o, section not found for address 0x696765625F617863

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Jack Howarth  2011-01-09 
16:03:58 UTC ---
Closing since this bug is still absent at r168608.

[Bug middle-end/46892] gcc.dg/vect/vect-25.c failures with -fgraphite-identity

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Jack Howarth  2011-01-09 
16:05:24 UTC ---
Closing since this bug is still absent at r168608.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #101 from Jack Howarth  2011-01-09 
16:06:52 UTC ---
Fixed in current gcc trunk.

[Bug tree-optimization/47234] New: ipa-split is executed before profile feedback is read

[hubicka at gcc dot gnu.org]

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

   Summary: ipa-split is executed before profile feedback is read
   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


This happens since tree-profile SSA reorg. Obviously ipa-split it profile
driven pass and should be done afterwards.  Working on patch.

This also makes it ipossible to profile w/o LTO and use it for LTO build

[Bug tree-optimization/47234] ipa-split is executed before profile feedback is read

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.09 16:07:49
 Blocks||45375
 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug middle-end/45371] -fgraphite-identity causes assertion failures in libstdc++

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Jack Howarth  2011-01-09 
16:11:06 UTC ---
Closing since this bug is still absent at r168608.

http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg02090.html
http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00716.html

[Bug fortran/47235] New: Accepts invalid/wrong code: PURE functions and Cray pointers

[burnus at gcc dot gnu.org]

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

   Summary: Accepts invalid/wrong code: PURE functions and Cray
pointers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Kind of follow up to PR 46896, cf.
http://gcc.gnu.org/ml/fortran/2011-01/msg00059.html

gfortran accepts Cray pointers in PURE functions - causing problems with the
alias analysis. It should be fixed for PURE and implicitly pure procedures.

[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2011-01-09 16:20:35 
UTC ---
(In reply to comment #5)
> 
> Still, I think the cleanest way is:
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
> int a;
> main()
> {
>   asm __volatile__ ("movl %%eax, %0":"=m"(a));
> }
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
> 
> It avoids the ASMNAME hack and makes outputs explicit.

I will take a look. But it still leaves:

FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 12 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 14 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 12 arg1
== 1
FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 14 arg1
== 1
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
-flto-partition=none  execution test

[Bug driver/47236] New: Spaces introduced in option processing

[bigotp at acm dot org]

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

   Summary: Spaces introduced in option processing
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org


The fix to #44076 causes options passed to language drivers to be split into
two arguments, a feature not present in previous versions.  

cat >xspecs < foo.nc

gcc -specs=xspecs -DTEST foo.nc

With versions prior to revision 163770, this would produce output including:

INVOKE: -DTEST

As of that version, it now produces:

INVOKE: -D TEST

This breaks the nesC component-based compiler used for TinyOS, and possibly
other similar languages that leverage the gcc driver.  The space does not
appear to be introduced for built-in languages (viz., the parameter remains
-DTEST when passed to cpp for a C language file).

If this is intentional and to be fixed in the per-language driver, please
update the description of the specs language to describe the conditions under
which such canonicalization can occur.

Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[Jan Hubicka]

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
> 
> I will take a look. But it still leaves:
> 
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 12 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 14 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 12 arg1
> == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 14 arg1
> == 1

This is probably another case of unwanted optimization. It does not seem to 
reproduce
for me in 64bit mode, I will check 32bit.

> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test

What kind of failures are you getting here?

[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  2011-01-09 17:10:51 UTC 
---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
> 
> I will take a look. But it still leaves:
> 
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 12 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto  line 14 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 12 arg1
> == 1
> FAIL: gcc.dg/guality/pr36728-1.c  -O2 -flto -flto-partition=none  line 14 arg1
> == 1

This is probably another case of unwanted optimization. It does not seem to
reproduce
for me in 64bit mode, I will check 32bit.

> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> -flto-partition=none  execution test

What kind of failures are you getting here?

[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jan Hubicka  2011-01-09 
17:19:21 UTC ---
Fixed.

[Bug lto/46948] [4.6 Regression] Undefined reference errors, LTO, and visibility

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2011-01-09 17:19:54 UTC ---
GCC 4.6.0 20110108 no longer fails with `-fuse-linker-plugin'. Still fails with
`-fno-use-linker-plugin'.

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

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.09 17:25:25
 AssignedTo|unassigned at gcc dot   |davek at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/44981] cfstring_format_type support needed darwin10

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Jack Howarth  2011-01-09 
17:28:25 UTC ---
 Closing because scale of backport makes approval unlikely.

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

[davek at gcc dot gnu.org]

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

--- Comment #49 from Dave Korn  2011-01-09 17:30:31 
UTC ---
Created attachment 22935
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22935
trial patch

brings the earlier change that nathan made to always keep dllexported inlines
under control of a command-line flag.  Before:

--snip--
make[1]: Leaving directory `/tmp/wx/obj-x-ming-clean/utils/wxrc'
Creating library file:
/tmp/wx/obj-x-ming-clean/lib/libwx_mswd_core-2.8.dll.a/op
t/mingw-pr43601-clean/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/
bin/ld: final link failed: Memory exhausted
collect2: ld returned 1 exit status

make: *** [/tmp/wx/obj-x-ming-clean/lib/wxmsw28d_core_gcc_custom.dll] Error 1

real79m46.081s
user50m1.166s
sys 5m45.723s

$ du -cxsh lib/*.dll
59M lib/wxbase28d_gcc_custom.dll
1.4Mlib/wxbase28d_net_gcc_custom.dll
512Klib/wxbase28d_xml_gcc_custom.dll
61M total
--snip--

... and after ... 

--snip--
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_aui-2.8.dll.a
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_richtext-2.8.dll.a
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_xrc-2.8.dll.a

real39m32.531s
user21m52.641s
sys4m53.111s


$ du -cxsh lib/*.dll
33M lib/wxbase28d_gcc_custom.dll
1.3Mlib/wxbase28d_net_gcc_custom.dll
512Klib/wxbase28d_xml_gcc_custom.dll
5.2Mlib/wxmsw28d_adv_gcc_custom.dll
2.2Mlib/wxmsw28d_aui_gcc_custom.dll
117Mlib/wxmsw28d_core_gcc_custom.dll
4.7Mlib/wxmsw28d_html_gcc_custom.dll
576Klib/wxmsw28d_qa_gcc_custom.dll
4.2Mlib/wxmsw28d_richtext_gcc_custom.dll
8.2Mlib/wxmsw28d_xrc_gcc_custom.dll
176Mtotal
--snip--

Needs testcase + doco before I can submit it.

[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  2011-01-09 17:35:01 
UTC ---
(In reply to comment #7)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
> 
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution 
> > test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution 
> > test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto  execution 
> > test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> > -flto-partition=none  execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto
> > -flto-partition=none  execution test
> 
> What kind of failures are you getting here?

Run-time abort.  Please check 32bit.

[Bug fortran/47224] [F03] ICE with procedure pointer component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
Summary|ICE with procedure pointer  |[F03] ICE with procedure
   |component   |pointer component

--- Comment #3 from janus at gcc dot gnu.org 2011-01-09 17:45:24 UTC ---
Mine. The following patch fixes the test case and does not produce any
regressions on the "proc_*" test cases, which means it's probably fine:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 168609)
+++ gcc/fortran/resolve.c(working copy)
@@ -1528,7 +1528,6 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
   gfc_symtree *parent_st;
   gfc_expr *e;
   int save_need_full_assumed_size;
-  gfc_component *comp;

   for (; arg; arg = arg->next)
 {
@@ -1548,20 +1547,6 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
   continue;
 }

-  if (gfc_is_proc_ptr_comp (e, &comp))
-{
-  e->ts = comp->ts;
-  if (e->expr_type == EXPR_PPC)
-{
-  if (comp->as != NULL)
-e->rank = comp->as->rank;
-  e->expr_type = EXPR_FUNCTION;
-}
-  if (gfc_resolve_expr (e) == FAILURE)  
-return FAILURE; 
-  goto argument_list;
-}
-
   if (e->expr_type == EXPR_VARIABLE
 && e->symtree->n.sym->attr.generic
 && no_formal_args


Will commit as obvious after a full regtest.

Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[Jan Hubicka]

> 
> Run-time abort.  Please check 32bit.
OK, these reproduce to me. Adding "staitic" into the testcase as follows:

/* PR middle-end/12210 */
/* Origin: Ossadchy Yury A.  */

/* This used to fail on i686 because the argument was not copied
   to the right location by __builtin_apply after the direct call.  */

/* { dg-do run } */

#define INTEGER_ARG  5

extern void abort(void);

static void foo(int arg)
{
  if (arg != INTEGER_ARG)
abort();
}

static void bar(int arg)
{
  foo(arg);
  __builtin_apply(foo, __builtin_apply_args(), 16);
}

int main(void)
{
  bar(INTEGER_ARG);

  return 0;
}

make it fail too, so it is pre-existing wrong code.  I am looking into what 
gets wrong.

Honza

[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  2011-01-09 18:06:44 UTC 
---
> 
> Run-time abort.  Please check 32bit.
OK, these reproduce to me. Adding "staitic" into the testcase as follows:

/* PR middle-end/12210 */
/* Origin: Ossadchy Yury A.  */

/* This used to fail on i686 because the argument was not copied
   to the right location by __builtin_apply after the direct call.  */

/* { dg-do run } */

#define INTEGER_ARG  5

extern void abort(void);

static void foo(int arg)
{
  if (arg != INTEGER_ARG)
abort();
}

static void bar(int arg)
{
  foo(arg);
  __builtin_apply(foo, __builtin_apply_args(), 16);
}

int main(void)
{
  bar(INTEGER_ARG);

  return 0;
}

make it fail too, so it is pre-existing wrong code.  I am looking into what
gets wrong.

Honza

[Bug fortran/47203] USE of module with same name as SUBROUTINE not reject, but also not working

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2011-01-09 18:11:47 UTC ---
cf. PR 47136 for similar examples

[Bug fortran/47136] local identifier shall not be the same as a global identifier

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-01-09 18:12:38 UTC ---
cf. also PR 47203, which is basically a duplicate of this one

[Bug tree-optimization/47237] New: builtin_apply_args broken WRT local API changes.

[hubicka at gcc dot gnu.org]

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

   Summary: builtin_apply_args broken WRT local API changes.
   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


#define INTEGER_ARG  5

extern void abort(void);

static void foo(int arg)
{
  if (arg != INTEGER_ARG)
abort();
}

static void bar(int arg)
{
  foo(arg);
  __builtin_apply(foo, __builtin_apply_args(), 16);
}

int main(void)
{
  bar(INTEGER_ARG);

  return 0;
}
fails at 32bit.  The problem is that we call bar with register calling
conventions, while foo's calling conventions are default.
We must prevent any call conventions changes on functions calling
builtlin_apply.

This is not only case where builtin_apply_args breaks, since we will happily
clone the functions, too.

I guess in addition to inlinable and cloning flag, we need flag whether
function calling convention can change. In what conditions this is false in
addition to apply_args?

This bug probably exists since GCC 3.4. I tested 4.3 and 4.5 to fail.

[Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 18:25:04
 Ever Confirmed|0   |1

--- Comment #10 from Jan Hubicka  2011-01-09 
18:25:04 UTC ---
OK, the remaining stack align changes all seem to be caused by the same
problem, filled in as PR 47237.  It seems to be regression to GCC 3.3, as the
API changes was introduced in 3.4 with cgraph infrastructure.

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #19 from Jan Hubicka  2011-01-09 
18:27:52 UTC ---
it works for me now.

[Bug c++/46904] [4.6 Regression] g++.dg/tree-prof/(indir-call-prof.C|inline_mismatch_args.C) fail on powerpc-apple-darwin9

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #4 from Jack Howarth  2011-01-09 
18:38:34 UTC ---
The appears to be fixed according to the powerpc-apple-darwin9 regress server.

[Bug fortran/42418] PROCEDURE: Rejects interface which is both specific and generic procedure

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 18:55:46
 Ever Confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org 2011-01-09 18:55:46 UTC ---
(In reply to comment #0)
> gfortran rejects the following program where "gen" is both a generic and a
> specific procedure name as interface argument to PROCEDURE. I cannot find a
> reason why it should be invalid and thus I think it is valid.
> 
> 
> procedure(gen) :: f
>  1
> Error: Interface 'gen' at (1) may not be generic


The behavior in comment #0 I can confirm. And I agree that it is valid. Chapter
16.3.1 of F08 says:

"Within its scope, a local identifier of one class shall not be the same as
another local identifier of the same class, except that a generic name may be
the same as the name of a procedure as explained in 12.4.3.4 [...]"

In 12.4.3.4.1 we find:

"A generic name is a generic identifier that refers to all of the procedure
names in the interface block. A generic name may be the same as any one of the
procedure names in the interface block, or the same as any accessible generic
name."

[Bug fortran/47224] [F03] ICE with procedure pointer component

[m.a.hulsen at tue dot nl]

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

--- Comment #4 from Martien Hulsen  2011-01-09 
19:04:27 UTC ---
(In reply to comment #3)
Yes, this fixes the ICE. My full code also compiles now. Thanks.
I now have a segfault when running the code. Will send a bug report after I
manage to reduce the code.

[Bug c++/46904] [4.6 Regression] g++.dg/tree-prof/(indir-call-prof.C|inline_mismatch_args.C) fail on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #5 from Dominique d'Humieres  2011-01-09 
19:07:04 UTC ---
Closing as fixed, thanks for the patch.

[Bug ada/47238] New: Incorrect evaluation '=' in GNATPREP

[ivansavvateev at yandex dot ru]

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

   Summary: Incorrect evaluation '=' in GNATPREP
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ivansavvat...@yandex.ru


GNATPREP evaluates incorrectly an expression contains two integer symbols. For
example, when I define:

SYS_MODE_PCP := 1
SYS_MODE := SYS_MODE_PCP

and try to preprocess:

#IF SYS_MODE = SYS_MODE_PCP
  TCB: P_TCB;
#END IF; 

I get after preprocessing:

--! #IF SYS_MODE = SYS_MODE_PCP
--!   TCB: P_TCB;
--! #END IF;

although the condition is true.

[Bug fortran/47224] [F03] ICE with procedure pointer component

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-01-09 21:01:41 UTC ---
Author: janus
Date: Sun Jan  9 21:01:38 2011
New Revision: 168618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168618
Log:
2011-01-09  Janus Weil  

PR fortran/47224
* resolve.c (resolve_actual_arglist): Remove unneeded and buggy piece
of code.


2011-01-09  Janus Weil  

PR fortran/47224
* gfortran.dg/proc_ptr_comp_28.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_28.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47051] [4.6 Regression] Wrong reallocate

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  2011-01-09 21:02:50 
UTC ---
Created attachment 22936
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22936
This patch fixes the PR

I need to go through this with a fine toothed comb.  It regtests OK and
represents a big simplification of the code.

I'll submit tomorrow.

Paul

[Bug fortran/47224] [F03] ICE with procedure pointer component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from janus at gcc dot gnu.org 2011-01-09 21:17:08 UTC ---
(In reply to comment #4)
> Yes, this fixes the ICE. My full code also compiles now.

The patch has been committed as r168618. So we can close this PR.


> I now have a segfault when running the code. Will send a bug report after I
> manage to reduce the code.

A segfault is not necessarily a compiler bug, but in case it is, a reduced test
case would be very helpful.

[Bug fortran/42418] PROCEDURE: Rejects interface which is both specific and generic procedure

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-01-09 21:32:14 UTC ---
cf. also PR 39427 (generic names can be the same as derived type names)

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org 2011-01-09 21:42:04 UTC ---
A loosely related bug is PR 42418, which demands that generic interfaces can
have the same name as specific procedures. When fixing this bug, one should
ideally find a solution which also fixes that issue (e.g. one could have a
separate symtree for generics in a namespace).

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #20 from H.J. Lu  2011-01-09 22:02:10 
UTC ---
On my Intel64 machine with 6GB RAM and 12GB swap, revision 168617
failed at final link:

lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [lto1] Error 1
make[5]: *** Waiting for unfinished jobs
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [cc1obj] Error 1
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [jc1] Error 1
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [cc1] Error 1
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [cc1plus] Error 1
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc
returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[5]: *** [f951] Error 1
rm gcj-dbtool.pod jcf-dump.pod cpp.pod jv-convert.pod grmic.pod gcov.pod
gcj.pod gc-analyze.pod gfdl.pod gij.pod gcc.pod gfortran.pod fsf-funding.pod
make[5]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux/gcc'
make[4]: *** [all-stagefeedback-gcc] Error 2
make[4]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'
make[3]: *** [stagefeedback-bubble] Error 2
make[3]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'
make[2]: *** [profiledbootstrap] Error 2
make[2]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'

GCC configured with

/export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib
--with-demangler-in-ld   --prefix=/usr/gcc-4.6.0 --with-local-prefix=/usr/local
--with-fpmath=sse --with-build-config=bootstrap-lto

Re: [Bug driver/46760] LTO bootstrap doesn't work with FDO

[Jan Hubicka]

> lto1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc

What is the backtrace here?  I built working profiledbootsrap LTO compiler with 
various cofigurations
already (both GNU ld and gold) w/o problems  I will try with current tree.

Honza

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hubicka at ucw dot cz]

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

--- Comment #21 from Jan Hubicka  2011-01-09 22:07:59 
UTC ---
> lto1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc

What is the backtrace here?  I built working profiledbootsrap LTO compiler with
various cofigurations
already (both GNU ld and gold) w/o problems  I will try with current tree.

Honza

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2011-01-09 22:47:27 
UTC ---
Author: nicola
Date: Sun Jan  9 22:47:22 2011
New Revision: 168619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168619
Log:
In gcc/:
2011-01-09  Nicola Pero  

PR objc/47232
* c-parser.c (c_parser_declaration_or_fndef): Improved
error message.

In gcc/testsuite/:
2011-01-09  Nicola Pero  

PR objc/47232
* objc.dg/attributes/invalid-attribute-1.m: New.
* obj-c++.dg/attributes/invalid-attribute-1.mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/attributes/invalid-attribute-1.mm
trunk/gcc/testsuite/objc.dg/attributes/invalid-attribute-1.m
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2011-01-09 22:48:51 
UTC ---
Fixed in trunk (4.6.0).

Thanks

[Bug tree-optimization/47234] ipa-split is executed before profile feedback is read

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  2011-01-09 
23:05:05 UTC ---
Patch posted http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00509.html

[Bug tree-optimization/47233] IPA reference tends to explode in memory use with -fprofile-generate

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.09 23:07:05
 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jan Hubicka  2011-01-09 
23:07:05 UTC ---
Path posted http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00508.html

[Bug tree-optimization/47239] New: (int)&func & 3 is always optimized to 0 on some targets

[kkojima at gcc dot gnu.org]

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

   Summary: (int)&func & 3 is always optimized to 0 on some
targets
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org


Targets like arm, hppa and sh64 use the lower bits of the address
of functions for special purposes.  Even on those targets,


extern void plabel32_function (void);

int
is_plabel32 (void)
{
  return ((unsigned long) &plabel32_function & 3);
}


which was the test case of PR 35705, is wrongly compiled with -O2.
It seems that tree-bit-ccp optimization evaluates the expression
((unsigned long) &plabel32_function & 3) to zero always.
With -fno-tree-bit-ccp, the result looks OK.  For example, arm-eabi
compiler outputs

movr0, #0
bxlr

with -O2 and

ldrr0, .L2
andr0, r0, #3
bxlr
.L3:
.align2
.L2:
.wordplabel32_function

with -O2 -fno-tree-bit-ccp.  I've got similar results for hppa and sh64
compilers.

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

[loaden at gmail dot com]

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

--- Comment #50 from Yuchen Deng  2011-01-09 23:48:09 
UTC ---
Good news!

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu  2011-01-10 00:01:45 
UTC ---
Program received signal SIGSEGV, Segmentation fault.
tree_can_inline_p (e=0x7fffdaf9fd68)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:5391
5391  gimple_call_set_cannot_inline (e->call_stmt, true);
Missing separate debuginfos, use: debuginfo-install
cloog-ppl-0.15.8-1.0.f12.x86_64 glibc-2.12.90-21.2.f14.x86_64
gmp-4.3.2-0.0.f13.x86_64 libgcc-4.5.1-4.fc14.x86_64 libmpc-0.8.1-1.0.f12.x86_64
libstdc++-4.5.1-4.fc14.x86_64 mpfr-2.4.2-1.0.f12.x86_64
ppl-0.10.2-10.fc12.x86_64 zlib-1.2.5-2.fc14.x86_64
(gdb) bt
#0  tree_can_inline_p (e=0x7fffdaf9fd68)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:5391
#1  0x00a5653a in cgraph_decide_inlining_of_small_functions ()
at /export/gnu/import/git/gcc/gcc/ipa-inline.c:1177
#2  0x00a585b7 in cgraph_decide_inlining ()
at /export/gnu/import/git/gcc/gcc/ipa-inline.c:1479
#3  0x00e65b52 in execute_one_pass (pass=0x1947960)
at /export/gnu/import/git/gcc/gcc/passes.c:1553
#4  0x00e6626a in execute_ipa_pass_list (pass=0x1947960)
at /export/gnu/import/git/gcc/gcc/passes.c:1920
#5  0x00e665e6 in do_whole_program_analysis ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:2334
#6  0x00ebab88 in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:2446
#7  0x0071730d in compile_file ()
at /export/gnu/import/git/gcc/gcc/toplev.c:579
#8  do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1874
#9  0x007189e5 in toplev_main (argc=405, argv=0x1e44a00)
at /export/gnu/import/git/gcc/gcc/toplev.c:1937
#10 0x004a5040 in main (argc=35, argv=0x7fffdc08)
at /export/gnu/import/git/gcc/gcc/main.c:36
(gdb) list
5386
5387  /* Allow the backend to decide if inlining is ok.  */
5388  if (!targetm.target_option.can_inline_p (caller, callee))
5389{
5390  e->inline_failed = CIF_TARGET_OPTION_MISMATCH;
5391  gimple_call_set_cannot_inline (e->call_stmt, true);
5392  e->call_stmt_cannot_inline_p = true;
5393  return false;
5394}
5395
(gdb) p e
$1 = (struct cgraph_edge *) 0x7fffdaf9fd68
(gdb) p e->call_stmt
$2 = (union gimple_statement_d *) 0x0
(gdb)

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hubicka at ucw dot cz]

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

--- Comment #23 from Jan Hubicka  2011-01-10 00:21:35 
UTC ---
> 5386
> 5387  /* Allow the backend to decide if inlining is ok.  */
> 5388  if (!targetm.target_option.can_inline_p (caller, callee))
> 5389{
> 5390  e->inline_failed = CIF_TARGET_OPTION_MISMATCH;
> 5391  gimple_call_set_cannot_inline (e->call_stmt, true);
> 5392  e->call_stmt_cannot_inline_p = true;
> 5393  return false;
> 5394}
> 5395
> (gdb) p e
> $1 = (struct cgraph_edge *) 0x7fffdaf9fd68
> (gdb) p e->call_stmt
> $2 = (union gimple_statement_d *) 0x0
> (gdb)
Obviously we can not set gimple_call_set_cannot_inline when call_stmt is
missing.
I guess just guardining the set with
if (e->call_stmt)
  gimple_call_set_cannot_inline (e->call_stmt, true);
in all occurences in the function should fix the issue. Consider it preaproved
if it helps.  In 4.7 we probably should drop the gimple_call_set_cannot_inline
calls completely, I don't see any value in them.

Can you do dump_cgraph_node (stderr, e->caller) and dump_cgraph_node (stderr,
e->callee)??  I think we should decide function to be uninlinable only in
presence of target optimization attributes and I can not think of any during
the bootstrap

Honza

[Bug driver/47236] Spaces introduced in option processing

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jsm28 at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Joseph S. Myers  2011-01-10 
00:32:29 UTC ---
This has nothing to do with the specs language.  Rather, the canonical form of
an option accepting both joined and separate arguments is the form with a
separate argument, all option processing in both the driver and the core
compilers now uses common logic to process options into logical
cl_decoded_option structures, and all subsequent processing now uses those
structures - and if it needs to regenerate an option for specs processing, uses
the canonical form of the option (meaning specs no longer need to handle
noncanonical options if they are noncanonical in a way indicated in the .opt
files, e.g. through being aliases or through using joined arguments where
separate arguments are also accepted).  -D options certainly appear to be
passed in canonical (separate) form to subprocesses (e.g. by gcc -E) to me.

If an option accepts a separate argument and it is passed down to subprocesses
by specs, those subprocesses must accept the form with the separate argument.

[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem

[davek at gcc dot gnu.org]

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

--- Comment #9 from Dave Korn  2011-01-10 00:33:35 
UTC ---
Author: davek
Date: Mon Jan 10 00:33:32 2011
New Revision: 168624

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168624
Log:
gcc/ChangeLog:

PR c++/47218
* cgraphunit.c (assemble_thunk): Call resolve_unique_section.

gcc/testsuite/ChangeLog:

PR c++/47218
* g++.dg/other/pr47218-1.C: New test file.
* g++.dg/other/pr47218.C: Likewise.
* g++.dg/other/pr47218.h: New supporting header.


Added:
trunk/gcc/testsuite/g++.dg/other/pr47218-1.C
trunk/gcc/testsuite/g++.dg/other/pr47218.C
trunk/gcc/testsuite/g++.dg/other/pr47218.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Dave Korn  2011-01-10 00:53:45 
UTC ---
Done.

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hjl.tools at gmail dot com]

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

--- Comment #24 from H.J. Lu  2011-01-10 01:24:13 
UTC ---
(gdb) call dump_cgraph_node (stderr, e->caller)
_cpp_clean_line/47583(-1) @0x7fffdaf97b00 (asm: _cpp_clean_line)
availability:available analyzed executed 136036096x 107 time, 14 benefit 186
size, 7 benefit (204 after inlining) needed reachable externally_visible
prevailing_def finalized inlinable
  called by: cpp_pop_definition/47256 (1.00 per call) destringize_and_run/47257
(1.00 per call) run_directive/47259 (2130530x) (1.00 per call)
builtin_macro/47693 (97x) (1.00 per call) paste_tokens/47699 (450825x) (1.00
per call) cpp_read_state/47816 (1.00 per call) _cpp_skip_block_comment/47586
(19682217x) (0.93 per call) _cpp_get_fresh_line.part.5/47584 (113774079x) (1.00
per call) 
  calls: add_line_note/38510 (inlined) (136036096x) (1.00 per call)
add_line_note/47567 (nested in 1 loops) add_line_note/47567 (8317015x) (0.06
per call) (nested in 1 loops) add_line_note/47567 (2018574x) (0.01 per call)
__builtin_expect/2426 (133456296x) (0.98 per call) __builtin_expect/2426
(133456296x) (0.98 per call) __builtin_expect/2426 (133456296x) (0.98 per call)
add_line_note/47567 (nested in 1 loops) __builtin_expect/2426 (319549x) (0.00
per call) (nested in 1 loops) __builtin_expect/2426 (133775845x) (0.98 per
call) (nested in 1 loops) search_line_sse42/47576 (136174844x) (1.00 per call)
(nested in 1 loops) 
  References:  var:search_line_fast (read) fn:search_line_sse42/47576 (addr)
var:_cpp_trigraph_map (read) var:_cpp_trigraph_map (read) var:_sch_istable
(read) var:_sch_istable (read) var:_cpp_trigraph_map (read)
var:_cpp_trigraph_map (read)
  Refering this function: 
  has 1 outgoing edges for indirect calls.
(gdb) call dump_cgraph_node (stderr, e->callee)
search_line_sse42/47576(-1) @0x7fffdaf97160 (asm: search_line_sse42.762190)
availability:available analyzed executed 136174844x 18 time, 15 benefit 30
size, 7 benefit address_taken prevailing_def_ironly finalized inlinable
  called by: _cpp_clean_line/47583 (136174844x) (1.00 per call) 
  calls: __builtin_expect/2426 (127407932x) (0.94 per call)
search_line_sse2/47575 (1039x) __builtin_expect/2426 (142096x) (0.00 per call)
__builtin_expect/2426 (127408971x) (0.94 per call) 
  References: 
  Refering this function:  fn:init_vectorized_lexer/47582 (addr)
fn:_cpp_clean_line/47583 (addr)
(gdb)

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hjl.tools at gmail dot com]

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

--- Comment #25 from H.J. Lu  2011-01-10 01:25:00 
UTC ---
My machine supports SSE4.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #28 from Jan Hubicka  2011-01-10 
01:29:19 UTC ---
With fixes for PR47234 and PR47233 I can build -fprofile-generate libxul.
Didn't tried yet if the porfile apply, since build later dies at:
/abuild/jh/trunk-install/bin/g++ -fpermissive -O3 -flto=24 -fuse-linker-plugin
-fprofile-generate  -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type
-pedantic -Wno-long-long -fno-strict-aliasing -fshort-wchar -pthread -pipe 
-DNDEBUG -DTRIMMED -g   -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  
-I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12   -I/usr/include/gtk-2.0 -I/usr/lib64/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/lib64/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/gtk-unix-print-2.0-fPIC -shared -Wl,-z,defs
-Wl,-h,libmozgnome.so -o libmozgnome.so  nsGnomeModule.o nsAlertsService.o
nsAlertsIconListener.o -lpthread   
-Wl,-rpath-link,/abuild/jh/build-mozilla-new8-prof/dist/bin
-Wl,-rpath-link,/usr/local/lib
/abuild/jh/build-mozilla-new8-prof/dist/lib/libxpcomglue_s.a
-L/abuild/jh/build-mozilla-new8-prof/dist/bin -lxpcom -lmozalloc
-L/abuild/jh/build-mozilla-new8-prof/dist/bin -lxpcom -lmozalloc
-L/abuild/jh/build-mozilla-new8-prof/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread
-ldl   -lgobject-2.0 -lglib-2.0   -L/lib64 -lnotify -lgtk-x11-2.0 -ldbus-glib-1
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0
-lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgmodule-2.0
-ldbus-1 -lgobject-2.0 -lglib-2.0 -Wl,--version-script
-Wl,/abuild/jh/mozilla-central2/mozilla-central/build/unix/gnu-ld-scripts/components-version-script
-Wl,-Bsymbolic -ldl
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxUnknownSurface::~gfxUnknownSurface():../../../dist/include/gfxASurface.h:247:
error: undefined reference to 'vtable for gfxASurface'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxUnknownSurface::~gfxUnknownSurface():../../../dist/include/gfxASurface.h:248:
error: undefined reference to 'gfxASurface::RecordMemoryFreed()'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxUnknownSurface::~gfxUnknownSurface():../../../dist/include/gfxASurface.h:247:
error: undefined reference to 'vtable for gfxASurface'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxUnknownSurface::~gfxUnknownSurface():../../../dist/include/gfxASurface.h:248:
error: undefined reference to 'gfxASurface::RecordMemoryFreed()'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxASurface::~gfxASurface():../../../dist/include/gfxASurface.h:247: error:
undefined reference to 'vtable for gfxASurface'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxASurface::~gfxASurface():../../../dist/include/gfxASurface.h:248: error:
undefined reference to 'gfxASurface::RecordMemoryFreed()'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxASurface::~gfxASurface():../../../dist/include/gfxASurface.h:247: error:
undefined reference to 'vtable for gfxASurface'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
gfxASurface::~gfxASurface():../../../dist/include/gfxASurface.h:248: error:
undefined reference to 'gfxASurface::RecordMemoryFreed()'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/abuild/jh/tmp//cc0wLUAb.ltrans0.ltrans.o: in function
_ZTV17gfxUnknownSurface.local.39.3126:cc0wLUAb.ltrans0.o(.data.rel.ro+0x10):
error: undefined reference to 'gfxASurface::BeginPrinting(nsAString const&,
nsAString const&)'
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/.

[Bug driver/46760] LTO bootstrap doesn't work with FDO

[hubicka at ucw dot cz]

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

--- Comment #26 from Jan Hubicka  2011-01-10 01:42:06 
UTC ---
> call) (nested in 1 loops) search_line_sse42/47576 (136174844x) (1.00 per call)
Ahh, that is the Andi's vectorized preprocessor code. That is fine then

Honza

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #29 from Jan Hubicka  2011-01-10 
01:59:31 UTC ---
... and hacking around, the profile doesn't read back even with
-fprofile-correction
/abuild/jh/trunk-install/bin/gcc  -O3 -flto -flto-partition=none
-fuse-linker-plugin -fprofile-correction -fprofile-use -o jemalloc.o -c 
-DOSTYPE=\"Linux2.6.32.12-0\" -DOSARCH=Linux 
-I/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc -I.
-I../../dist/include -I../../dist/include/nsprpub 
-I/abuild/jh/build-mozilla-new8-prof/dist/include/nspr
-I/abuild/jh/build-mozilla-new8-prof/dist/include/nss   -fPIC  -Wall -W
-Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long
-fno-strict-aliasing -pthread -pipe  -DNDEBUG -DTRIMMED -g   -include
../../mozilla-config.h -DMOZILLA_CLIENT -MD -MF .deps/jemalloc.pp
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c: In
function 'arena_malloc':
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c:6530:1:
note: correcting inconsistent profile data
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c: In
function 'malloc_mutex_unlock':
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c:6530:1:
error: corrupted profile info: edge from 0 to 2 exceeds maximal count
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c: In
function 'malloc_mutex_lock':
/abuild/jh/mozilla-central2/mozilla-central/memory/jemalloc/jemalloc.c:6530:1:
error: corrupted profile info: edge from 2 to 3 exceeds maximal count

will see if this reproduce w/o LTO.

[Bug fortran/47051] [4.6 Regression] Wrong reallocate

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  2011-01-10 07:31:42 
UTC ---
(In reply to comment #13)

> I'll submit tomorrow.

Done http://gcc.gnu.org/ml/fortran/2011-01/msg00075.html

Paul