[Bug middle-end/46845] -fgraphite-identity causes ICE in gcc.dg/pr43300.c at -m32/-m64

[spop at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Pop  2010-12-14 07:30:07 
UTC ---
Patch
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01062.html

Reg: Relocation Truncated to fit : R_PPC_PLTREL24 error occur in EABI POWERPC GNU compiler

[Gugan]

Hi ,

 Actually while compling i am getting the error " Relocation
Truncated to fit : R_PPC_PLTREL24 " in 

Eabi PowerPC GNU compiler.

Previousely we have used the optimisation " -01" . if we use that
optimisation we didnt get any error. 

After removing that optimisation we are getting the error " Relocation
Truncated to fit : R_PPC_PLTREL24 ".

Is there any solution for solving this problem .?? Give me some Suggestions
regarding  about this ...

Regards
Gugan N
-- 
View this message in context: 
http://old.nabble.com/Reg%3A-Relocation-Truncated-to-fit-%3A-R_PPC_PLTREL24-error-occur-in-EABI-POWERPC-GNU-compiler-tp30452274p30452274.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug target/46934] New: gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109

[raj.khem at gmail dot com]

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

   Summary: gcc ICE: error: unrecognizable insn: in extract_insn,
at recog.c:2109
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: raj.k...@gmail.com
  Host: x86_64-linux
Target: arm-none-linux-gnueabi
 Build: x86_64-linux


attached testcase reduced from samba when building for armvte/thumb with -Os
caused a gcc ICE with 4.6.0. Note that it works ok for arm mode and for other
opt levels than -Os

arm-none-linux-gnueabi-gcc-4.6.0 -mthumb -Os cli_reg.i -S

cli_reg.i: In function ‘caller’:
cli_reg.i:20:1: error: unrecognizable insn:
(insn 6 5 7 3 (set (reg:SI 137)
(plus:SI (reg/v:SI 136 [ reg_type ])
(const_int 2147483648 [0x8000]))) cli_reg.i:4 -1
 (nil))
cli_reg.i:20:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


testcase

$ cat cli_reg.i
int caller(unsigned int reg_type)
{

 switch (reg_type)
 {
 case 0x8000:
  return (int)foo();

 case 0x8003:
  return (int) bar();

 case 0x8001:
  return (int) baz();

 case 0x8004:
  return (int) fooz();

 }

}

[Bug c++/46933] New: [4.6 Regression] Revision 167781 failed g++.dg/other/first-global.C

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] Revision 167781 failed
g++.dg/other/first-global.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


Revision 167781:

http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00463.html

caused:

FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I(_|_65535_0_)foobar

[Bug regression/46931] Subversion id 167184 breaks building perlbench on power7 with debug

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2010-12-14 05:59:50 
UTC ---
It may be related to PR 46834.

