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

[xunxun1982 at gmail dot com]

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

--- Comment #54 from PcX  2011-03-16 06:53:47 UTC 
---
(In reply to comment #53)
> If I don't use LTO Optimization, Vadim Zeitlin's patch works well.
> But if I use LTO Optimization, the compiling speed becomes vey slow, and the
> linker stage fails. I will get the information: 
> 
> lto1.exe: out of memory allocating 1900552 bytes
> lto-wrapper: g++ returned 1 exit status
> ld.exe: lto-wrapper failed
> collect2: ld returned 1 exit status
> 
> mingw32-make: *** [wxmsw28u_gcc.dll] Error 1

BTW, I use gcc 4.6.

[Bug target/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  2011-03-16 06:26:33 
UTC ---
Author: amodra
Date: Wed Mar 16 06:26:29 2011
New Revision: 171031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171031
Log:
PR target/45844
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't
create invalid offset address for vsx splat insn.
* config/rs6000/predicates.md (splat_input_operand): New.
* config/rs6000/vsx.md (vsx_splat_*): Use it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vsx.md

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

[xunxun1982 at gmail dot com]

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

PcX  changed:

   What|Removed |Added

 CC||xunxun1982 at gmail dot com

--- Comment #53 from PcX  2011-03-16 04:42:20 UTC 
---
If I don't use LTO Optimization, Vadim Zeitlin's patch works well.
But if I use LTO Optimization, the compiling speed becomes vey slow, and the
linker stage fails. I will get the information: 

lto1.exe: out of memory allocating 1900552 bytes
lto-wrapper: g++ returned 1 exit status
ld.exe: lto-wrapper failed
collect2: ld returned 1 exit status

mingw32-make: *** [wxmsw28u_gcc.dll] Error 1

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  2011-03-16 
04:10:09 UTC ---
Created attachment 23678
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23678
Valgrind out for test case that completes compilation

This attachment with the version of the test case that compiled without error
shows the valgrind errors.  Hope this helps isolate the problem.

[Bug c/48146] New: ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342

[regehr at cs dot utah.edu]

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

   Summary: ICE tree check: expected ssa_name, have var_decl in
has_zero_uses, at tree-flow-inline.h:342
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


regehr@home:~/volatile/bugs/tmp004$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/mnt/z/z/compiler-install/gcc-r171019-install/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/mnt/z/z/compiler-install/gcc-r171019-install
--program-prefix=r171019- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110315 (experimental) (GCC) 

regehr@home:~/volatile/bugs/tmp004$ current-gcc -c small.c -O2

small.c: In function ‘func_67’:
small.c:14:1: internal compiler error: tree check: expected ssa_name, have
var_decl in has_zero_uses, at tree-flow-inline.h:342
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

regehr@home:~/volatile/bugs/tmp004$ cat small.c


static unsigned char
safe_sub_func_int_s_s (int si1, unsigned char si2)
{
  return si1 ^ si2 & -si2 ^ si2 ? : si1 - si2;
}

int g_2[10] = {
  0x90AC204EL
};

volatile unsigned char g_39;

unsigned char
func_67 (unsigned short p_68)
{
  unsigned char l_92;
  unsigned char l_74;
  int *l = &g_2[6];
lbl_90:*l ^= 1;
  if (p_68)
goto lbl_93;
  for (l_74 = 0;; l_74 = safe_sub_func_int_s_s (l_74, 1))
{
  if (l_74)
goto lbl_90;
lbl_93:l_92 ^= 0 != &g_39;
  if (0)
{
}
  else
*l = 1;
}
}

[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS

[lianhao.lu at intel dot com]

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

lianhao.lu at intel dot com changed:

   What|Removed |Added

 CC||lianhao.lu at intel dot com

--- Comment #2 from lianhao.lu at intel dot com 2011-03-16 03:11:48 UTC ---
There is a patch for this in YoctoProject.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc/gcc-4.5.1/COLLECT_GCC_OPTIONS.patch?h=bernard&id=6bb3da22363ced7da04f2b0e70f18b0d9736ff13

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  2011-03-16 
03:01:11 UTC ---
Another small piece just before the error message.

$ valgrind --leak-check=full f951 pr47546.f90 
==3316== Memcheck, a memory error detector
==3316== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3316== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3316== Command: f951 pr47546.f90
==3316== 
 init __copy_hydro_state_State_t speeds_cellpr47546.f90:32.18:

  use hydro_speeds
  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

What the heck is that?

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #22 from Jerry DeLisle  2011-03-16 
02:58:59 UTC ---
Another valgrind chunk:

==3316== 318 bytes in 2 blocks are definitely lost in loss record 357 of 443
==3316==at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==by 0xD49748: xcalloc (xmalloc.c:162)
==3316==by 0x656E34: init_emit (emit-rtl.c:5544)
==3316==by 0x6EA958: prepare_function_start (function.c:4433)
==3316==by 0x6F09F8: init_function_start (function.c:4487)
==3316==by 0x54859E: trans_function_start.clone.0 (trans-decl.c:2103)
==3316==by 0x552C60: gfc_generate_function_code (trans-decl.c:4728)
==3316==by 0x534CA1: gfc_generate_module_code (trans.c:1511)
==3316==by 0x4F6344: gfc_parse_file (parse.c:4379)
==3316==by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)
==3316==by 0x845EC6: toplev_main (toplev.c:579)
==3316==by 0x3F03A1EE5C: (below main) (libc-start.c:226)
==3316==

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  2011-03-16 
02:57:02 UTC ---
partial valgrind:

==3316== 5,104 bytes in 2 blocks are definitely lost in loss record 433 of 443
==3316==at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==by 0xD49748: xcalloc (xmalloc.c:162)
==3316==by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==by 0x504110: resolve_structure_cons (resolve.c:967)
==3316==by 0x50D581: resolve_values (resolve.c:9313)
==3316==by 0x51EFF6: traverse_ns (symbol.c:)
==3316==by 0x51EFE5: traverse_ns (symbol.c:3330)
==3316==by 0x50C8EE: resolve_types (resolve.c:13530)
==3316== 
==3316== 8,600 (5,104 direct, 3,496 indirect) bytes in 2 blocks are definitely
lost in loss record 435 of 443
==3316==at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==by 0xD49748: xcalloc (xmalloc.c:162)
==3316==by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==by 0x51EFF6: traverse_ns (symbol.c:)
==3316==by 0x50C7A3: resolve_types (resolve.c:13513)
==3316==by 0x501363: gfc_resolve (resolve.c:13612)
==3316==by 0x4F5E77: gfc_parse_file (parse.c:4368)
==3316==by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)

[Bug fortran/48145] New: Generic interfaces & derived types cannot share names

[townsend at astro dot wisc.edu]

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

   Summary: Generic interfaces & derived types cannot share names
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Created attachment 23677
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23677
Test case demonstrating issue

There seems to be a problem when a generic interface and a derived type share
the same name. Compiling the attached code with 4.6.0 (20110312) on OS X
10.6.6, I get the following error:

test_name_conflict.f90:7.18:

  interface mytype
  1
Error: DERIVED attribute of 'mytype' conflicts with PROCEDURE attribute at (1)
test_name_conflict.f90:8.22:

 module procedure new_mytype
  1
Error: MODULE PROCEDURE at (1) must be in a generic module interface
test_name_conflict.f90:9.5:

  end interface
 1
Error: Expecting END MODULE statement at (1)

This conflict is bogus, since the F2003 standard allows derived types to share
names with generic interfaces (see, e.g., Appendix C.1.6 of the standard).

[Bug rtl-optimization/48144] New: ICE: in code_motion_path_driver, at sel-sched.c:6575 with -fselective-scheduling2 and custom flags

[zsojka at seznam dot cz]

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

   Summary: ICE: in code_motion_path_driver, at sel-sched.c:6575
with -fselective-scheduling2 and custom flags
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23676
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23676
auto-reduced testcase (from gfortran.dg/intrinsic_ifunction_1.f90)

I am sorry for the insane flags needed to reproduce, but I hope this uncovers
some possibly hidden problem.

Compiler output:
$ gfortran -O -fira-region=one -fno-dce -fno-guess-branch-probability
-fno-ivopts -frerun-cse-after-loop -fschedule-insns2 -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fselective-scheduling2 -fno-tree-copyrename
-funroll-loops --param=max-cse-insns=50 --param=max-pipeline-region-blocks=30
testcase.f90 
testcase.f90: In function 'gf0026':
testcase.f90:6:0: internal compiler error: in code_motion_path_driver, at
sel-sched.c:6575
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #20 from Jerry DeLisle  2011-03-16 
02:48:41 UTC ---
I see the problem on x86-64 linux with current trunk.

Problem goes away if I reverse the order of the use statements:

From:

module hydro_fluxes
  use hydro_state
  use hydro_speeds
end module

To:

module hydro_fluxes
  use hydro_speeds
  use hydro_state
end module

This hints at some sort of namespace corruption, maybe related to hydro_speeds
uses hydro_state.

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #19 from Rich Townsend  2011-03-16 
02:29:35 UTC ---
(In reply to comment #18)
> (In reply to comment #8)
> > This is a *very* strange bug, to say the least. Here is a reduced test case:
> > 
> > 
> > module hydro_types
> >   implicit none
> > end module hydro_types
> > 
> > module hydro_state
> >   implicit none
> >   type :: state_t
> >  real:: U 
> >  integer :: n
> >   end type
> >   private
> >   public :: state_t
> > contains
> >   subroutine init
> > type(state_t) :: this
> >   end subroutine init
> > end module hydro_state
> > 
> > module hydro_speeds
> >   use hydro_state
> >   implicit none
> > contains
> >   subroutine speeds_cell (st, c_l, c_r)
> > class(state_t) :: st
> > real :: c_l(st%n)
> > real :: c_r(st%n)
> >   end subroutine speeds_cell
> > end module hydro_speeds
> > 
> > module hydro_fluxes
> >   use hydro_state
> >   use hydro_speeds
> > end module
> 
> Here's an interesting observation: if the definitions of c_l and c_r are
> changed to
> 
>  real :: c_l(:)
>  real :: c_r(:)
> 
> (i.e., assumed shape rather than explicit shape), then the problem goes away.
> 
> In the interests of full disclosure, I should add that this is how I intended
> to code the speeds_cell routine in the first place -- I have no real need of
> the explicit shapes, assumed shapes are just fine. So, this bug becomes much
> less of a showstopper for me.

Well, I spoke too soon -- I've just gone through a code refactorization, and
this same bug has cropped up again. This time, the 'workaround' above no longer
helps out.

Fundamentally, this is a problem that hasn't gone away; the reduced test case
fails in exactly the same way, even using a recent (4.6.0 20110312) build. Has
anyone been able to figure out what is going on?

[Bug rtl-optimization/48143] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[zsojka at seznam dot cz]

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

   Summary: ICE: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7114 with custom flags
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23675
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23675
reduced testcase

Compiler output:
$ gcc -ftree-vectorize -O2 -fno-dce -fno-ivopts -fsel-sched-pipelining
-fselective-scheduling2 -funroll-loops --param=max-cse-insns=50
--param=max-pending-list-length=50 testcase.c
testcase.c: In function ‘foo’:
testcase.c:13:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7114
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r171001 - crash
4.6 r170955 - crash
4.5 r170955 - OK

[Bug target/48142] New: miscompilation with -mpreferred-stack-boundary=5 -fstack-check=specific

[zsojka at seznam dot cz]

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

   Summary: miscompilation with -mpreferred-stack-boundary=5
-fstack-check=specific
   Product: gcc
   Version: 4.7.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 23674
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23674
reduced testcase

Output:
$ g++ -Os -mpreferred-stack-boundary=5 -fstack-check=specific
-fno-omit-frame-pointer testcase.C
$ valgrind -q ./a.out 
==16640== Invalid read of size 8
==16640==at 0x4007D0: main (testcase.C:6)
==16640==  Address 0xfff8 is not stack'd, malloc'd or (recently)
free'd

(gdb) i r rsp
rsp0xfff8   0xfff8
(gdb) disassemble
   0x004007c6 <+82>:pop%rcx
   0x004007c7 <+83>:pop%r10
   0x004007c9 <+85>:xor%eax,%eax
   0x004007cb <+87>:pop%rbp
   0x004007cc <+88>:lea-0x8(%r10),%rsp
=> 0x004007d0 <+92>:retq   
End of assembler dump.

Tested revisions:
r171001 - fail
4.6 r170955 - fail
4.5 r170955 - OK

[Bug middle-end/29160] missed optimization: redundant casts prevent vectorization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #2 from Andrew Pinski  2011-03-16 
00:39:12 UTC ---
Fixed in 4.6.0.

[Bug libstdc++/48123] bits/cpu_defines.h not installed in freestanding mode.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #3 from Paolo Carlini  2011-03-16 
00:27:45 UTC ---
Fixed for 4.6.0.

[Bug libstdc++/48123] bits/cpu_defines.h not installed in freestanding mode.

[dougkwan at gcc dot gnu.org]

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

--- Comment #2 from dougkwan at gcc dot gnu.org 2011-03-15 23:39:07 UTC ---
Author: dougkwan
Date: Tue Mar 15 23:39:02 2011
New Revision: 171020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171020
Log:
2011-03-15  Doug Kwan  

PR libstdc++/48123
* include/Makefile.am (install-freestanding-headers): Install
cpu_defines.h
* include/Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/Makefile.am
branches/gcc-4_6-branch/libstdc++-v3/include/Makefile.in

Re: MIPS: va_arg is unable to correct extract an empty zero-length array

[Richard Sandiford]

Nick Clifton  writes:
> Hi Eric, Hi Richard,
>
>   A customer has reported the following bug with the MIPS target.  Since
>   it is for a GNU extension to the C language (zero-length arrays) that
>   is being used in a non-intended fashion (the zero-length array is in a
>   structure with no other fields) I doubt if you will want to
>   investigate the problem too much, but I thought that it was worth
>   reporting anyway:
>
> % mips64vr-elf-gcc -mgp32 -O2 -Tddb.ld -march=vr5500 bug.c
> % mips64vr-elf-run a.out
> assertion "arg4 == va4" failed: file "bug.c", line 40, function: foo
>
>   As an aside if the type3 structure in bug.c is given another,
>   non-zero-length field, then the test passes.

Interesting test case :-)  Certainly looks like a genuine bug though.
I see the same thing happens for varargs that are passed on the stack
as well (not just those passed in registers).

Fortunately, it looks like the bug is on the varargs side, so no ABI
change is needed.  Does the attached patch work?  I'll try to do a
full test this weekend.

Richard


Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  (revision 170697)
+++ gcc/config/mips/mips.c  (working copy)
@@ -5625,6 +5625,10 @@
 NULL_TREE);
   size = int_size_in_bytes (type);
 
+  /* Even zero-sized arguments occupy one byte.  */
+  if (size == 0)
+   size = 1;
+
   if (GET_MODE_CLASS (TYPE_MODE (type)) == MODE_FLOAT
  && GET_MODE_SIZE (TYPE_MODE (type)) <= UNITS_PER_FPVALUE)
{

[Bug libstdc++/48123] bits/cpu_defines.h not installed in freestanding mode.

[dougkwan at gcc dot gnu.org]

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

--- Comment #1 from dougkwan at gcc dot gnu.org 2011-03-15 20:57:00 UTC ---
Author: dougkwan
Date: Tue Mar 15 20:56:52 2011
New Revision: 171019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171019
Log:
2011-03-15  Doug Kwan  

PR libstdc++/48123
* include/Makefile.am (install-freestanding-headers): Install
cpu_defines.h
* include/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in

[Bug c/48140] fmod() not accurate to double precision?

[sdedeo at post dot harvard.edu]

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

--- Comment #2 from Simon DeDeo  2011-03-15 
20:48:28 UTC ---
Created attachment 23672
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23672
.i file (Different system, gcc 4.1.2 (Gentoo 4.1.2 p1.1))

[Bug c/48140] fmod() not accurate to double precision?

[sdedeo at post dot harvard.edu]

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

--- Comment #1 from Simon DeDeo  2011-03-15 
20:46:55 UTC ---
Created attachment 23671
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23671
.i file (Intel Core i7, gcc 4.5.2)

[Bug rtl-optimization/48141] New: [4.4/4.5/4.6/4.7 Regression] DSE compile time hog

[jakub at gcc dot gnu.org]

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

   Summary: [4.4/4.5/4.6/4.7 Regression] DSE compile time hog
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


#define A i = 0;
#define B A A A A A A A A A A
#define C B B B B B B B B B B
#define D C C C C C C C C C C
#define E D D D D D D D D D D

int
foo (void)
{
  volatile int i = 0;
  E E E E E E E E E E E
  return 0;
}

compiles at -O in under 4 seconds in 4.3, but in 4.4+ takes almost 8 minutes,
99% of the time spent in RTL DSE, and as it is quadratic, trying 10 times as
many stores makes things much worse.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

--- Comment #41 from Janne Blomqvist  2011-03-15 
20:38:18 UTC ---
(In reply to comment #37)
> #if defined(__alpha__) && defined(__osf__)
> #undef HAVE_CLOCK_GETTIME
> #endif
> 
> or some configure.ac equivalent.  Ugly but still better than completely
> breaking Fortran.

Thinking about this some more, while the above is ugly it should at least be
safe. Please consider it approved from my part for 4.6; if you get approval
from the release manager, please commit it.

I'll regtest and submit my patch to review for trunk, and backport to the 4.6
branch after it has been in trunk for a while; I suspect this won't make the
4.6 release and will thus have to wait for 4.6.1. Hence your patch is a usable
compromise for 4.6.0.

[Bug c/48140] New: fmod() not accurate to double precision?

[sdedeo at post dot harvard.edu]

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

   Summary: fmod() not accurate to double precision?
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sde...@post.harvard.edu


Created attachment 23670
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23670
c code to produce the output above

I am not sure if this is a "good" bug to submit to gcc, since it involves the
math library. I have found it occurs on my own machine (Intel Core i7) with
gcc4.5 and gcc4.6, as well as on other machines I have access to that use gcc. 

Again, I apologize if this is either not a real error, or if it is related to
other floating point errors that people report. I have tried to look through
the database. The error below appears even without optimization flags.

In any case, I am finding that fmod, given a double precision set of inputs,
produces answers that are only good to (approximately) single precision. In
other words, the output of fmod is a double, but the answer is not accurate. It
seems to show up for large values of x in fmod(x,y).

Below I compare the outputs to Mathematica (which can handle arbitrary
precision.)

10^9 mod 2pi:  0.5773954624831035
Mathematica value: 0.5773954235013852
[this is accurate only to 10^-8]

sin(10^9 mod 2pi): 0.5458434821109812
sin(10^9): 0.5458434494486994
Mathematica value: 0.5458434494486996
[the sin function handles the large number gracefully to give standard 10^-16
precision]

#include 
#include 

#define TWOPI 6.2831853071795864769252867665590057683943387987502

int main() {
double big, twopi;

big=10.0;

printf("10^9 mod 2pi:  %#17.16g\n",  fmod(big, TWOPI));
printf("Mathematica value: 0.5773954235013852\n");
printf("\n");
printf("sin(10^9 mod 2pi): %#17.16g\nsin(10^9): %#17.16g\n",
sin(fmod(big, TWOPI)), sin(big));
printf("Mathematica value: 0.5458434494486996\n");
}

[Bug c/48139] New: __builtin_lrintf() becomes a library call, not an cvtss2si instruction

[sgunderson at bigfoot dot com]

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

   Summary: __builtin_lrintf() becomes a library call, not an
cvtss2si instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com


Hi,

It seems there is no way on x86-64 (short of an asm() statement) to get direct
access to the cvtss2si instruction, ie. convert a single float to an int in the
current rounding mode. Even __builtin_lrintf() becomes a library call to
glibc's lrintf(), which in itself only contains a single instruction and then a
ret. (If I set -fno-math-errno, I do get the instruction, but this is
unfortunately not an option for me.)

I've been told that this may or may not be correct behavior; it's a bit unclear
if lrintf() should set errno or not according to C99 and glibc's
math_errhandling setting. I guess this either is a missed optimization in GCC
_or_ a bug in glibc, though. It seems to me the former is more likely, though,
given that the entire point of lrint() and friends seems to be being able to do
quick float-to-int without having to deal with special code for NaN and the
likes.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #9 from Ramana Radhakrishnan  2011-03-15 
20:06:16 UTC ---
(In reply to comment #7)
> AFAICS, however, pr47688.c is still there.

I think I managed to delete it now even though I did do a svn rename.

Ramana

[Bug libstdc++/48130] [4.7 Regression]: build fails on libsupc++/nested_exception.cc

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Hans-Peter Nilsson  2011-03-15 
20:03:22 UTC ---
Yep, thanks!

[Bug tree-optimization/48129] [4.7 Regression]: gcc.c-torture/execute/builtins/snprintf-chk.c ICE

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Hans-Peter Nilsson  2011-03-15 
20:02:22 UTC ---
Fixed, so closing.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  2011-03-15 
19:59:29 UTC ---
Author: ramana
Date: Tue Mar 15 19:59:25 2011
New Revision: 171017

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

Fix PR target/46788


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171005,
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/47862] Incorrect code for spilling a vector register

[pthaugen at gcc dot gnu.org]

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

--- Comment #8 from Pat Haugen  2011-03-15 
19:43:44 UTC ---
Author: pthaugen
Date: Tue Mar 15 19:43:38 2011
New Revision: 171016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171016
Log:
PR target/47862
* caller-save.c (insert_restore, insert_save): Use non-validate
form of adjust_address.


Modified:
branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_5-branch/gcc/caller-save.c

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #7 from Paolo Carlini  2011-03-15 
19:07:44 UTC ---
By the way, it's not at all clear to me why those misplaced patterns actually
do the exporting work (of course at least I verified that, at the time).

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-03-15 
19:03:01 UTC ---
Uhhhm, you are right, doesn't make much sense, I don't know what i was
thinking. Luckily we are still in time to move those lines in gnu.ver. Let me
know if you want me to do it or you have the tweak part of other work.

[Bug libstdc++/48130] [4.7 Regression]: build fails on libsupc++/nested_exception.cc

[bkoz at gcc dot gnu.org]

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

--- Comment #5 from Benjamin Kosnik  2011-03-15 
19:01:57 UTC ---

HP if you can confirm this is now working, can you close this? thanks.

[Bug boehm-gc/47309] gcc-4.4.5 fails to build on darwin/ppc due to issues in boehm-gc GC_test_and_set

[elelay at macports dot org]

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

Eric Le Lay  changed:

   What|Removed |Added

 CC||elelay at macports dot org

--- Comment #2 from Eric Le Lay  2011-03-15 
18:58:00 UTC ---
(In reply to comment #1)
> How did you configure GCC?  It seems you are building without bootstrap
> and/or with custom CFLAGS (you lack any optimization).

Hi,
jumping in because I experience the same issue on Gentoo with a PPC32 ibook g4.

Here is my current gcc : 
Target: powerpc-unknown-linux-gnu
Configuré avec: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.4/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp --enable-checking=release
--disable-libgcj --enable-objc-gc
--enable-languages=c,c++,objc,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.1,
pie-10.1.5'
Modèle de thread: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) 


Here is the configure command line
:/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr
--bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.5/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/python
--enable-checking=release --disable-libgcj --enable-objc-gc
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.4.5 p1.2,
pie-0.4.5

I can attach the full log if it helps...

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[bkoz at gcc dot gnu.org]

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

--- Comment #5 from Benjamin Kosnik  2011-03-15 
18:43:21 UTC ---

Hey P, why was bad_function_call added in CXXABI instead of GLIBCXX? That
doesn't make sense to me.

-benjamin

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

   Keywords|alias, wrong-code   |
 Status|NEW |WAITING

--- Comment #9 from mrs at gcc dot gnu.org  2011-03-15 
18:36:33 UTC ---
So, I'm sort of skeptical of this problem.  Please engineer a test case that
shows bad code.  I think you'll find it is a rather bit harder than you expect.
 I think most dynamic things happen at the end of a function call, that you
can't see into (the Object-C run-time), and those things that happen before
that point, must happen before that point, and those things that happen after
that point, can't come before it.  Objective-C adds a ton of these type of
calls all over the place, which controls just how far the optimizer can move
anything.  Escape analysis should quickly realize that it doesn't own much of
anything, which further prevents almost anything from happening.  As for an
individual pointer, statically, the type should always be reasonable, though,
we do expect to up-cast and downcast pointers.  Some on the C side of things
might disagree, but, once the C people realize that up-casting and down-casting
are both valid, then even this is fine.  Once you combine all these factors,
there is no wiggle room left for the optimizer to do anything.  If you can find
any, test case please.  We can then address the specific concern.

Until then, we'll wait for a testcase.

As far as missing language definition bits, please describe a missing bit, be
specific.  I can't think of any off the top of my head.

[Bug c++/34758] [4.3/4.4/4.5/4.6/4.7 regression] Bad diagnostic for circular dependency in constructor default argument

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-03-15 
18:27:15 UTC ---
Author: jason
Date: Tue Mar 15 18:27:09 2011
New Revision: 171009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171009
Log:
PR c++/34758
* call.c (convert_default_arg): Use DECL_ORIGIN of fn.  Check for
recursion first.
(push_defarg_context, pop_defarg_context): New.
* parser.c (cp_parser_late_parsing_default_args): Use them.
* cp-tree.h: Declare them.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr34758.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c/47557] Effect of aligned attribute on arrays

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 CC||jyasskin at gcc dot gnu.org

--- Comment #3 from Jeffrey Yasskin  2011-03-15 
18:18:06 UTC ---
Alignments on typedefs behave very strangely (PR48138). What you want is:

typedef struct __attribute__((aligned(2))) {
char a[3];
} T;

unsigned x1 = sizeof(T);// sizeof is 4
unsigned x2 = sizeof(T[1]); // sizeof is 4
unsigned x3 = sizeof(T[2]); // sizeof is 8
unsigned x4 = sizeof(T[2][1]);  // sizeof is 8
unsigned x5 = sizeof(T[1][2]);  // sizeof is 8

Moving the attribute makes it apply to the struct instead of the typedef, which
fixes everything. C1x and C++0x don't allow alignments on typedefs either.

[Bug c++/48138] New: __attribute__((aligned)) should give an error when applied to a typedef or template parameter, at least in C++0x mode.

[jyasskin at gcc dot gnu.org]

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

   Summary: __attribute__((aligned)) should give an error when
applied to a typedef or template parameter, at least
in C++0x mode.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


In the C++0x draft, [dcl.align] says:

"An alignment-specifier may be applied to a variable or to a class
data member, but it shall not be applied to a bit-field, a function
parameter, the formal parameter of a catch clause (15.3), or a
variable declared with the register storage class specifier.  An
alignment-specifier may also be applied to the declaration of a class
or enumeration type."

This does not allow its use on a typedef or next to a typename template
parameter.  It might make sense for gcc to support that as an extension, but
gcc's current behavior is not what people expect that extension to do:

$ cat test.cc
#include 

#define ALIGNED(x) __attribute__((aligned(x)))

struct Char15 {
  char x[15];
}  ALIGNED(8);

template
void print_type_alignment(const T&) {
  struct { char c; T t; } s;
  std::cout << sizeof(T) << ' ' << ((char*)&s.t - (char*)&s.c) << '\n';
}

int main() {
  typedef char unaligned[15];
  typedef char aligned[15] ALIGNED(8);
  unaligned x[10];
  aligned y[10];
  Char15 c15[10];
  std::cout << sizeof(unaligned) << ' ' << sizeof(x) << '\n';
  std::cout << sizeof(aligned) << ' ' << sizeof(y) << '\n';
  std::cout << sizeof(Char15) << ' ' << sizeof(c15) << '\n';

  aligned z ALIGNED(8);
  print_type_alignment(z);
}

$ g++-mp-4.6 -std=gnu++0x test.cc && ./a.out
15 150
15 152
16 160
15 1


Note that the alignment on the typedef applies to the final variable, not the
defined type, which means that interior members of arrays of the defined type
have an unexpected alignment. This has been reported several times before
(PR43798, PR47557, PR12742, PR42098), but the core problem seems to be that
alignments on typedefs aren't supported.

__attribute__((aligned)) on template arguments seems to have no effect at all.





$ g++-mp-4.6 -v
Using built-in specs.
COLLECT_GCC=g++-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110305/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.6.0 20110305 (experimental) (GCC)

[Bug target/48127] Program crashes reading a non-aligned variable

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev  
2011-03-15 18:00:23 UTC ---
I do not agree that the testcase is invalid. As the standart says:

  Common extensions

  Multiple external definitions

 There may be more than one external definition for the identifier of
  an object, with or without the explicit use of the keyword extern; if
  the definitions disagree, or more than one is initialized, the behavior
  is undefined.

According to the Binutils documentation,

  The linker turns a common symbol into a declaration, if there is a
  definition of the same variable.

Also, from Ian Lance Taylor's article [1]:

  5. If A is a strong definition in an object file:

* If B is a common symbol, then we treat B as an undefined reference.

I think it would be better to fix this problem in the linker. Gold does not
even warn about it!

However, I don't understand why GCC makes baz[8] to have 32 bytes alignment,
while baz[4] has only 4 bytes alignment. It seems to be a GCC bug.

When baz is declared extern in main.c, the generated code is correct, but less
optimal.


1. http://www.airs.com/blog/archives/49

MIPS: va_arg is unable to correct extract an empty zero-length array

[Nick Clifton]

Hi Eric, Hi Richard,

  A customer has reported the following bug with the MIPS target.  Since
  it is for a GNU extension to the C language (zero-length arrays) that
  is being used in a non-intended fashion (the zero-length array is in a
  structure with no other fields) I doubt if you will want to
  investigate the problem too much, but I thought that it was worth
  reporting anyway:

% mips64vr-elf-gcc -mgp32 -O2 -Tddb.ld -march=vr5500 bug.c
% mips64vr-elf-run a.out
assertion "arg4 == va4" failed: file "bug.c", line 40, function: foo

  As an aside if the type3 structure in bug.c is given another,
  non-zero-length field, then the test passes.

Cheers
  Nick

#include 
#include 
#include 

typedef int * type1;

typedef struct 
{
  union u1 { double f1; long int f2; } f3[0];
} type3;

typedef int type4;

static type1 arg1 = 0;
static double arg2 = 1.0;
static type3 arg3 = {{}};
static type4 arg4 = 0x12345678;

void
foo (double parm,
 ...)
{
  va_list  ap;
  type1va1;
  double   va2;
  type3va3;
  type4va4;

  va_start (ap, parm);

  va1 = va_arg (ap, type1);
  assert (arg1 == va1);

  va2 = va_arg (ap, double);
  assert (arg2 == va2);

  va3 = va_arg (ap, type3);

  va4 = va_arg (ap, type4);
  assert (arg4 == va4);

  va_end (ap);
}

int
main (void)
{
  foo (1.0, arg1, arg2, arg3, arg4);
  return 0;
}

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

--- Comment #40 from Janne Blomqvist  2011-03-15 
17:19:43 UTC ---
(In reply to comment #37)
> >> I'd really like to see this fixed before 4.6.0: it is a regression from
> >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
> >> minor gain on other platforms.
> >
> > Well, do we really have any actual gfortran users on Tru64? Whereas a
> > high-resolution monotonic clock, while admittedly not a huge feature per 
> > se, is
> > something that is now available to gfortran users on some rather more 
> > popular
> > platforms.
> 
> Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all
> is fine.'?   You will only learn if things break.

While I have no proof, I find it difficult to imagine that we have a
significant amount of bleeding edge users that upgrade to the latest and
greatest gcc release on an expensive platform where new hw isn't sold since
many years, and the OS is scheduled to go EOL in a year or so. So while IMHO it
would be nice if we could get a fix into 4.6, I don't think it's the end of the
world if these users, if they exist at all, will have to wait until 4.6.1.

> >>  If all else fails, I'd go as far as
> >> advocating to revert the patch that introduced clock_gettime
> >
> > There has been a number of patches in this area more or less related to
> > clock_gettime, so IMHO fixing it properly is simpler and less prone to
> > introduce new regressions. My previous message in this PR hopefully does
> > exactly this and introduces a patch which should fix it along the lines
> > previously discussed. As my normal gcc development machine is packed in a 
> > box,
> > I haven't been able to test it. Also, note that it won't apply cleanly as 
> > the
> > paths are messed up (but the contents should otherwise apply fine). 
> 
> There have been some subsequent suggestions/updates, so I'm uncertain if
> I should test this patch or wait for an update.

The suggestion are only for the potential corner case where CLOCK_* are not
preprocessor macros but e.g. enums. In any case, this is fixed in the updated
patch I just posted, so feel free to try that one.

> Now that 4.6 has branched, it's safer to commit to mainline after some
> testing and only backport to 4.6 after it has proven correct.

I agree.

>  If all
> else fails, one could apply a hack to 4.6 along the lines of
> 
> #if defined(__alpha__) && defined(__osf__)
> #undef HAVE_CLOCK_GETTIME
> #endif
> 
> or some configure.ac equivalent.  Ugly but still better than completely
> breaking Fortran.

Yes, that's a possibility. OTOH I think my patch should be fairly simple and
safe, but ultimately that's up to the reviewer(s) to decide.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-03-15 
17:16:11 UTC ---
AFAICS, however, pr47688.c is still there.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  2011-03-15 
17:08:03 UTC ---
Looks fine to me.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  2011-03-15 
17:07:56 UTC ---

(In reply to comment #5)
> Author: ramana
> Date: Tue Mar 15 17:05:51 2011
> New Revision: 171002
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171002
> Log:
> 
> Fixup last commit.
> 
> Fixed PR target/46788 and not PR 47688
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.target/arm/pr46788.c
>   - copied unchanged from r171001,
> trunk/gcc/testsuite/gcc.target/arm/pr47688.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog


This was fixed on trunk with this original commit followed by the commit in the
previous comment.


Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-03-15 
17:07:04 UTC ---
(In reply to comment #4)
> Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and
> --disable-symvers is the next thing i'm going to try.
> 
> Still not convinced that i am "modifying GCC".

You're not, but I think the prerequisites docs are misleading.  The Perl
requirement shouldn't be in the "modifying GCC" section. Perl is required when
doing any of:

* regenerating Makefile dependencies in libiberty.
* regenerating libiberty/functions.texi. 
* generating manpages from Texinfo manuals.
* targetting Darwin, building `libstdc++', and not using --disable-symvers
* targetting Solaris 2 with Sun ld, building `libstdc++', and not using
--disable-symvers.

Only the first two belong under the "modifying GCC" heading.

You are targetting Solaris2 with Sun ld, building libstdc++ and not using
--disable-symvers, so Perl (and Glob.pm) is required.

[Bug c++/47688] [C++0x] Segfault when assigning lambda to std::function variable

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  2011-03-15 
17:05:56 UTC ---
Author: ramana
Date: Tue Mar 15 17:05:51 2011
New Revision: 171002

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

Fixup last commit.

Fixed PR target/46788 and not PR 47688


Added:
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171001,
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  2011-03-15 
17:05:56 UTC ---
Author: ramana
Date: Tue Mar 15 17:05:51 2011
New Revision: 171002

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

Fixup last commit.

Fixed PR target/46788 and not PR 47688


Added:
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171001,
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #23 from joe at mcknight dot de 2011-03-15 17:05:24 UTC ---
(In reply to comment #22)
> > Compare it to:
> > 
> > typedef int mytype;
> > int myfunc2(mytype var) {
> > return 1;
> > };
> > 
> > which outputs
> > 
> >   static int myfunc2 (mytype);
> > 
> > i.e. returns the newly created type as well.
> 
> That's by design.

Then what is the design rule behind it, for me it looks inconsistent to once
inline the original type and another time use the newly created type.


> > It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"
> 
> It's not designed to do that.  The functions are for debugging and
> diagnostic output only, they are not supposed to generate valid C.

I know, but instead of creating a new language, wouldn't it be good to just
stick to the C grammar to describe what is being seen?



Was the debug output helpful with respect to the wrong variadic output?

thanks!

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

  Attachment #23648|0   |1
is obsolete||

--- Comment #38 from Janne Blomqvist  2011-03-15 
17:04:41 UTC ---
Created attachment 23669
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23669
Updated patch

This patch takes into account the comments by Jakub, and unconditionally sets
GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if
CLOCK_* are not preprocessor macros.

Also, paths should be correct now, if the patch is applied in libgfortran/

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Zdenek Sojka  2011-03-15 16:49:13 
UTC ---
Thank you for quick replies.

Now it seems I was also wrong with that "write to volatile int * is removed"
statement - I can't reproduce it any more... Sorry for the noise.

[Bug middle-end/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
16:46:02 UTC ---
Created attachment 23668
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23668
gcc47-pr48136.patch

Patch I'm going to bootstrap/regtest.

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

Denis Excoffier  changed:

   What|Removed |Added

 CC||Denis.Excoffier at airbus
   ||dot com

--- Comment #4 from Denis Excoffier  
2011-03-15 16:40:13 UTC ---
Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and
--disable-symvers is the next thing i'm going to try.

Still not convinced that i am "modifying GCC".

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-15 
16:36:34 UTC ---
Yes, well ... if it "works" you are lucky.  "Works" in this case can even
mean we simply don't turn the indirect call into a direct one (in which
case we'll not notice the fn is always-inline and do not complain).

I suggested to emit a diagnostic whenever the address of an always-inline
function is taken, but kernel people will take that not lightly I guess ;)

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  
2011-03-15 16:33:09 UTC ---
On Tue, 15 Mar 2011, joe at mcknight dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
> 
> --- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC ---
> (In reply to comment #19)
> > All looks good to me with your C testcase:
> > 
> > (gdb) call debug_generic_expr (fndecl->common.type)
> > int  (struct 
> > {
> >   double dvar;
> >   int ivar;
> > } *)
> 
> Hm, the function was declared to take a new type "tpdefp", so I was expecting
> the dump to return it like this and not resolve it to whatever it is 
> typedef'ed
> to.
> 
> Compare it to:
> 
> typedef int mytype;
> int myfunc2(mytype var) {
> return 1;
> };
> 
> which outputs
> 
>   static int myfunc2 (mytype);
> 
> i.e. returns the newly created type as well.

That's by design.

> > (gdb) call debug_generic_expr (fndecl->common.type)
> > void (*Handler) (int, void *)  (void)
> 
> It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"
> 
> And this is not C  :-)
> 
> The compiler throws a parse error when I compile a function with the prototype
> that it outputs.

It's not designed to do that.  The functions are for debugging and
diagnostic output only, they are not supposed to generate valid C.

Richard.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2011-03-15 16:32:37 
UTC ---
Oh, sorry. It was reduced from gcc.c-torture/compile/pr44043.c:

...
static inline __attribute__((always_inline)) int dst_output(struct sk_buff
*skb) {
return skb_dst(skb)->output(skb);
};
...
  NF_HOOK(2, NF_INET_LOCAL_OUT, skb, ((void *)0), rt->u.dst.dev,
   dst_output);
...

dst_output is always_inline there, but is used in this way.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-03-15 
16:29:33 UTC ---
indirect calls can't be always-inline, the testcase is invalid.

[Bug debug/47510] DW_TAG_typedef can have children when designating a naming typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-03-15 
16:24:27 UTC ---
(In reply to comment #4)
> This is because G++ generates struct F::C.  The instantiated
> F::C a typedef.  No anonymous struct is generated inside F.
> What is generated is really the same as for:
> 
> template
> class F
> {
>   struct C {int i};
>   C a;
> };
> F f;
> 
> I guess we could try hard to trick the dwarf emitter into describing
> debug information for a typedef and an anonymous code that is actually
> not generated (instantiated), but would that be really worth it?

See also PR47939.  Yes, debug info consumers expect typedefs to be available
if they are used in source.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-15 16:24:01 UTC ---
>> I'd really like to see this fixed before 4.6.0: it is a regression from
>> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
>> minor gain on other platforms.
>
> Well, do we really have any actual gfortran users on Tru64? Whereas a
> high-resolution monotonic clock, while admittedly not a huge feature per se, 
> is
> something that is now available to gfortran users on some rather more popular
> platforms.

Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all
is fine.'?   You will only learn if things break.

>>  If all else fails, I'd go as far as
>> advocating to revert the patch that introduced clock_gettime
>
> There has been a number of patches in this area more or less related to
> clock_gettime, so IMHO fixing it properly is simpler and less prone to
> introduce new regressions. My previous message in this PR hopefully does
> exactly this and introduces a patch which should fix it along the lines
> previously discussed. As my normal gcc development machine is packed in a box,
> I haven't been able to test it. Also, note that it won't apply cleanly as the
> paths are messed up (but the contents should otherwise apply fine). 

There have been some subsequent suggestions/updates, so I'm uncertain if
I should test this patch or wait for an update.

> As I mentioned previously, I'd prefer to commit it after the 4.6 release, but
> if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6.

Now that 4.6 has branched, it's safer to commit to mainline after some
testing and only backport to 4.6 after it has proven correct.  If all
else fails, one could apply a hack to 4.6 along the lines of

#if defined(__alpha__) && defined(__osf__)
#undef HAVE_CLOCK_GETTIME
#endif

or some configure.ac equivalent.  Ugly but still better than completely
breaking Fortran.

Rainer

[Bug tree-optimization/48137] New: [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

   Summary: [4.6/4.7 Regression] "sorry, unimplemented: inlining
failed in call to 'cb'" with -fnon-call-exceptions
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23667
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23667
reduced testcase

Compiler output:
$ gcc -O -fipa-cp -fnon-call-exceptions testcase.c   
testcase.c: In function 'f1':
testcase.c:3:52: sorry, unimplemented: inlining failed in call to 'cb': 
testcase.c:10:6: sorry, unimplemented: called from here

Compilation succeeds when either:
a) __attribute__ ((always_inline)) is removed from cb()
b) -fnon-call-exceptions is removed
c) -fipa-cp is removed
d) *p (dereferencing null pointer) is removed

(e) -O is removed)

In all a,b,c,d cases, the generated code is:
f1:
.LFB3:
.cfi_startproc
addl$1, x(%rip)
ret
.cfi_endproc

so the (possibly causing exception?) *p is removed. (even when it is declared
as "volatile int *")

This seems to be a recent regression, as r170436 seems to work fine (generated
code is the same as above). Also, r170436 (and 4.5.2) generates write to *p if
it is "volatile int *".

I don't know what's the expected behaviour, but removing write to null pointer
looks strange.

Tested revisions:
r170964 - fail
r170436 - OK
4.5.2 - OK

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC ---
(In reply to comment #19)
> All looks good to me with your C testcase:
> 
> (gdb) call debug_generic_expr (fndecl->common.type)
> int  (struct 
> {
>   double dvar;
>   int ivar;
> } *)

Hm, the function was declared to take a new type "tpdefp", so I was expecting
the dump to return it like this and not resolve it to whatever it is typedef'ed
to.

Compare it to:

typedef int mytype;
int myfunc2(mytype var) {
return 1;
};

which outputs

  static int myfunc2 (mytype);

i.e. returns the newly created type as well.


> (gdb) call debug_generic_expr (fndecl->common.type)
> void (*Handler) (int, void *)  (void)

It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"

And this is not C  :-)

The compiler throws a parse error when I compile a function with the prototype
that it outputs.

[Bug libstdc++/47668] missing 'typename' in debug-mode map

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  2011-03-15 
16:14:29 UTC ---
Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/47688] [C++0x] Segfault when assigning lambda to std::function variable

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  2011-03-15 
16:14:29 UTC ---
Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #20 from joe at mcknight dot de 2011-03-15 16:03:23 UTC ---
Unfortunately I cannot confirm that this bug is fixed, so I need to reopen it.

For one thing this bug is not only about variadic functions, but
dump_function_declaration() returns wrong output also for other cases as
described, like functions involving function pointers and typedef'ed structs.

Second I am still seeing the issue described earlier, where a function now
returns a variadic function even though there is none.

I have modified the function to print debug output to a file and I am attaching
both the modified function and its debug output. For me it looks like the "arg
!= void_list_node" does not work, so the while loop is executed once more,
printing the "void" and then arg goes NULL, the loop is left and since arg is
NULL, the function prints ", ..." at the end.

Let me know if there is anything else I can do to help.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2011-03-15 
15:59:44 UTC ---
All looks good to me with your C testcase:

gcc> gdb --args ./cc1 -quiet t.i
(gdb) b gimplify_function_tree
Breakpoint 5 at 0x855ac4: file /space/rguenther/src/svn/trunk/gcc/gimplify.c,
line 7820.
(gdb) run
Breakpoint 5, gimplify_function_tree (fndecl=0x75b49000)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820
7820  gcc_assert (!gimple_body (fndecl));
(gdb) call debug_generic_expr (fndecl->common.type)
int  (struct 
{
  double dvar;
  int ivar;
} *)
(gdb) call debug_generic_expr (fndecl)
myfunc
(gdb) c
Continuing.

Breakpoint 5, gimplify_function_tree (fndecl=0x75b29f00)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820
7820  gcc_assert (!gimple_body (fndecl));
(gdb) call debug_generic_expr (fndecl)
GetFunctionPointer
(gdb) call debug_generic_expr (fndecl->common.type)
void (*Handler) (int, void *)  (void)
(gdb) c
Continuing.

Breakpoint 3, 0x763ca250 in exit () from /lib64/libc.so.6

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-03-15 
15:56:04 UTC ---
comment #13 would happen if the list of argument types is not terminated by
the shared tree node void_list_node but by a clone.  We expect the
shared void_list_node to be used elsewhere as well.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #17 from joe at mcknight dot de 2011-03-15 15:53:23 UTC ---
Created attachment 23666
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23666
debug output from a run of the modified function

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #16 from joe at mcknight dot de 2011-03-15 15:52:01 UTC ---
Created attachment 23665
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23665
dump_function_declaration with debug

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[fxcoudert at gcc dot gnu.org]

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

--- Comment #8 from Francois-Xavier Coudert  
2011-03-15 15:36:16 UTC ---
(In reply to comment #7)
> - Yes, Fortran itself does not have unsigned integers, but the string length
> type is invisible to Fortran programs. The LEN intrinsic does return the 
> string
> length typecast to a signed integer kind depending on the optional KIND
> argument, or to a default kind integer.

My point is just that, if you're merely changing the size of the variable, you
are less likely to unearth new bugs than if you change both that and
signedness.

Plus, as you say, the difference between SIZE_MAX and SSIZE_MAX is a corner
case, and maybe a huge size_t value isn't usable in common code.

Finally, you'd loose some compatibility with what used to be done

> Also, consider that at the asm level, typecasting from an unsigned to a
> signed value of the same size is a no-op, so there is no efficiency loss.

And casts from signed to unsigned, with checks for positivity, when string
lengths are passed as function arguments.

[Bug c/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Jakub Jelinek  2011-03-15 
15:26:55 UTC ---
Folder, what else, likely triggered by my PR38878 fix.

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist  2011-03-15 15:26:05 
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > If not before, perhaps something to fix when/if we change to use size_t for
> > string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
> 
> Just as a remark: you're not going to use size_t, but the signed ssize_t,
> right?

I think the idea was to use the unsigned size_t. 

- size_t is the natural type for representing the size of a memory object in
bytes. There is no need for negative values, and SSIZE_MAX is smaller than the
largest possible object (=SIZE_MAX) (an obscure corner case, but still).

- size_t is what the C string.h functions use, which is used in the
implementation of various string handling functions in gfortran (in libgfortran
and code generated directly by the frontend). Using the same type might also
help mixed C/Fortran programs.

- size_t is what Intel Fortran uses

- Yes, Fortran itself does not have unsigned integers, but the string length
type is invisible to Fortran programs. The LEN intrinsic does return the string
length typecast to a signed integer kind depending on the optional KIND
argument, or to a default kind integer. Depending on whether the target
supports an integer kind > sizeof(size_t) it might be possible to represent all
possible string lengths, or then not. But IMHO this does not change the fact
that the correct type for the (Fortran invisible) string length is the unsigned
size_t. Also, consider that at the asm level, typecasting from an unsigned to a
signed value of the same size is a no-op, so there is no efficiency loss.

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-03-15 
15:19:34 UTC ---
But are you using Sun ld, building libstdc++, and not using --disable-symvers?

[Bug c/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 15:13:11
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-03-15 
15:13:11 UTC ---
Simplified testcase:

extern int foo (void);

int
baz (int x)
{
  return ((5U ^ x) == (foo () ^ 1)) > foo ();
}

Looking at it.

[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 15:13:27
 CC||janus at gcc dot gnu.org
Summary|generic interface to|[4.6/4.7 Regression]
   |external function in module |generic interface to
   ||external function in module
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2011-03-15 15:13:27 UTC ---
Confirmed. Seems to be a regression in 4.6.

At first glance your code looks completely innocent. I think the bug may be
somehow related to the interface and the result variable having the same name.
Removing (or renaming) the result variable makes the error go away.

In any case the problem seems to occur during module writing. Backtrace:

#0  0x004c9fc8 in error_string (p=0xfbadac84 ) at /home/jweil/gcc47/trunk/gcc/fortran/error.c:132
#1  0x004cafd7 in error_print (type=0x11d5508 "", format0=0x11e3a88
"write_symbol(): bad module symbol '%s'", argp=0x7fffd980)
at /home/jweil/gcc47/trunk/gcc/fortran/error.c:671
#2  0x004cbc56 in gfc_internal_error (format=0x11e3a88 "write_symbol():
bad module symbol '%s'") at /home/jweil/gcc47/trunk/gcc/fortran/error.c:977
#3  0x00510351 in write_symbol (n=6, sym=0x1973dd0) at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:4848
#4  0x00510572 in write_symbol1 (p=0x1974f60) at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:4933
#5  0x005109b2 in write_module () at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:5081
#6  0x00510e23 in gfc_dump_module (name=0x77f651f0 "module_m",
dump_flag=1) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:5224
#7  0x0051eb09 in gfc_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/parse.c:4377
#8  0x005641c4 in gfc_be_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/f95-lang.c:250
#9  0x00a56410 in compile_file () at
/home/jweil/gcc47/trunk/gcc/toplev.c:579
#10 0x00a5862b in do_compile () at
/home/jweil/gcc47/trunk/gcc/toplev.c:1900
#11 0x00a58778 in toplev_main (argc=2, argv=0x7fffddd8) at
/home/jweil/gcc47/trunk/gcc/toplev.c:1963
#12 0x005fe2b4 in main (argc=2, argv=0x7fffddd8) at
/home/jweil/gcc47/trunk/gcc/main.c:36

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

--- Comment #2 from Denis Excoffier  
2011-03-15 15:09:37 UTC ---
Oh, thank you for pointing, but i should not be concerned since i
didn't modify the sources (i simply include gmp/mpfr/mpc within
the source directory tree).

Perhaps this is a side-effect because two files have the same mtime
(that will disappear with the final gcc-4.6.0)?

[Bug c/48136] New: verify_gimple failed at -O0

[regehr at cs dot utah.edu]

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

   Summary: verify_gimple failed at -O0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu


regehr@home:~/volatile/bugs/tmp003$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/mnt/z/z/compiler-install/gcc-r170969-install/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/mnt/z/z/compiler-install/gcc-r170969-install
--program-prefix=r170969- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110314 (experimental) (GCC) 

regehr@home:~/volatile/bugs/tmp003$ current-gcc -O0 small.c

small.c: In function ‘func_16’:
small.c:12:15: error: type mismatch in comparison expression
int
unsigned int
int
D.1965 = D.1963 == D.1964;

small.c:12:15: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

regehr@home:~/volatile/bugs/tmp003$ cat small.c


static short foo(short si1, short si2 ) {
  return si1 + si2;
}

static int bar(int si1, short si2 ) {
  return si1 + si2;
}

short g_2[1][9] = {
};

unsigned char func_16(unsigned p_17, const int p_18) 
{
 lbl_51:  
  {
  lbl_350:  
{
  ((5U ^ p_18) == (bar(0, 1) ^ 1)) > foo(1, 0)  ;
}
  }
  return 0;
}

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2011-03-15 
14:55:16 UTC ---
As documented in install.texi.

@item Perl version 5.6.1 (or later)

Necessary when regenerating @file{Makefile} dependencies in libiberty.
Necessary when regenerating @file{libiberty/functions.texi}.
Necessary when generating manpages from Texinfo manuals.
Necessary when targetting Darwin, building @samp{libstdc++},
and not using @option{--disable-symvers}.
Necessary when targetting Solaris 2 with Sun @command{ld}, building
@samp{libstdc++}, and not using @option{--disable-symvers}.  A helper
scripts needs @samp{Glob.pm}, which is missing from @command{perl} 5.005
included in Solaris@tie{}8.  The bundled @command{perl} in Solaris@tie{}9 and
up
works.
Used by various scripts to generate some files included in SVN (mainly
Unicode-related and rarely changing) from source tables.

[Bug bootstrap/48135] New: build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

   Summary: build fails on Solaris2.8 due to Glob.pm not found
within /usr/perl5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com
  Host: sparc64-sun-solaris2.8
Target: sparc64-sun-solaris2.8
 Build: sparc64-sun-solaris2.8


Building gcc-4.6.0-RC-20110314 on solaris8 (with gcc-3.3.2 preinstalled) fails
with the following message:


Can't locate File/Glob.pm in @INC (@INC contains:
/usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503
/usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .) at
/tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl
 line 19.
BEGIN failed--compilation aborted at
/tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl line
19.
make[5]: *** [libgomp.map-sun] Error 1


Indeed, there is no Glob.pm in the folders indicated. Under Solaris2.10 (where
we have /usr/perl5/5.8.4/lib/sun4-solaris-64int/File/Glob.pm) the build is ok
up to the end.

With GCC 4.5.2 no build problem with Solaris2.8 or Solaris2.10.

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
14:36:39 UTC ---
Created attachment 23664
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23664
gcc46-pr48134.patch

This fixes it, though perhaps as discussed earlier we want to fold everything
in expand_debug_expr except for memory addresses or something similar.

For 4.6 this is low priority, as with --enable-checking=release it will just
work, so doesn't need to be fixed before 4.6.0 release.

[Bug rtl-optimization/48133] [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-15 
14:13:22 UTC ---
Started failing with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149206

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-15 
13:59:05 UTC ---
That's the COMPONENT_REF case which runs into get_inner_reference which
doesn't deal with invalid MEM_REFs either.  It returns t.s as base.

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 13:55:32
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-15 
13:55:32 UTC ---
Confirmed.

(gdb) call debug_rtx (mem)
(mem/s/j/c:SI (plus:DI (debug_expr:DI D#3)
(const_int -12 [0xfff4])) [0 MEM[(struct S *)&t.s].z+0 S4
A32])

invalid MEM_EXPR again.

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #19 from Richard Guenther  2011-03-15 
13:41:43 UTC ---
Fixed.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Guenther  2011-03-15 
13:41:02 UTC ---
Fixed.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-03-15 
13:39:50 UTC ---
Author: rguenth
Date: Tue Mar 15 13:39:28 2011
New Revision: 170995

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170995
Log:
2011-03-15  Richard Guenther  

PR middle-end/47650
* tree-pretty-print.c (dump_function_declaration): Properly
dump unprototyped and varargs function types.

* gfortran.dg/c_f_pointer_tests_3.f90: Adjust.
* gfortran.dg/ishft_4.f90: Likewise.
* gfortran.dg/leadz_trailz_3.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90
trunk/gcc/testsuite/gfortran.dg/ishft_4.f90
trunk/gcc/testsuite/gfortran.dg/leadz_trailz_3.f90
trunk/gcc/tree-pretty-print.c

[Bug tree-optimization/48134] New: [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[zsojka at seznam dot cz]

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

   Summary: [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at
tree-ssa-alias.c:1085 with custom flags
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23663
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23663
reduced testcase (from gcc.dg/pr19633-1.c)

Maybe similiar to PR47283.

Compiler output:
$ gcc -O2 -fstack-check=specific -fno-tree-dse -fno-tree-fre
-fno-tree-loop-optimize -g testcase.c
testcase.c: In function 'foo':
testcase.c:26:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:1085
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r170964 - crash
4.6 r170955 - crash
4.5 r170955 - OK

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-03-15 
13:37:42 UTC ---
Author: rguenth
Date: Tue Mar 15 13:37:23 2011
New Revision: 170994

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170994
Log:
2011-03-15  Richard Guenther  

PR tree-optimization/13954
* tree-ssa-sccvn.c (vn_reference_lookup_3): Look through memcpy
and friends.

* g++.dg/tree-ssa/pr13954.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr13954.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
13:19:09 UTC ---
Regressed (expectedly) with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166167
The problem seems to be that the middle-end relies on indexes being filled in
in ctors for arrays, but the C++ FE in this case doesn't fill them in.
For POD arrays the indexes are added by process_init_constructor_array, but
that
isn't called in this case (both because check_initializer will do:
  /* Don't call digest_init; it's unnecessary and will complain
 about aggregate initialization of non-aggregate classes.  */
  flags |= LOOKUP_ALREADY_DIGESTED;
and also because it is called only for:
  if (BRACE_ENCLOSED_INITIALIZER_P (init)
  && !TYPE_NON_AGGREGATE_CLASS (type))
return process_init_constructor (type, init);

[Bug target/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch
 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-03/msg00829.htm
   ||l

[Bug target/48032] PowerPC64 -mcmodel=medium invalid ld offset

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #5 from Alan Modra  2011-03-15 12:59:25 
UTC ---
Fixed

[Bug target/48032] PowerPC64 -mcmodel=medium invalid ld offset

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  2011-03-15 12:57:42 
UTC ---
Author: amodra
Date: Tue Mar 15 12:57:37 2011
New Revision: 170990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170990
Log:
PR target/48032
* config/rs6000/rs6000.c (offsettable_ok_by_alignment): Do not
presume symbol_refs without a symbol_ref_decl are suitably
aligned, nor other trees we may see here.  Handle anchor symbols.
(legitimate_constant_pool_address_p): Comment.  Add mode param.
Check cmodel=medium addresses.  Adjust all calls.
(rs6000_emit_move): Don't call offsettable_ok_by_alignment on
creating cmodel=medium optimized access to locals.
* config/rs6000/constraints.md (R): Pass QImode to
legitimate_constant_pool_address_p.
* config/rs6000/predicates.md (input_operand): Pass mode to
legitimate_constant_pool_address_p.
* config/rs6000/rs6000-protos.h (legitimate_constant_pool_address_p):
Update prototype.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/rs6000/constraints.md
branches/gcc-4_6-branch/gcc/config/rs6000/predicates.md
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c

[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug

[aldyh at redhat dot com]

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

--- Comment #5 from Aldy Hernandez  2011-03-15 
12:42:36 UTC ---
> struct S
> {
>signed a : 26;
>signed b : 16;
>signed c : 10;
>volatile signed d : 14;
>int e;
> } s;
> I think you can't just modify s.e when writing s.d (I think it is fine to
> modify
> adjacent bitfields though, Aldy?).

No, you can't modify s.e when writing to s.d.  However, you can modify 
adjacent bitfields.  All contiguous bitfields can be considered a single 
memory location for the purpose of introducing data races.  The only 
exception is when bitfields are separated by a zero-length bitfield, or 
when they happen to be contiguous but occur in different 
structures/unions.  Those conditions force alignments on those fields.

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-03-15 
12:41:57 UTC ---
The patch fixed the pass-by-value cases to no longer go through stack memory.
The useless reg-reg moves prevail:

_Z6vsqrt2U8__vectord:
.LFB520:
.cfi_startproc
sqrtsd  %xmm0, %xmm1
unpckhpd%xmm0, %xmm0
movapd  %xmm1, %xmm2
sqrtsd  %xmm0, %xmm0
unpcklpd%xmm0, %xmm2
movapd  %xmm2, %xmm0
ret

both movapds can be avoided by better register allocation.

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-03-15 
12:22:18 UTC ---
Author: rguenth
Date: Tue Mar 15 12:22:12 2011
New Revision: 170986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170986
Log:
2011-03-15  Richard Guenther  

PR tree-optimization/48037
* tree-ssa.c (maybe_rewrite_mem_ref_base): Rewrite vector
selects into BIT_FIELD_REFs.
(non_rewritable_mem_ref_base): Check if a MEM_REF is a
vector select.

* gcc.target/i386/pr48037-1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr48037-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-15 
12:15:13 UTC ---
Reduced testcase:

struct C
{
  constexpr C (int x) : c (x) {}
  int c;
};

void
foo ()
{
  C a[] = { C (0) };
}

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-03-15 
11:49:12 UTC ---
The easiest way is to attach the may_alias attribute to all object types that
should not be subject to TBAA.  Bonus point if you transition that attribute
to use a flag instead.

[Bug rtl-optimization/48133] [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 11:44:24
   Target Milestone|--- |4.5.3
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-15 
11:44:24 UTC ---
Confirmed.

[Bug tree-optimization/46763] gcc 4.5: missed optimization: copy global to local, prefetch

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2011-03-15 
11:32:49 UTC ---
store sinking now works and exposes an if-conversion possibility:

:
  g.1_6 = i_19 + 1;
  g = g.1_6;
  i_7 = bar (i_16);
  g = i_7;
  goto ;

:
  g = i_16;

:
  # i_5 = PHI 

the stores to g can be if-converted by re-using the existing PHI like so:

:
  g.1_6 = i_19 + 1;
  g = g.1_6;
  i_7 = bar (i_16);
  goto ;

:
  ;

:
  # i_5 = PHI 
  g = i_5;

that eventually fits into the cs_elim framework, but cs_elim runs
too early - Micha, do you remember why it runs where it runs?

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
  Known to fail||

--- Comment #7 from Iain Sandoe  2011-03-15 11:29:29 
UTC ---
can the language lawyers take a look at this so that we can decide on a way
forward?