[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  2010-12-14 05:35:00 
UTC ---
(In reply to comment #11)
> (In reply to comment #9)

> > The attached fixes the PR and is regtesting right now.  I do not believe 
> > that
> > there will be any ere regressions since the patch adds temporaries where 
> > there
> > were none before.
> ... unless the testcases check for the absence of temporary ;-)

That's what I meant by trivial. I have to sift through the extra temporaries
and decide which ones are warranted and which ones are not.

Thanks

Paul

[Bug other/46542] GCC 4.7 pending patches meta-bug

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  2010-12-14 04:35:45 
UTC ---
Created attachment 22749
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22749
Patch to combine several distinct arrays into a single VEC

Patch to move various reg_equiv_xxx arrays into a single structure to ease
debugging and growing the structures in response to creating new pseudos.

About .1% compile-time slowdown, possibly due to the checking built into the
VEC implementation.

[Bug target/46932] New: Inefficient code sequence to access local variable

[carrot at google dot com]

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

   Summary: Inefficient code sequence to access local variable
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com


Compile the following code with options -march=armv7-a -mthumb -O2

extern void foo(char*);
void t01(char t)
{
  char c = t;
  foo(&c);
}

gcc4.6 generates:

t01:
push{lr}
subsp, sp, #12
addr3, sp, #8   // A
strbr0, [r3, #-1]!   // B
movr0, r3   // C
blfoo
addsp, sp, #12
pop{pc}

Code sequence ABC can be replaced by

strbr0, [sp, #7]
add r0, sp, #7  

Which may be faster. If we allocate the variable c at the boundary of a word(4
bytes aligned), the code sequence would be:

strbr0, [sp, #4]
add r0, sp, #4

which is shorter in code size because "add r0, sp, #4" can be encode into
16 bits.

When compiled to ARM instructions and/or -Os, it has the same problem.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #57 from H.J. Lu  2010-12-14 01:31:56 
UTC ---
My current patch is on hjl/init-array branch at

http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary

It uses .init_array only if linker supports mixing .init_array.* and
.ctors.* input sections. A linker patch is posted at

http://sourceware.org/ml/binutils/2010-12/msg00446.html

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  2010-12-14 
01:26:51 UTC ---
Author: hubicka
Date: Tue Dec 14 01:26:47 2010
New Revision: 167781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167781
Log:
This time really commit
PR middle-end/45388
* decl2.c (start_objects): Do not generate collect2 recognicable name
for static ctor.
* ipa.c (cgraph_build_static_cdtor_1): Break out from ... ; add FINAL
parameter.
(cgraph_build_static_cdtor): ... here.
(build_cdtor): Use cgraph_build_static_cdtor_1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/ipa.c

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ccoutant at gcc dot gnu.org]

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

--- Comment #56 from Cary Coutant  2010-12-14 
01:24:30 UTC ---
> H.J, Cary is talking about multiple global constructors in a single file, none
> of which use constructor priorities.  In other words, the normal case.  gcc
> generates those in a specific required order for the .ctors section.  If it
> does not reverse the order for .init_array, I don't see how it could possible
> work correctly.
> 
> Again: a single file, no priorities specified.

Right. I looked deeper and now see that gcc generates a single function per CU
that runs all the static constructors for that CU, then adds that single entry
to the .ctors section. So my concern was groundless -- the order of
constructors within the CU is controlled by the code in that one function.

-cary

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #55 from H.J. Lu  2010-12-14 01:14:22 
UTC ---
(In reply to comment #54)
> H.J, Cary is talking about multiple global constructors in a single file, none
> of which use constructor priorities.  In other words, the normal case.  gcc
> generates those in a specific required order for the .ctors section.  If it
> does not reverse the order for .init_array, I don't see how it could possible
> work correctly.
> 
> Again: a single file, no priorities specified.

It is handled by the C++ front end. Only one entry in .ctors/.init_array
section in a single file. Order within a single file doesn't matter.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ian at airs dot com]

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

--- Comment #54 from Ian Lance Taylor  2010-12-14 00:38:41 
UTC ---
H.J, Cary is talking about multiple global constructors in a single file, none
of which use constructor priorities.  In other words, the normal case.  gcc
generates those in a specific required order for the .ctors section.  If it
does not reverse the order for .init_array, I don't see how it could possible
work correctly.

Again: a single file, no priorities specified.

[Bug rtl-optimization/44374] Hoist same instructions in different branches

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  2010-12-14 
00:23:48 UTC ---
Author: bernds
Date: Tue Dec 14 00:23:40 2010
New Revision: 167779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167779
Log:
gcc/
PR rtl-optimization/44374
Reapply patch with fixes.
* basic-block.h (enum bb_flags): Add BB_MODIFIED.
* df-core.c (df_set_bb_dirty): Set it.
* ifcvt.c (find_memory): Remove function.
(dead_or_predicable): Use can_move_insns_across.
* df.h (can_move_insns_across): Declare function.
* cfgcleanup.c (block_was_dirty): New static variable.
(flow_find_head_matching_sequence): Test for epilogue notes.
(try_crossjump_bb, try_forward_edges): Test BB_MODIFIED flag rather
than df_get_bb_dirty.
(try_head_merge_bb): New static function.
(try_optimize_cfg): Call it.  Call df_analyze if block_was_dirty
is set.
* df-problems.c: Include "target.h"
(df_simulate_find_uses): New static function.
(MEMREF_NORMAL, MEMREF_VOLATILE): New macros.
(find_memory, find_memory_store): New static functions.
(can_move_insns_across): New function.
* Makefile.in (df-problems.o): Update dependencies.

gcc/testsuite/
PR rtl-optimization/44374
Reapply patch with fixes.
* gcc.target/arm/headmerge-1.c: New test.
* gcc.target/arm/headmerge-2.c: New test.
* gcc.target/i386/headmerge-1.c: New test.
* gcc.target/i386/headmerge-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/headmerge-1.c
trunk/gcc/testsuite/gcc.target/arm/headmerge-2.c
trunk/gcc/testsuite/gcc.target/i386/headmerge-1.c
trunk/gcc/testsuite/gcc.target/i386/headmerge-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/basic-block.h
trunk/gcc/cfgcleanup.c
trunk/gcc/df-core.c
trunk/gcc/df-problems.c
trunk/gcc/df.h
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46300] Calls to internals _ITM_cxa_throw and _ITM_cxa_allocate_exception are not marked as safe

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Aldy Hernandez  2010-12-14 
00:02:19 UTC ---
closed and fixed

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

[mikestump at comcast dot net]

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

--- Comment #11 from Mike Stump  2010-12-13 
22:55:12 UTC ---
I don't think this should be necessary.  One section should be enough.  If you
have specific concerns, let me know, I could just be missing something.

[Bug regression/46931] New: Subversion id 167184 breaks building perlbench on power7 with debug

[meissner at gcc dot gnu.org]

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

   Summary: Subversion id 167184 breaks building perlbench on
power7 with debug
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
CC: m...@suse.de
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 22748
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22748
Stripped down file that shows the problem

GCC has a segmentation violation when compiling the spec 2006 benchmark
perlbench on powerpc64-linux systems with the -O2 -ftree-vectorize -mcpu=power7
-g options.

Here is the traceback:
 -igoo-> /opt/at4.0/bin/gdb cc1
'import site' failed; use -v for traceback
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-linux".
For bug reporting instructions, please see:
...
Reading symbols from /home/meissner/fsf-build-ppc64/bug/gcc/cc1...done.
Breakpoint 1 at 0x101f95ec: file /home/meissner/fsf-src/bug/gcc/diagnostic.c,
line 893.
Breakpoint 2 at 0x101f9548: file /home/meissner/fsf-src/bug/gcc/diagnostic.c,
line 838.
Breakpoint 3 at 0x10a45678
Breakpoint 4 at 0x10a45260
(gdb) r -O2 -ftree-vectorize -mcpu=power7 -g -quiet pp.i
Starting program: /home/meissner/fsf-build-ppc64/bug/gcc/cc1 -O2
-ftree-vectorize -mcpu=power7 -m64 -g -quiet pp.i

Program received signal SIGSEGV, Segmentation fault.
gsi_for_stmt (stmt=0xfffb659af50) at
/home/meissner/fsf-src/bug/gcc/gimple-iterator.c:554
554 i = gsi_start_bb (bb);
(gdb) where
#0  gsi_for_stmt (stmt=0xfffb659af50) at
/home/meissner/fsf-src/bug/gcc/gimple-iterator.c:554
#1  0x10660998 in insert_debug_temp_for_var_def (gsi=0x0,
var=0xfffb693b318) at /home/meissner/fsf-src/bug/gcc/tree-ssa.c:444
#2  0x10663ff8 in release_ssa_name (var=0xfffb693b318) at
/home/meissner/fsf-src/bug/gcc/tree-ssanames.c:207
#3  0x10542640 in delete_update_ssa () at
/home/meissner/fsf-src/bug/gcc/tree-into-ssa.c:2793
#4  0x10691c64 in slpeel_tree_peel_loop_to_edge (loop=, e=, first_niters=0xfffb693aef8,
niters=0xfffb693aad8, update_first_loop_count=, th=0, 
check_profitability=86 'V', cond_expr=,
cond_expr_stmt_list=0x0) at
/home/meissner/fsf-src/bug/gcc/tree-vect-loop-manip.c:1456
#5  0x10691f44 in vect_do_peeling_for_alignment (loop_vinfo=0x10ecfa40)
at /home/meissner/fsf-src/bug/gcc/tree-vect-loop-manip.c:2189
#6  0x10686dc8 in vect_transform_loop (loop_vinfo=0x10ecfa40) at
/home/meissner/fsf-src/bug/gcc/tree-vect-loop.c:4677
#7  0x1069be78 in vectorize_loops () at
/home/meissner/fsf-src/bug/gcc/tree-vectorizer.c:205
#8  0x105febec in tree_vectorize () at
/home/meissner/fsf-src/bug/gcc/tree-ssa-loop.c:220
#9  0x10417468 in execute_one_pass (pass=0x10d1e3d8) at
/home/meissner/fsf-src/bug/gcc/passes.c:1563
#10 0x10417ab4 in execute_pass_list (pass=0x10d1e3d8) at
/home/meissner/fsf-src/bug/gcc/passes.c:1618
#11 0x10417ae0 in execute_pass_list (pass=0x10d1e248) at
/home/meissner/fsf-src/bug/gcc/passes.c:1619
#12 0x10417ae0 in execute_pass_list (pass=0x10d1dad0) at
/home/meissner/fsf-src/bug/gcc/passes.c:1619
#13 0x10558490 in tree_rest_of_compilation (fndecl=0xfffb6879200) at
/home/meissner/fsf-src/bug/gcc/tree-optimize.c:422
#14 0x1075866c in cgraph_expand_function (node=0xfffb680c080) at
/home/meissner/fsf-src/bug/gcc/cgraphunit.c:1508
#15 0x1075bc48 in cgraph_expand_all_functions () at
/home/meissner/fsf-src/bug/gcc/cgraphunit.c:1567
#16 cgraph_optimize () at /home/meissner/fsf-src/bug/gcc/cgraphunit.c:1823
#17 0x1075c118 in cgraph_finalize_compilation_unit () at
/home/meissner/fsf-src/bug/gcc/cgraphunit.c:1031
#18 0x1009e3d8 in c_write_global_declarations () at
/home/meissner/fsf-src/bug/gcc/c-decl.c:9837
#19 0x104e57cc in compile_file (argc=7, argv=0xfffe008) at
/home/meissner/fsf-src/bug/gcc/toplev.c:819
#20 do_compile (argc=7, argv=0xfffe008) at
/home/meissner/fsf-src/bug/gcc/toplev.c:2211
#21 toplev_main (argc=7, argv=0xfffe008) at
/home/meissner/fsf-src/bug/gcc/toplev.c:2274
#22 0x10147720 in main (argc=, argv=) at /home/meissner/fsf-src/bug/gcc/main.c:36
gdb) c
Continuing.

Breakpoint 2, internal_error (gmsgid=0x10cb8778 "%s") at
/home/meissner/fsf-src/bug/gcc/diagnostic.c:838
838   diagnostic_set_info (&diagnostic, gmsgid, &ap, input_location,
DK_ICE);
(gdb) c
Continuing.
pp.i: In function ‘Perl_pp_complement’

[Bug target/46887] Invalid AIX linker flag '-bnoerok', it has to be '-bernotok'

[michael.haubenwallner at salomon dot at]

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

--- Comment #2 from Michael Haubenwallner  2010-12-13 22:18:57 UTC ---
It did hit me in gcc-4.2.4 (languages=c,c++) in Gentoo Prefix on AIX, where I
do have some automagic patches to enable runtime linking by default as well as
full "soname" support (still to be sorted out with libtool upstream).

So I'm unable to hit this problem with vanilla gcc-4.2.4, even not with
LDFLAGS=-Wl,-brtl for unknown reason.
For gcc-trunk, I've just searched the sources for 'bnoerok' and still found it,
although I'm unsure if this would hit me whenever I start using gcc-java.

If this code is old and unused, I'm fine with its removal during normal
development.

[Bug fortran/46371] [Coarray] [OOP] SELECT TYPE: scalar coarray variable is rejected

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2010-12-13 
22:13:53 UTC ---
Created attachment 22747
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22747
Draft patch

Draft patch fixes "2 VALID" and "3 VALID" - however, I see failures for the
following examples. Additionally, the gfc_is_coindexed check is still missing.

Additional examples:

  class(foo), allocatable :: o_foo(:)
  class(foo), allocatable :: o_bar(:)[:]

! Expected: "o => o_foo" gives an error because of missing "(...)"
! However, it is accepted by NAG and Intel; the gfortran message is strange
!select type(o => o_foo)! 4 INVALID
  type is(foo) ! "must have a deferred shape"
  j = o(1)%i
end select

   select type(o => o_bar)! 5 VALID
 type is(foo)
 j = o(1)[1]%i ! "Unexpected coarray designator"
   end select

   select type(o => o_foo(1))  ! ICE segfault   
 type is(foo)  ! 6 VALID
 j = o%i
   end select

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  2010-12-13 
22:13:32 UTC ---
> Sure, they're not meant to be runtime tests.

I just wanted to be sure that I had understood the problem. Thanks

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #9 from Dmitry Gorbachev  
2010-12-13 22:02:02 UTC ---
Marking bar() externally_visible does not help..

[Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2010-12-13 21:59:21 UTC ---
(In reply to comment #3)
> Here is a reduced test case for the rejects-valid part, without CLASS and
> ISO_C_BINDING:


Not sure if it's the perfectly right thing to do, but the following patch fixes
the test cases in comment #3 and #1:

Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 167765)
+++ gcc/fortran/symbol.c(working copy)
@@ -2717,7 +2717,7 @@ gfc_get_sym_tree (const char *name, gfc_namespace

   /* This doesn't usually happen during resolution.  */
   if (ns == NULL)
-ns = gfc_current_ns;
+ns = gfc_find_proc_namespace (gfc_current_ns);

   /* Try to find the symbol in ns.  */
   st = gfc_find_symtree (ns->sym_root, name);

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2010-12-13 21:51:49 UTC ---
(In reply to comment #7)
> The tests in comments #2 and #3 compile now but segfault at run-time. Am I
> right to say that they are invalid because the pointers point to nowhere?

Sure, they're not meant to be runtime tests.

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  2010-12-13 
21:38:49 UTC ---
The tests in comments #2 and #3 compile now but segfault at run-time. Am I
right to say that they are invalid because the pointers point to nowhere?

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2010-12-13 
21:37:37 UTC ---
(In reply to comment #1)
> Two different patches have been posted to fix this:
> 
>  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00778.html
> 
>  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00784.html

The testcase in comment #2 is not optimized with the CSE patch but is with the
combine patch.

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

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  2010-12-13 21:32:15 UTC ---
On Mon, 13 Dec 2010, iains at gcc dot gnu.org wrote:

> > > (gdb) print plugindir_string
> > > $1 = 0x 
> > > 
> > > which is the origin of the current fail (there will be other issues 
> > > related to
> > > the FIXME, I'm sure).
> > 
> > independent of whether -iplugindir is given on the c/l.
> 
> in fact, the whole of global_options looks suspiciously un-initialized.

It's supposed to be runtime-initialized from global_options_init; see 
init_options_struct.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  2010-12-13 21:31:11 UTC ---
On Mon, 13 Dec 2010, amylaar at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
> 
> --- Comment #13 from Jorn Wolfgang Rennecke  
> 2010-12-13 19:16:47 UTC ---
> (In reply to comment #12)
> > On Sat, 11 Dec 2010, amylaar at gcc dot gnu.org wrote:
> > 
> > > We don't have any current decimal floating or fixed-point type size macros
> > > to replace.  As discussed elsewhere, the stdint type, wchar type, and ada 
> > > long
> > 
> > Yes we do.  The definitions starting with DECIMAL32_TYPE_SIZE in 
> > defaults.h.
> 
> Are these really supposed to be a target interface?  They are not documented,
> nowhere overridden, and besides, it would appear odd to have a
> DECIMAL32_TYPE_SIZE of, say, 31 bits.
> It seems these macros just serve to make the code more readable.
> Maybe they should be moved to tree.h ?

MIPS *does* override the fixed-point definitions.  As for the decimal 
ones, it seems TR 24732 does not allow the types to vary from the 754-2008 
formats - so maybe the sizes should just be hardcoded in tree.c with an 
appropriate comment.

[Bug c++/46701] [C++0x] ICE in build_data_member_initialization, at cp/semantics.c:5503

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Paolo Carlini  2010-12-13 
21:29:05 UTC ---
Thanks Jason. Fixed in Rev. 167770.

[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin  2010-12-13 
21:24:35 UTC ---
(In reply to comment #9)
> Created attachment 22739 [details]
> A tentative fix for the PR
Yeah, trying to share the code with gfc_trans_arrayfunc_assign was plain pain.
Copy'n'paste will work better here. :-(

> 
> The attached fixes the PR and is regtesting right now.  I do not believe that
> there will be any ere regressions since the patch adds temporaries where there
> were none before.
... unless the testcases check for the absence of temporary ;-)


I won't dig into it further, sorry.

[Bug c++/46930] [C++0x] ICE with static constexpr data member

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2010-12-13 
21:24:22 UTC ---
Jason, can you have a look?

[Bug c++/46930] New: [C++0x] ICE with static constexpr data member

[paolo.carlini at oracle dot com]

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

   Summary: [C++0x] ICE with static constexpr data member
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


Today was playing with this snippet inspired by an old constexpr paper:

struct S {
  static constexpr int size;
};

const int limit = 2 * S::size;
constexpr int S::size = 256;

u3.cc:5:26: internal compiler error: in decl_constant_var_p, at cp/decl2.c:3563

[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
 Depends on||25714, 44352, 46020, 46588,
   ||44735, 45244, 41922, 37211,
   ||43136, 34500, 41604, 38506

--- Comment #3 from Thomas Koenig  2010-12-13 
21:06:53 UTC ---
A few more character-related bugs have come up.

[Bug rtl-optimization/46920] suboptimal register allocation with local register variables

[vmakarov at redhat dot com]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #1 from Vladimir Makarov  2010-12-13 
21:03:48 UTC ---
Before IRA we have the following code

 L43:
   25 NOTE_INSN_BASIC_BLOCK
   26 pc=r59:DI
  REG_DEAD: r59:DI
i  27: barrier
L28:
   29 NOTE_INSN_BASIC_BLOCK
   30 r62:DI=r12:DI
  REG_DEAD: r12:DI
   31 {r63:DI=r62:DI+0x2;clobber flags:CC;}
  REG_UNUSED: flags:CC
   32 r12:DI=r63:DI
   33 flags:CCZ=cmp([r62:DI+0x2],0)
  REG_DEAD: r62:DI
   34 pc={(flags:CCZ==0)?L39:pc}
  REG_DEAD: flags:CCZ
  REG_BR_PROB: 0x1388
   35 NOTE_INSN_BASIC_BLOCK
   36 r76:DI=sign_extend(r65:SI)
  REG_DEAD: r65:SI
   37 {r63:DI=r63:DI+r76:DI;clobber flags:CC;}
  REG_DEAD: r76:DI
  REG_UNUSED: flags:CC
   38 r12:DI=r63:DI
L39:
   40 NOTE_INSN_BASIC_BLOCK
   41 r65:SI=sign_extend([r63:DI+0x1])
  REG_DEAD: r63:DI
   42 r59:DI=[r71:DI]
   61 pc=L43

To generate the proposed code, we should assign r12 to p63.  IRA marks p63
conflicting with r12 because DF-infrastructure reports r12 having intersected
live ranges with p63.

It is possible to solve the problem if we have conflicts based on values (not
live ranges).  I'd not recommend to do that, because it will slow down RA
without visible improvement on majority benchmarks (I did such experiment about
7 years ago and reported about the results on GCC summit in 2004).

By the way, usage of implicit hard registers in RTL (when it can be avoided. 
Example when hard registers can be avoided is their usage as call arguments) is
very bad idea for RA.  I see it a lot such code in x86-64 code.  I'd recommend
to prevent optimizations before RA to abuse hard register usage.

[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jason Merrill  2010-12-13 
20:53:19 UTC ---
Fixed.

[Bug c++/46877] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5502

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jason Merrill  2010-12-13 
20:52:41 UTC ---
Fixed.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #53 from H.J. Lu  2010-12-13 20:47:44 
UTC ---
(In reply to comment #52)
> (In reply to comment #51)
> > > If gcc switches from .ctors to .init_array, it needs to make sure to 
> > > generate
> > > the constructors in forward order within the TU, rather than backwards 
> > > order as
> > > it does in the .ctors section. I didn't see anything in HJ's patch that 
> > > does
> > > that.
> > 
> > It uses priority, instead of MAX_INIT_PRIORITY - priority, to generate
> >  for .init_arry..
> 
> No, I was talking about order of constructors within a TU without using
> priority. If you have static constructors for A then B in your source file, 
> gcc
> will output B's constructor before A's in the .ctors section, so that A's will
> run first. Where does your patch reverse that to account for the fact that
> .init_array sections are processed in forward order?


Yes, since

1. ld sorts .init_array sections in forward order.
2. ld.so processes .init_array section in forward order.

[Bug c++/46877] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5502

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2010-12-13 
20:47:04 UTC ---
Author: jason
Date: Mon Dec 13 20:46:58 2010
New Revision: 167770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167770
Log:
PR c++/46873
PR c++/46877
* semantics.c (build_data_member_initialization): Handle
cv-qualified data member.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor4.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2010-12-13 
20:47:03 UTC ---
Author: jason
Date: Mon Dec 13 20:46:58 2010
New Revision: 167770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167770
Log:
PR c++/46873
PR c++/46877
* semantics.c (build_data_member_initialization): Handle
cv-qualified data member.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor4.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 CC||ccoutant at gcc dot gnu.org

--- Comment #52 from Cary Coutant  2010-12-13 
20:41:46 UTC ---
(In reply to comment #51)
> > If gcc switches from .ctors to .init_array, it needs to make sure to 
> > generate
> > the constructors in forward order within the TU, rather than backwards 
> > order as
> > it does in the .ctors section. I didn't see anything in HJ's patch that does
> > that.
> 
> It uses priority, instead of MAX_INIT_PRIORITY - priority, to generate
>  for .init_arry..

No, I was talking about order of constructors within a TU without using
priority. If you have static constructors for A then B in your source file, gcc
will output B's constructor before A's in the .ctors section, so that A's will
run first. Where does your patch reverse that to account for the fact that
.init_array sections are processed in forward order?

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #51 from H.J. Lu  2010-12-13 20:30:58 
UTC ---
(In reply to comment #50)
> 
> If gcc switches from .ctors to .init_array, it needs to make sure to generate
> the constructors in forward order within the TU, rather than backwards order 
> as
> it does in the .ctors section. I didn't see anything in HJ's patch that does
> that.
> 

It is handled in

static section *
get_elf_initfini_array_priority_section (int priority,
 bool constructor_p)
{
  section *sec;
  if (priority != DEFAULT_INIT_PRIORITY)
{
  char buf[18];
  sprintf (buf, "%s.%.5u", 
   constructor_p ? ".init_array" : ".fini_array",
   priority);
  sec = get_section (buf, SECTION_WRITE, NULL_TREE);
}
  else
sec = constructor_p ? init_array_section : fini_array_section;
  return sec;
}

It uses priority, instead of MAX_INIT_PRIORITY - priority, to generate
 for .init_arry..

[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #22724|0   |1
is obsolete||

--- Comment #9 from Thomas Koenig  2010-12-13 
20:29:03 UTC ---
Created attachment 22746
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22746
As far as I got...

This is as far as I got.  Offsets are still calculated wrongly,
but without a clue as to where to start looking, I think I'll
give up for now.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ccoutant at gcc dot gnu.org]

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

--- Comment #50 from Cary Coutant  2010-12-13 
20:24:43 UTC ---
Sorry for jumping in so late here, but it sounds like the conclusions here
match my recollections:

- We added .init_array/.fini_array in order to blend the SVR4 version of .init,
which contained actual code, with the HP-UX version, which contained function
pointers and used a DT_INIT_SZ entry in the dynamic array rather than prologue
and epilogue pieces contributed from crt*.o files. The HP-UX version was seen
as an improvement, but it wasn't compatible, so we renamed the sections and the
dynamic table entries so that the two versions could live side-by-side and
implementations could transition slowly from one to the other.

- On HP-UX, we used .init/.init_array for static constructors, and they
registered the corresponding static destructors on a special atexit list,
rather than adding destructors to .fini_array, so that we could handle
destructors on dlclose() events properly (subject to your interpretation of
"properly" in that context)
[http://www.codesourcery.com/public/cxx-abi/abi.html#dso-dtor].

- Because .init was always executed from beginning to end (as code, there
really wasn't much alternative), so was .init_array.

- The gABI guaranteed that the init sections from a DT_NEEDED entry would
execute before those from the library containing that DT_NEEDED entry (reverse
topological order).

- Constructor execution order within a translation unit was guaranteed, but
there was no specified ordering between translation units within an executable
or shared library (although in practice it was link order). Those of us in the
discussions were mostly pro-shared library, so we weren't too worried about
running initializers backwards with respect to link order. The C++ ABI group
specified a way to record the constructor priorities, different from the
.ctors.n method used by gcc
[http://www.codesourcery.com/public/cxx-abi/abi.html#ctor-order].

If gcc switches from .ctors to .init_array, it needs to make sure to generate
the constructors in forward order within the TU, rather than backwards order as
it does in the .ctors section. I didn't see anything in HJ's patch that does
that.

We will still have an incompatibility with constructor order across TUs within
an executable or shared library. The new order may be just as legal as the
previous order according to the ABI and the language spec, but it will almost
certainly cause previously-working code to fail. If we offer an option to
switch from .ctors to .init_array, and encourage such code to use explicit
priorities where order really matters, I'd think that would be OK.

[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 #11 from Iain Sandoe  2010-12-13 20:23:40 
UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > hm  although we have:
> > 
> > gcc/common.opt:Common Joined Var(plugindir_string) Init(0)
> > 
> > I get
> 
> 
> > (gdb) print plugindir_string
> > $1 = 0x 
> > 
> > which is the origin of the current fail (there will be other issues related 
> > to
> > the FIXME, I'm sure).
> 
> independent of whether -iplugindir is given on the c/l.

in fact, the whole of global_options looks suspiciously un-initialized.

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

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  2010-12-13 20:16:23 
UTC ---

perhaps it would be safer to name the fallback section:

>>  : darwin_sections[text_unlikely_fallback_section]);


>> DEF_SECTION (text_unlikely_fallback_section, SECTION_CODE|SECTION_NO_ANCHOR,
 ".section __TEXT,__unlikely_flbk,regular,pure_instructions", 0)

(limit of 16chars for the section name == "unlikely fallback" )

then there's no danger of a section name clash when someone tries to build 
named_section ( "__TEXT,__unlikely,regular,pure_instruction",  )

(If the regtest works w/out this, then perhaps not necessary ... )

[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 #10 from Iain Sandoe  2010-12-13 20:09:10 
UTC ---
(In reply to comment #9)
> hm  although we have:
> 
> gcc/common.opt:Common Joined Var(plugindir_string) Init(0)
> 
> I get


> (gdb) print plugindir_string
> $1 = 0x 
> 
> which is the origin of the current fail (there will be other issues related to
> the FIXME, I'm sure).

independent of whether -iplugindir is given on the c/l.

[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 #9 from Iain Sandoe  2010-12-13 20:05:52 
UTC ---
hm  although we have:

gcc/common.opt:Common Joined Var(plugindir_string) Init(0)

I get

Breakpoint 1 at 0x886ea4: file /GCC/gcc-live-trunk/gcc/plugin.c, line 880.
(gdb) run
Starting program: /Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/cc1 -E -quiet -v
-iprefix
/Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/../lib/gcc/powerpc-apple-darwin9/4.6.0/
-isystem gcc/include -isystem gcc/include-fixed -D__DYNAMIC__ -iplugindir=bar
/GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/plugin/plugindir1.c -fPIC
-mmacosx-version-min=10.5.8 -m32 -fplugin=foo -fpch-preprocess -o plugindir1.i
Reading symbols for shared libraries . done

Breakpoint 1, default_plugin_dir_name () at
/GCC/gcc-live-trunk/gcc/plugin.c:880
880   if (!plugindir_string)
(gdb) print plugindir_string
$1 = 0x 

which is the origin of the current fail (there will be other issues related to
the FIXME, I'm sure).

[Bug fortran/46625] libquadmath: Mangle internal symbols; rename __float128 <-> string functions

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2010-12-13 
19:58:49 UTC ---
FIXED on the trunk (4.6)

[Bug fortran/46625] libquadmath: Mangle internal symbols; rename __float128 <-> string functions

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2010-12-13 
19:44:51 UTC ---
Author: burnus
Date: Mon Dec 13 19:44:38 2010
New Revision: 167768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167768
Log:
2010-12-13  Tobias Burnus  

PR fortran/46625
* gdtoa/gdtoaimp.h: Mangle internal functions by
prefixing them with __quadmath. Don't use gdtoa's strcp(y).
* gdtoa/g_Qfmt.c (g_Qfmt): Use strcpy instead of strcp.
* gdtoa/misc.c (strcpy): Renamed from strcp and only use
if NO_STRING_H is set.
* quadmath-imp.h (__quadmath_rem_pio2q,
* __quadmath_kernel_sincosq
__quadmath_kernel_sinq, __quadmath_kernel_cosq): Added
__quadmath prefix to internal functions.
* math/cosq.c (cosq): Ditto.
* math/sinq.c (cosq): Ditto.
* math/tanq.c (tanq,__quadmath_kernel_tanq): Ditto.
* math/rem_pio2q.c (rem_pio2, __quadmath_kernel_rem_pio2):
* Ditto.
* math/sinq_kernel.c (__quadmath_kernel_sinq): Ditto.
* math/cosq_kernel.c (__quadmath_kernel_cosq): Ditto.


Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/gdtoa/g_Qfmt.c
trunk/libquadmath/gdtoa/gdtoaimp.h
trunk/libquadmath/gdtoa/misc.c
trunk/libquadmath/math/cosq.c
trunk/libquadmath/math/cosq_kernel.c
trunk/libquadmath/math/rem_pio2q.c
trunk/libquadmath/math/sincosq.c
trunk/libquadmath/math/sincosq_kernel.c
trunk/libquadmath/math/sinq.c
trunk/libquadmath/math/sinq_kernel.c
trunk/libquadmath/math/tanq.c
trunk/libquadmath/quadmath-imp.h

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #49 from H.J. Lu  2010-12-13 19:41:15 
UTC ---
A linker patch is posted at

http://sourceware.org/ml/binutils/2010-12/msg00439.html

[Bug tree-optimization/46928] data dependence analysis fails on constant array accesses

[spop at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Pop  2010-12-13 19:30:19 
UTC ---
The code from comment #4 comes from 
./cc1 -O2 -ftree-loop-distribution -fdump-tree-ldist-details
as on -O3 we end up unrolling all the loops.

[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

--- Comment #8 from Dominique d'Humieres  2010-12-13 
19:22:56 UTC ---
On x86_64-apple-darwin10.5.0, the first test passes as:

Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/plugin/finish_unit-test-1.c 
-fplugin=./finish_unit_plugin.so -O -S  -m32 -o finish_unit-test-1.s   
(timeout = 300)
PASS: gcc.dg/plugin/finish_unit-test-1.c -fplugin=./finish_unit_plugin.so (test
for excess errors)
Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/plugin/plugindir1.c   -c -fplugin=foo -S 
-m32 -o plugindir1.s(timeout = 300)
cc1: fatal error: inacessible plugin file /opt/gcc/build_w/gcc/plugin/foo.so
expanded from short plugin name foo: No such file or directory^M
compilation terminated.^M
compiler exited with status 1
output is:
cc1: fatal error: inacessible plugin file /opt/gcc/build_w/gcc/plugin/foo.so
expanded from short plugin name foo: No such file or directory^M
compilation terminated.^M

PASS: gcc.dg/plugin/plugindir1.c (test for excess errors)

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from janus at gcc dot gnu.org 2010-12-13 19:22:26 UTC ---
Fixed with r167767. Closing.

Thanks for the report!

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2010-12-13 19:18:08 UTC ---
Author: janus
Date: Mon Dec 13 19:17:46 2010
New Revision: 167767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167767
Log:
2010-12-13  Janus Weil  

PR fortran/46201
* trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer
components called on a dimensionful base object.

2010-12-13  Janus Weil  

PR fortran/46201
* gfortran.dg/proc_ptr_comp_27.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_27.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

--- Comment #13 from Jorn Wolfgang Rennecke  
2010-12-13 19:16:47 UTC ---
(In reply to comment #12)
> On Sat, 11 Dec 2010, amylaar at gcc dot gnu.org wrote:
> 
> > We don't have any current decimal floating or fixed-point type size macros
> > to replace.  As discussed elsewhere, the stdint type, wchar type, and ada 
> > long
> 
> Yes we do.  The definitions starting with DECIMAL32_TYPE_SIZE in 
> defaults.h.

Are these really supposed to be a target interface?  They are not documented,
nowhere overridden, and besides, it would appear odd to have a
DECIMAL32_TYPE_SIZE of, say, 31 bits.
It seems these macros just serve to make the code more readable.
Maybe they should be moved to tree.h ?

> 
> > DEFHOOK
> > (atomic_type,
> 
> The name should reflect that this is purely about sig_atomic_t and not 
> about any other form of atomicity - that is, sig_atomic_type or similar.

Point taken.  Using sig_atomic_type as the hook name makes sense.

[Bug c/46929] Xutil.h and Complex - some trouble

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-12-13 
19:14:39 UTC ---
There is a #define somewhere in the chain of X11/Xutil.h so this is not a GCC
issue.

[Bug c/46929] New: Xutil.h and Complex - some trouble

[lisp2d at lisp2d dot net]

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

   Summary: Xutil.h and Complex - some trouble
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net


After including Xutil.h some trouble with name Complex

main.c:

//structComplex{};
#include
structComplex{};
intmain(void){return0;}

>gcc main.c

main.c:3:8: error: expected ‘{’ before numeric constant

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

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  2010-12-13 
19:10:55 UTC ---
> here is fix ... but I dunno if it's the "Right" fix --- so I'll let Mike &|
> Honza comment... 

The patch fixed the failures. I am regstrapping. Thanks!

[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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.13 19:09:16
 Ever Confirmed|0   |1

--- Comment #7 from Iain Sandoe  2010-12-13 19:09:16 
UTC ---
c/l:

 ./gcc/xgcc -Bgcc /GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/plugin/plugindir1.c 
 -c -fplugin=foo -S  -m32 -o plugindir1.s

(gdb) bt
#0  0x9757f928 in strlen ()
#1  0x00eff460 in vconcat_length (first=0x , args=0xbfffef8c "") at /GCC/gcc-live-trunk/libiberty/concat.c:76
#2  0x00eff6a4 in concat (first=0x )
at /GCC/gcc-live-trunk/libiberty/concat.c:159
#3  0x00885274 in add_new_plugin (plugin_name=0xb3b6 "foo") at
/GCC/gcc-live-trunk/gcc/plugin.c:157
#4  0x00879444 in handle_common_deferred_options () at
/GCC/gcc-live-trunk/gcc/opts-global.c:385
#5  0x009e83d4 in toplev_main (argc=20, argv=0xb140) at
/GCC/gcc-live-trunk/gcc/toplev.c:1923
#6  0x00142760 in main (argc=20, argv=0xb140) at
/GCC/gcc-live-trunk/gcc/main.c:36

the code for plugin.c: around line 157:

152   base_name = CONST_CAST (char*, plugin_name);
153   /* FIXME: the ".so" suffix is currently builtin, since plugins
154  only work on ELF host systems like e.g. Linux or Solaris.
155  When plugins shall be available on non ELF systems such as
156  Windows or MacOS, this code has to be greatly improved.  */
157   plugin_name = concat (default_plugin_dir_name (), "/",
158 plugin_name, ".so", NULL);
159   if (access (plugin_name, R_OK))
160 fatal_error
161   ("inacessible plugin file %s expanded from short plugin name
%s: %m",

so we probably need to improve the robustness... 
out of time for now ..

[Bug tree-optimization/46928] data dependence analysis fails on constant array accesses

[sebpop at gmail dot com]

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

--- Comment #4 from sebpop at gmail dot com  
2010-12-13 19:05:58 UTC ---
The code that is produced looks like this just after loop
distribution, i.e., we generate memset zero only by distributing the
innermost loop:

mad_synth_mute (struct mad_synth * synth)
{
  long unsigned int D.2739;
  long unsigned int D.2740;
  long unsigned int D.2741;
  long unsigned int D.2742;
  long unsigned int D.2743;
  struct mad_synth * D.2744;
  long unsigned int D.2730;
  long unsigned int D.2731;
  long unsigned int D.2732;
  long unsigned int D.2733;
   D.2734;
   D.2735;
   D.2736;
  long unsigned int D.2737;
  struct mad_synth * D.2738;
  long unsigned int D.2721;
  long unsigned int D.2722;
  long unsigned int D.2723;
  long unsigned int D.2724;
   D.2725;
   D.2726;
   D.2727;
  long unsigned int D.2728;
  struct mad_synth * D.2729;
  long unsigned int D.2712;
  long unsigned int D.2713;
  long unsigned int D.2714;
  long unsigned int D.2715;
   D.2716;
   D.2717;
   D.2718;
  long unsigned int D.2719;
  struct mad_synth * D.2720;
  unsigned int pretmp.2;
  unsigned int v;
  unsigned int s;
  unsigned int ch;

:
  goto ;

:
Invalid sum of incoming frequencies 139, should be 
  s_9 = s_29 + 1;
  if (s_9 != 16)
goto ;
  else
goto ;

:

:
Invalid sum of outgoing probabilities 12.5%
  # s_29 = PHI <0(10), s_9(6)>
  D.2712_25 = (long unsigned int) s_29;
  D.2713_22 = (long unsigned int) ch_28;
  D.2714_1 = D.2713_22 * 64;
  D.2715_2 = D.2712_25 + D.2714_1;
  D.2716_3 = () D.2715_2;
  D.2717_26 = D.2716_3 + 48;
  D.2718_27 = D.2717_26 * 32;
  D.2719_24 = (long unsigned int) D.2718_27;
  D.2720_23 = synth_7(D) + D.2719_24;
  __builtin_memset (D.2720_23, 0, 32);
  D.2721_13 = (long unsigned int) s_29;
  D.2722_12 = (long unsigned int) ch_28;
  D.2723_11 = D.2722_12 * 64;
  D.2724_6 = D.2721_13 + D.2723_11;
  D.2725_20 = () D.2724_6;
  D.2726_32 = D.2725_20 + 32;
  D.2727_33 = D.2726_32 * 32;
  D.2728_34 = (long unsigned int) D.2727_33;
  D.2729_35 = synth_7(D) + D.2728_34;
  __builtin_memset (D.2729_35, 0, 32);
  D.2730_36 = (long unsigned int) s_29;
  D.2731_37 = (long unsigned int) ch_28;
  D.2732_38 = D.2731_37 * 64;
  D.2733_39 = D.2730_36 + D.2732_38;
  D.2734_40 = () D.2733_39;
  D.2735_41 = D.2734_40 + 16;
  D.2736_42 = D.2735_41 * 32;
  D.2737_43 = (long unsigned int) D.2736_42;
  D.2738_44 = synth_7(D) + D.2737_43;
  __builtin_memset (D.2738_44, 0, 32);
  D.2739_45 = (long unsigned int) ch_28;
  D.2740_46 = D.2739_45 * 64;
  D.2741_47 = (long unsigned int) s_29;
  D.2742_48 = D.2740_46 + D.2741_47;
  D.2743_49 = D.2742_48 * 32;
  D.2744_50 = synth_7(D) + D.2743_49;
  __builtin_memset (D.2744_50, 0, 32);
  goto ;

:
  ch_10 = ch_28 + 1;
  if (ch_10 != 2)
goto ;
  else
goto ;

:

:
  # ch_28 = PHI <0(2), ch_10(9)>
  goto ;

:
  return;

}

and the assembler:

mad_synth_mute:
.LFB0:
.cfi_startproc
movq%rdi, %r9
xorl%r8d, %r8d
.L2:
leaq16(%r8), %rsi
movq%r9, %rdx
movq%r8, %rax
.p2align 4,,10
.p2align 3
.L3:
leaq48(%rax), %rcx
salq$5, %rcx
addq%rdi, %rcx
movq$0, (%rcx)
movq$0, 8(%rcx)
movq$0, 16(%rcx)
movq$0, 24(%rcx)
leaq32(%rax), %rcx
salq$5, %rcx
addq%rdi, %rcx
movq$0, (%rcx)
movq$0, 8(%rcx)
movq$0, 16(%rcx)
movq$0, 24(%rcx)
leaq16(%rax), %rcx
addq$1, %rax
salq$5, %rcx
addq%rdi, %rcx
movq$0, (%rcx)
movq$0, 8(%rcx)
movq$0, 16(%rcx)
movq$0, 24(%rcx)
movq$0, (%rdx)
movq$0, 8(%rdx)
movq$0, 16(%rdx)
movq$0, 24(%rdx)
addq$32, %rdx
cmpq%rsi, %rax
jne.L3
addq$64, %r8
addq$2048, %r9
cmpq$128, %r8
jne.L2
rep
ret

[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

--- Comment #6 from Dominique d'Humieres  2010-12-13 
19:05:18 UTC ---
Note that adding ' -iplugindir=my-plugindir' to the option does not change the
results.

[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

--- Comment #5 from Dominique d'Humieres  2010-12-13 
19:02:59 UTC ---
GDB session:

(gdb) watch -location global_options.x_plugindir_string
Hardware watchpoint 1: *(const char **) 12424292
(gdb) run -fplugin=foo
/opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/plugin/plugindir4.c
Starting program: /opt/gcc/gcc4.6w/libexec/gcc/powerpc-apple-darwin9/4.6.0/cc1
-fplugin=foo /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/plugin/plugindir4.c
Reading symbols for shared libraries +++warning: Could not find object
file "/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/iconv.o" - no
debug information available for "./iconv.c".

warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/localcharset.o" -
no debug information available for "./../libcharset/lib/localcharset.c".

warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/relocatable.o" - no
debug information available for "./relocatable.c".

.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffc
0x94afe928 in strlen ()
(gdb) bt
#0  0x94afe928 in strlen ()
#1  0x008b6414 in concat (first=0x )
at ../../gcc-4.6-work/libiberty/concat.c:76
#2  0x0051e624 in add_new_plugin (plugin_name=0xbfffdac2 "foo") at
../../gcc-4.6-work/gcc/plugin.c:157
#3  0x0051584c in handle_common_deferred_options () at
../../gcc-4.6-work/gcc/opts-global.c:385
#4  0x005e3808 in toplev_main (argc=3, argv=0x) at
../../gcc-4.6-work/gcc/toplev.c:1923
#5  0x24f4 in start ()
(gdb) watch global_options.x_plugindir_string
Hardware watchpoint 2: global_options.x_plugindir_string
(gdb) run -fplugin=foo
/opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/plugin/plugindir4.c
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/gcc/gcc4.6w/libexec/gcc/powerpc-apple-darwin9/4.6.0/cc1
-fplugin=foo /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/plugin/plugindir4.c

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffc
0x94afe928 in strlen ()

[Bug tree-optimization/46928] data dependence analysis fails on constant array accesses

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  2010-12-13 18:58:41 
UTC ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01016.html

[Bug target/46883] GCC ICE with error: unrecognizable insn

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||bernds at codesourcery dot
   ||com, uweigand at gcc dot
   ||gnu.org

--- Comment #3 from Ulrich Weigand  2010-12-13 
18:54:48 UTC ---
Confirmed.  A somewhat shorter testcase is:

void
bar (unsigned char *q, unsigned short *data16s, int len)
{
  int i;

  for (i = 0; i < len; i++)
{
  q[2 * i] =
(((data16s[i] & 0xFF) << 8) | ((data16s[i] >> 8) & 0xFF)) & 0xFF;
  q[2 * i + 1] =
((unsigned short)
 (((data16s[i] & 0xFF) << 8) | ((data16s[i] >> 8) & 0xFF))) >> 8;
}
}

The problem seems to be that an insn:
(insn 88 86 90 4 (set (reg:SI 240)
(zero_extend:SI (subreg:QI (mem:HI (post_inc:SI (reg:SI 220 [ ivtmp.22
])) [2 MEM[(short unsigned int *)D.2066_62 + 4294967294B]+0 S2 A16]) 0)))
a.c:10 152 {*arm_zero_extendqisi2}
 (expr_list:REG_INC (reg:SI 220 [ ivtmp.22 ])
(nil)))

gets transformed by a splitter into:
(insn 122 86 90 4 (set (reg:SI 240)
(and:SI (subreg:SI (mem:HI (post_inc:SI (reg:SI 220 [ ivtmp.22 ])) [2
MEM[(short unsigned int *)D.2066_62 + 4294967294B]+0 S2 A16]) 0)
(const_int 255 [0xff]))) a.c:10 -1
 (expr_list:REG_INC (reg:SI 220 [ ivtmp.22 ])
(nil)))

But this isn't accepted by the andsi3 pattern, since the (subreg (mem ..)) does
not match the s_register_operand predicate.

The splitter
(define_split
  [(set (match_operand:SI 0 "register_operand" "")
(zero_extend:SI (match_operand:QI 1 "register_operand" "")))]
  "!arm_arch6"
  [(set (match_dup 0) (ashift:SI (match_dup 2) (const_int 24)))
   (set (match_dup 0) (lshiftrt:SI (match_dup 0) (const_int 24)))]
{
  operands[2] = simplify_gen_subreg (SImode, operands[1], QImode, 0);
  if (TARGET_ARM)
{
  emit_insn (gen_andsi3 (operands[0], operands[2], GEN_INT (255)));
  DONE;
}
})

was introduced by Bernd Schmidt's patch to improve zero- and sign-extension
handling on ARM (committed 2010-07-02), PR 42172:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00832.html

Bernd, do you have any suggestions how to fix this?

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

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2010-12-13 18:53:41 UTC ---
On Mon, 13 Dec 2010, dominiq at lps dot ens.fr wrote:

> I am fluent neither in C nor gdb. Does not "first=0x  0x out of bounds>" answer the first question? I tried to go a little
> bit further by setting breakpoints at 'add_new_plugin' and
> 'default_plugin_dir_name' and tried to print 'plugindir_string', but ran out 
> of
> idea at
> 
> Breakpoint 3, default_plugin_dir_name () at 
> ../../gcc-4.6-work/gcc/plugin.c:880
> 880  if (!plugindir_string)
> (gdb) p plugindir_string
> No symbol "plugindir_string" in current context.

Thats global_options.x_plugindir_string.  If it's an invalid pointer then 
setting a watchpoint on it might help show when that pointer was stored 
(or there may be other memory debugging tools available on your platform).

In any case, please post the exact cc1 command line.

[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c

[asharif at gcc dot gnu.org]

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

--- Comment #5 from asharif at gcc dot gnu.org 2010-12-13 18:49:50 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Yeah, if #c2 tests what the test meant to test, then it is much preferrable
> > over the thing that got committed, which has lots of issues.
> 
> Sorry about the trunk breakage. I reverted the testcase. Yes, it was meant for
> x86-64. I'll fix the testcase and repost a patch to the mailing list.
> 
> Reverted in r167756.

Update:

The test doesn't do what #c3 is doing. The test is supposed to fail with this
patch: http://gcc.gnu.org/viewcvs?view=revision&revision=153780 and pass
otherwise. That patch limits the alignment to MAX_SUPPORTED_STACK_ALIGNMENT. 

The test described in #c3 will still pass with that patch. 


As far as the uninitialized variables are concerned, I can set them all to 0
and it doesn't affect whether the test passes or fails.

Can you assign this bug to me?

Also, can I submit my patch with the lp64 dejaGNU filter?

Thanks!

[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-12-13 18:48:22 UTC ---
On Mon, 13 Dec 2010, pinskia at gcc dot gnu.org wrote:

> I think this is invalid as GNU/Linux defaults to including sincos as a 
> builtin.  If you want to disable the builtin then use 
> -fno-builtin-sincos.

It seems valid to me.  The options specified included -ansi (i.e. 
-std=c90) which implies -fno-builtin-sincos.

Whether GCC *generates* calls to a function when that function does not 
appear in the source code is independent of how it *handles* calls to a 
function in the source code, and -fno-builtin-* deals with the latter 
only.  It's always OK to generate calls to C90 function such as memcpy 
(standards.texi list the subset that may be used in freestanding mode) or 
to C99 functions when in C99 mode or to reserved-namespace functions in 
libgcc.  It's not OK to generate calls to non-reserved-namespace libc/libm 
functions, when in a strict conformance mode such as -std=c90/-std=c99, if 
those functions are outside the language version specified and the calls 
do not appear in the source code.  This includes sincos.

[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

--- Comment #3 from Dominique d'Humieres  2010-12-13 
18:44:50 UTC ---
> > #0  0x94afe928 in strlen ()
> > #1  0x008b6414 in concat (first=0x  > bounds>)
> > at ../../gcc-4.6-work/libiberty/concat.c:76
> > #2  0x0051e660 in add_new_plugin (plugin_name=0xbfffdac2 "foo") at
> > ../../gcc-4.6-work/gcc/plugin.c:157
>
> Which of the arguments in the call to concat is invalid?  How did that 
> argument get its value?

I am fluent neither in C nor gdb. Does not "first=0x " answer the first question? I tried to go a little
bit further by setting breakpoints at 'add_new_plugin' and
'default_plugin_dir_name' and tried to print 'plugindir_string', but ran out of
idea at

Breakpoint 3, default_plugin_dir_name () at ../../gcc-4.6-work/gcc/plugin.c:880
880  if (!plugindir_string)
(gdb) p plugindir_string
No symbol "plugindir_string" in current context.

[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.

[jameskuyper at verizon dot net]

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

--- Comment #2 from James Kuyper Jr.  
2010-12-13 18:41:55 UTC ---
info gcc says:

Functions which would normally be built in but do not have
 semantics defined by ISO C (such as `alloca' and `ffs') are not
 built-in functions with `-ansi' is used.

[Bug libfortran/46607] [4.6 Regression] libgfortran relocated install fails

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2010-12-13 18:39:47 UTC ---
On Mon, 13 Dec 2010, rwild at gcc dot gnu.org wrote:

> So is this only about the MinGW case?  Because there, we should just fix
> libtool to not ever relink.

No, it's about the general issue; MinGW is simply one of the cases where 
the "make install prefix=" semantics are preferred to DESTDIR (but in 
general when dealing with lots of versions of lots of software each may 
have cases where the other doesn't work).

[Bug tree-optimization/46928] data dependence analysis fails on constant array accesses

[xinliangli at gmail dot com]

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

davidxl  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #2 from davidxl  2010-12-13 18:38:40 
UTC ---
Is memset guaranteed to be asynchronous safe? Otherwise such transformation is
not legal in signal handle code.

Icc does not covert it to memset, but unrolls differently -- this is where the
tuing in gcc should be done as well.

David

[Bug bootstrap/46650] r167010 breaks --enable-build-with-cxx

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  2010-12-13 
18:34:48 UTC ---
Author: ian
Date: Mon Dec 13 18:34:45 2010
New Revision: 167764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167764
Log:
PR bootstrap/46650
* system.h: Include cstring for cxx bootstrap.

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

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

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #8 from mrs at gcc dot gnu.org  2010-12-13 
18:32:56 UTC ---
Ok.

[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2010-12-13 18:30:31 UTC 
---
Author: ro
Date: Mon Dec 13 18:30:20 2010
New Revision: 167762

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167762
Log:
Backport from mainline:
2010-04-28  Rainer Orth  

PR target/4
* config/alpha/osf.h (ASM_OUTPUT_LOCAL): Redefine.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/alpha/osf.h

[Bug target/46908] printf not handling printing of double correctly in certain cases

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution||INVALID

--- Comment #6 from Joseph S. Myers  2010-12-13 
18:28:22 UTC ---
GCC knows about the limitations of the Windows (msvcrt) printf and scanf
functions, which do not support all standard C99 formats, and the warnings are
telling you that they are not supported by those libraries.  The MinGW
libraries (wrapping msvcrt) are a separate project from GCC and there is no GCC
bug here.

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

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.13 18:22:21
 CC||iains at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #7 from Iain Sandoe  2010-12-13 18:22:21 
UTC ---
the problem is infinite recursion -- the bailing of darwin_function_section
when reodering is off causes a fallback to darwin_text_section ()  -- which
calls unlikely_text_section () ... and we get a stack meltdown...

here is fix ... but I dunno if it's the "Right" fix --- so I'll let Mike &|
Honza comment... 


Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c(revision 167755)
+++ gcc/config/darwin.c(working copy)
@@ -1150,7 +1150,7 @@ darwin_text_section (int reloc, int weak)
   if (reloc)
 return (weak
 ? darwin_sections[text_unlikely_coal_section]
-: unlikely_text_section ());
+: darwin_sections[text_unlikely_section]);
   else
 return (weak
 ? darwin_sections[text_coal_section]
Index: gcc/config/darwin-sections.def
===
--- gcc/config/darwin-sections.def(revision 167755)
+++ gcc/config/darwin-sections.def(working copy)
@@ -30,6 +30,8 @@ along with GCC; see the file COPYING3.  If not see
 /* .text handled in varasm.c  */
 DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
  ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
+DEF_SECTION (text_unlikely_section, SECTION_CODE|SECTION_NO_ANCHOR,
+ ".section __TEXT,__unlikely,regular,pure_instructions", 0)
 DEF_SECTION (text_unlikely_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
  ".section __TEXT,__text_unlikely_coal,"
  "coalesced,pure_instructions", 0)

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

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2010-12-13 18:20:16 UTC ---
On Sun, 12 Dec 2010, dominiq at lps dot ens.fr wrote:

> The backtrace is
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xfffc
> 0x94afe928 in strlen ()
> (gdb) bt
> #0  0x94afe928 in strlen ()
> #1  0x008b6414 in concat (first=0x )
> at ../../gcc-4.6-work/libiberty/concat.c:76
> #2  0x0051e660 in add_new_plugin (plugin_name=0xbfffdac2 "foo") at
> ../../gcc-4.6-work/gcc/plugin.c:157

Which of the arguments in the call to concat is invalid?  How did that 
argument get its value?

[Bug tree-optimization/46928] data dependence analysis fails on constant array accesses

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.13 18:09:36
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Sebastian Pop  2010-12-13 18:09:36 
UTC ---
Mine.

BTW, this PR comes from example 2 of http://blog.regehr.org/archives/320

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[joseph at codesourcery dot com]

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

--- Comment #48 from joseph at codesourcery dot com  2010-12-13 18:08:00 UTC ---
On Sat, 11 Dec 2010, hjl.tools at gmail dot com wrote:

> We introduced .init_array into gABI 10 years ago so that we can avoid
> those crazy things in crt*.o.  It is the time now to switch for Linux/x86/

I see no reason it could make sense for this to be specific to x86.  GCC 
should be consistent between different targets where possible.  As a gABI 
feature, this indicates enabling it for all ELF targets rather than just 
for x86 GNU/Linux - and maybe disabling for specific target OSes if there 
prove to be problems for those specific ELF targets.

[Bug tree-optimization/46928] New: data dependence analysis fails on constant array accesses

[spop at gcc dot gnu.org]

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

   Summary: data dependence analysis fails on constant array
accesses
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@gcc.gnu.org


In this code we should be able to convert the inner loop to memset zero with
./cc1 -O3 bug.c

typedef int mad_fixed_t;
struct mad_pcm
{
  unsigned int samplerate;
  unsigned short channels;
  unsigned short length;
  mad_fixed_t samples[2][1152];
};
struct mad_synth
{
  mad_fixed_t filter[2][2][2][16][8];
  unsigned int phase;
  struct mad_pcm pcm;
};
void mad_synth_mute (struct mad_synth *synth);
void
mad_synth_mute (struct mad_synth *synth)
{
  unsigned int ch;
  unsigned int s;
  unsigned int v;

  ch = 0U;
  while (ch < 2U)
{
  s = 0U;
  while (s < 16U)
{
  v = 0U;
  while (v < 8U)
{
  synth->filter[ch][1][1][s][v] = 0;
  synth->filter[ch][1][0][s][v] = 0;
  synth->filter[ch][0][1][s][v] = 0;
  synth->filter[ch][0][0][s][v] = 0;
  v++;
}
  s++;
}
  ch++;
}
  return;
}

When looking at the output of the dump
./cc1  -O3 -fdump-tree-ldist-details bug.c
the data dependence analysis fails to analyze the overlapping iterations for
s_29:

(compute_affine_dependence
  (stmt_a = 
synth_7(D)->filter[ch_28][0][1][s_29][v_30] = 0;
)
  (stmt_b = 
synth_7(D)->filter[ch_28][0][0][s_29][v_30] = 0;
)
(subscript_dependence_tester 
(analyze_overlapping_iterations 
  (chrec_a = {0, +, 1}_3)
  (chrec_b = {0, +, 1}_3)
  (overlap_iterations_a = [0]
)
  (overlap_iterations_b = [0]
)
)
(analyze_overlapping_iterations 
  (chrec_a = s_29)
  (chrec_b = s_29)
  (overlap_iterations_a = not known
)
  (overlap_iterations_b = not known
)
)
(dependence classified: scev_not_known)
)
)

When we remove the s loop, we transform the following code with memset zero:

  ch = 0U;
  while (ch < 2U)
{
  v = 0U;
  while (v < 8U)
{
  synth->filter[ch][1][1][0][v] = 0;
  synth->filter[ch][1][0][0][v] = 0;
  synth->filter[ch][0][1][0][v] = 0;
  synth->filter[ch][0][0][0][v] = 0;
  v++;
}
  ch++;
}

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #11 from Alexander Monakov  2010-12-13 
18:05:21 UTC ---
Only Changelog changed have been checked in.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  2010-12-13 17:58:13 UTC ---
On Sat, 11 Dec 2010, amylaar at gcc dot gnu.org wrote:

> We don't have any current decimal floating or fixed-point type size macros
> to replace.  As discussed elsewhere, the stdint type, wchar type, and ada long

Yes we do.  The definitions starting with DECIMAL32_TYPE_SIZE in 
defaults.h.

> DEFHOOK
> (atomic_type,

The name should reflect that this is purely about sig_atomic_t and not 
about any other form of atomicity - that is, sig_atomic_type or similar.

[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c

[asharif at gcc dot gnu.org]

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

asharif at gcc dot gnu.org changed:

   What|Removed |Added

 CC||asharif at gcc dot gnu.org

--- Comment #4 from asharif at gcc dot gnu.org 2010-12-13 17:49:40 UTC ---
(In reply to comment #3)
> Yeah, if #c2 tests what the test meant to test, then it is much preferrable
> over the thing that got committed, which has lots of issues.

Sorry about the trunk breakage. I reverted the testcase. Yes, it was meant for
x86-64. I'll fix the testcase and repost a patch to the mailing list.

Reverted in r167756.

[Bug lto/46879] [4.6 Regression] ICE: in separate_decls_in_region_debug_bind, at tree-parloops.c:778 with -flto -ftree-parallelize-loops -gdwarf-3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2010-12-13 
17:41:24 UTC ---
Fixed.

[Bug debug/46867] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Jakub Jelinek  2010-12-13 
17:40:49 UTC ---
Fixed.

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

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 |

--- Comment #4 from janus at gcc dot gnu.org 2010-12-13 17:39:05 UTC ---
The ICE is fixed by the following patch:


Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 167750)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3594,7 +3594,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *

   if (!se->direct_byref)
 {
-  if (sym->attr.dimension || (comp && comp->attr.dimension))
+  if ((sym->attr.dimension && !comp) || (comp && comp->attr.dimension))
 {
   if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
 {


Will commit as obvious after bootstrapping.

[Bug lto/46879] [4.6 Regression] ICE: in separate_decls_in_region_debug_bind, at tree-parloops.c:778 with -flto -ftree-parallelize-loops -gdwarf-3

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-12-13 
17:37:27 UTC ---
Author: jakub
Date: Mon Dec 13 17:37:20 2010
New Revision: 167755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167755
Log:
PR lto/46879
* lto-streamer-out.c (output_gimple_stmt): Never replace first
GIMPLE_DEBUG argument with MEM_REF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c

[Bug debug/46867] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-12-13 
17:36:31 UTC ---
Author: jakub
Date: Mon Dec 13 17:36:26 2010
New Revision: 167754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167754
Log:
PR debug/46867
* var-tracking.c (emitted_notes, string_pointer_flags): Removed.
(emit_note_insn_var_location): Remove ENABLE_RTL_CHECKING verification.
(vt_emit_notes): Don't initialize and destroy emitted_notes.

* gcc.dg/pr46867.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46867.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug fortran/46797] libquadmath: "make install" relinks libgfortran

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2010-12-13 
17:35:24 UTC ---
(In reply to comment #2)
> Well, I'd say works as it should: relinking is used to avoid run paths to
> in-tree directories.  What am I missing here?  Thanks.

Well, if it is supposed to be like that, one can close the bug as INVALID.

I was only surprised that libgfortran seems to be the only library which is
relinked during install - and I did not think about whether it could be
necessary.

[Bug fortran/46371] [Coarray] [OOP] SELECT TYPE: scalar coarray variable is rejected

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2010-12-13 
17:32:22 UTC ---
(In reply to comment #0)
>   type(foo), allocatable :: o_foo[:]

That should be "CLASS(foo)" - sorry for the typo.


TODO:

a) There is a gfc_is_coindexed() check missing for ASSOCIATE and SELECT TYPE,
cf. link and "1 INVALID" part of comment 0

b) "2 VALID" and "3 VALID" do not work:

  j = a[1]%i
   1
Error: Coarray designator at (1) but '__tmp_type_foo' is not a coarray

I think at least "attr.codimension" needs to be added during match time -
resolve time it too late. The variable is generated at select_type_set_tmp. I
tried the following (cf. select_type_set_tmp part of the patch), which does not
seem to be sufficient - though it is enough to trigger the issue in resolve.c
(cf. resolve.c part of the patch).


diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 44da1bb..6521e79 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4531,6 +4531,8 @@ select_type_set_tmp (gfc_typespec *ts)
  &tmp->n.sym->as, false);
   tmp->n.sym->attr.class_ok = 1;
 }
+  if (select_type_stack->selector->attr.codimension)
+tmp->n.sym->attr.codimension = 1;
   tmp->n.sym->attr.select_type_temporary = 1;

   /* Add an association for it, so the rest of the parser knows it is
@@ -4591,8 +4593,14 @@ gfc_match_select_type (void)
   if (m != MATCH_YES)
 goto cleanup;

-  /* Check for F03:C811.  */
-  if (!expr2 && (expr1->expr_type != EXPR_VARIABLE || expr1->ref != NULL))
+  /* Check for F03:C811. Special case: scalar coarray.  */
+  if (!expr2 && (expr1->expr_type != EXPR_VARIABLE
+|| (expr1->ref != NULL
+&& (expr1->ref->next != NULL
+|| expr1->ref->type != REF_ARRAY
+|| expr1->ref->u.ar.type != AR_FULL
+|| expr1->ref->u.ar.dimen != 0
+|| expr1->ref->u.ar.codimen != 0
 {
   gfc_error ("Selector in SELECT TYPE at %C is not a named variable; "
 "use associate-name=>");
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a27fe2d..5102aea 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12121,6 +12121,7 @@ resolve_symbol (gfc_symbol *sym)
   if (((sym->ts.type == BT_DERIVED && sym->ts.u.derived->attr.coarray_comp)
|| sym->attr.codimension)
   && !(sym->attr.allocatable || sym->attr.dummy || sym->attr.save
+  || sym->attr.select_type_temporary
   || sym->ns->proc_name->attr.flavor == FL_MODULE
   || sym->ns->proc_name->attr.is_main_program
   || sym->attr.function || sym->attr.result || sym->attr.use_assoc))

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jan Hubicka  2010-12-13 
17:31:47 UTC ---
Fixed by my patch.

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  2010-12-13 
17:29:17 UTC ---
Author: hubicka
Date: Mon Dec 13 17:29:14 2010
New Revision: 167753

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

PR middle-end/45388
* decl2.c (start_objects): Do not generate collect2 recognicable name
for static ctor.
* ipa.c (cgraph_build_static_cdtor_1): Break out from ... ; add FINAL
parameter.
(cgraph_build_static_cdtor): ... here.
(build_cdtor): Use cgraph_build_static_cdtor_1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog

[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|amonakov at gcc dot gnu.org |unassigned at gcc dot
   ||gnu.org

--- Comment #4 from Alexander Monakov  2010-12-13 
17:24:59 UTC ---
Ouch.  The "obvious" fix:

diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index 5036fba..8fda288 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -626,16 +626,9 @@ scan_tree_for_params_int (tree cst,
ppl_Linear_Expression_t expr, mpz_t k)
 {
   mpz_t val;
   ppl_Coefficient_t coef;
-  int v = int_cst_value (cst);

   mpz_init (val);
-  mpz_set_si (val, 0);
-
-  /* Necessary to not get "-1 = 2^n - 1". */
-  if (v < 0)
-mpz_sub_ui (val, val, -v);
-  else
-mpz_add_ui (val, val, v);
+  tree_int_to_gmp (cst, val);

   mpz_mul (val, val, k);
   ppl_new_Coefficient (&coef);

Makes Graphite fail most tests because this scanning machinery curiously
depends on signed/unsigned conversions/overflow.  For example, when an IV upper
bound N-1 is expressed as (unsigned)(N + 0xU), the patch makes Graphite
actually generate N + 0xU as upper bound in the corresponding PPL
expression:

(gdb) p nb_iters
$2 = (tree) 0x77ff9ee0
(gdb) pt
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x77ed0540 precision
32 min  max 
pointer_to_this >

arg 0 

arg 0 
visited var def_stmt GIMPLE_NOP

version 6>>
arg 1  constant 4294967295>>
(gdb) call debug_ppl_linear_expr (ub_expr)
1 5
0 0 1 0 4294967295 

I don't know how to fix this; thus, unassigning.  Sorry.

[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-12-13 
17:23:05 UTC ---
I think this is invalid as GNU/Linux defaults to including sincos as a builtin.
 If you want to disable the builtin then use -fno-builtin-sincos.

[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu.org

--- Comment #6 from Ralf Wildenhues  2010-12-13 
17:17:08 UTC ---
Is this still an issue (with the correct Automake version installed)?  Thanks.

[Bug target/46927] New: flag -fstrict-volatile-bitfields affects volatile non-bitfields

[zsojka at seznam dot cz]

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

   Summary: flag -fstrict-volatile-bitfields affects volatile
non-bitfields
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22745
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22745
reduced testcase (from Qt/KDE headers)

Compiler output:
$ gcc testcase.C -fstrict-volatile-bitfields
testcase.C: In function 'void foo(S*)':
testcase.C:11:54: error: output number 0 not directly addressable
testcase.C:11:54: warning: use of memory input without lvalue in asm operand 1
is deprecated [enabled by default]

Tested revisions:
r167723 - fail
r161659 - fail
4.5 - doesn't know -fstrict-volatile-bitfields

[Bug c++/46300] Calls to internals _ITM_cxa_throw and _ITM_cxa_allocate_exception are not marked as safe

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2010-12-13 
17:11:52 UTC ---
Yeah, if #c2 tests what the test meant to test, then it is much preferrable
over the thing that got committed, which has lots of issues.

[Bug c/46926] New: Paired sin() cos() calls optimized to sincos() call.

[jameskuyper at verizon dot net]

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

   Summary: Paired sin() cos() calls optimized to sincos() call.
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jameskuy...@verizon.net


I discovered this problem when porting from a mandriva Linux system using gcc
4.2.2 to a centos linux system using gcc 4.4.4. After much simplification, I
can now demonstrate the problem with an extremely short example program:

#include 
#include 
void sincos(double val, double *sin_val, double *cos_val)
{
*sin_val = sin(val);
*cos_val = cos(val);

return;
}

int func(
double * pd
){
double cosine, sine;

/* must use value accessed through pointer; bug disappears
 * without the pointer access.
 */
cosine = cos(*pd);
sine = sin(*pd);

/* Need to use cosine[] and sine[], or optimizer drops them. */
return cosine < 0.0 && sine > 0.0 ? EXIT_FAILURE : EXIT_SUCCESS;
}

int main (void)
{
   double d=0.0;
   return func(&d) ;
}

In the original program, the sincos() function defined above occurred in a
third-party library designed for use with a fully conforming implementation of
C90. Such implementations cannot provide a sincos() function in their standard
C library in any way that would conflict with a user-defined function of the
same name. I compiled and linked this program using the following command:

gcc -ansi -pedantic -O1 -g sincos_prob.c -lm -o sincos_prob

When I execute the program, it produces a bus error. gdb indicates that the bus
error occurs inside a recursive (!?) call to sincos(). The problem does not
come up if I lower the optimization level to -O0.

The reason appears to be that, at optimization levels of 1 or higher, paired
calls to sin() and cos(), like those that occur in two seperate locations
above, are replaced with a single call to sincos() - in itself, a seemingly
reasonable thing to do. The sincos() definition provided by the third party
library is used in place of the one provided as an extension in the C standard
library, which also seems reasonable. Where this all goes wrong is inside the
body of the third-party library's definition of sincos(). The sin()/cos()
optimization turns that function into an infinitely recursive call to itself.

Because sincos() is not a C standard library routine, the code given above does
not violate any constraint, and has well defined behavior - behavior which does
not include generating a bus error.

When invoked in a mode that's supposed to be fully conforming to either C90 or
C99, the compiler should not generate spurious calls to functions whose names
are not reserved to the implementation. Use of a reserved name, such as
__sincos(), seems to me like it would be the simplest fix for this problem.

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2010-12-13 16:57:20 UTC ---
Here is an even more compact version of the test case (getting rid of the
INTERFACE statement):


type t
  procedure(character), nopass, pointer :: ppc
end type
type(t),dimension(1) :: v
print *,v(1)%ppc()
end


Apparently the procedure pointer component must be CHARACTER-valued in order to
trigger the ICE. Also the object which the PPC is invoked on must be an array.