[Bug spam/45928] New: genattrtab is too slow.

[jay.krell at cornell dot edu]

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

   Summary: genattrtab is too slow.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: spam
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


genattrtab is too slow.

This step:
build/genattrtab ../../gcc-4.5/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-attrtab.c

takes a long time. I should look at what it is doing..

[Bug target/45927] New: autoconf regression wrt .quad availability targeting amd64 from biarch cross compiler

[jay.krell at cornell dot edu]

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

   Summary: autoconf regression wrt .quad availability targeting
amd64 from biarch cross compiler
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


Regression in 4.5.1 vs. 4.3.5 (sorry, we skipped 4.4)

gcc_GAS_CHECK_FEATURE([.quad directive],
  gcc_cv_as_ix86_quad,,,
  [.quad 0],,
  [AC_DEFINE(HAVE_AS_IX86_QUAD, 1,
[Define if your assembler supports the .quad directive.])])


This breaks cross builds to Solaris/amd64.
  You can then easily trigger this path:


const char *
integer_asm_op (int size, int aligned_p)
{
  struct asm_int_op *ops;

  if (aligned_p)
ops = &targetm.asm_out.aligned_op;
  else
ops = &targetm.asm_out.unaligned_op;


  switch (size)
{
case 1:
  return targetm.asm_out.byte_op;
case 2:
  return ops->hi;
case 4:
  return ops->si;
case 8:
  return ops->di;  <= NULL, but wasn't NULL in 4.3.5

...
bool
default_assemble_integer (rtx x ATTRIBUTE_UNUSED,
  unsigned int size ATTRIBUTE_UNUSED,
  int aligned_p ATTRIBUTE_UNUSED)
{
  const char *op = integer_asm_op (size, aligned_p);
  /* Avoid GAS bugs for large values.  Specifically negative values whose
 absolute value fits in a bfd_vma, but not in a bfd_signed_vma.  */
  if (size > UNITS_PER_WORD && size > POINTER_SIZE / BITS_PER_UNIT)
return false;
  return op && (assemble_integer_with_op (op, x), true);  <== NULL => false,
but was presumably true in 4.3.5
}


bool
assemble_integer (rtx x, unsigned int size, unsigned int align, int force)
{
  int aligned_p;

  aligned_p = (align >= MIN (size * BITS_PER_UNIT, BIGGEST_ALIGNMENT));

  /* See if the target hook can handle this kind of object.  */
  if (targetm.asm_out.integer (x, size, aligned_p))
return true;  <= no longer hit this

...
  if (! assemble_integer (expand_expr (exp, NULL_RTX, VOIDmode,
   EXPAND_INITIALIZER),
  MIN (size, thissize), align, 0))
 ==>error ("initializer for integer/fixed-point value is too complicated");
  break;



They worked fine in gcc 4.3 when this autoconfigury was absent.
gcc 4.3 assumed .quad was available in biarch x86.
Probably the autoconfigury is close to correct.
It should be used perhaps, but only for guiding 32bit compilation.


I verified the problem is related to:

/* The 32-bit Solaris assembler does not support .quad.  Do not use it.  */
#ifndef HAVE_AS_IX86_QUAD
#undef ASM_QUAD
#endif



gcc-4.5/gcc/config/i386/sol2.h


which wasn't in 4.3.5.

4.3.5 instead had:


/* The 32-bit Solaris assembler does not support .quad.  Do not use it.  */
#ifndef TARGET_BI_ARCH
#undef ASM_QUAD
#endif

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

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva  2010-10-07 
06:18:21 UTC ---
Aah, I think I got it: the MEM reference may throw, right?  Well, if i2src is
still available, I guess keeping the debug insn where it is, suitably adjusted,
is even better.  Did you check that it still makes sense after combine?

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

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva  2010-10-07 
06:15:15 UTC ---
(In reply to comment #6)
> The combiner swaps 2 insns.

This swap looks correct to me.  Presumably reg 85 is being dropped, so moving
the debug_insn down to a point at which it can refer to the used value should
be fine, no?  Is this move even related with the bug?  Why?

I'm trying to figure out why this change that drops “after”, presumably needed
for this very kind of situation, is correct, but I can't easily get an
environment in which I can duplicate the problem.  A cross compiler (without
target libs) doesn't seem to be enough (or at least I don't know how to run it
to trigger the problem).  Help?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

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

--- Comment #4 from Ralf Wildenhues  2010-10-07 
04:57:28 UTC ---
> --- Comment #2 from Jorn Wolfgang Rennecke  
> 2010-10-05 23:39:37 UTC ---
> > The output produced by genhooks is not portable (newline encoding), so it
> > should either produce binary output, or diff should be used to compare for
> > changes.
> 
> Sigh.  What was supposed to give C programs more portability works against
> us here.
> 
> Using diff to ignore line-end space change would not really be satisfactory,
> because then you'd get gratuitous changes in the checked in tm.texi whenever
> there is a change in the newline encoding in effect when autogenerating a
> changed tm.texi.

Good point.  Let's kill \r then.  It should be possible to use
  tr -d '\015'

on ASCII systems (\r is not portable to Solaris tr).  So for
portability you could pipe through this I guess:

case `echo X|tr X '\101'` in
 A) # ASCII based system
  tr -d '\015'
  ;;
 *) # EBCDIC based system
  tr -d '\r'
  ;;
esac

> Unless we make the copy step do newline translation, that is.
> So, what is the lesser evil in maintainability and portability?
> Generating binary output with unix-style newlines (as we generally have
> in our repository), or compare ignoring newline style and translating
> while copying?

> If we go for translating copying, do we make autoconf fail if no suitable
> tool is found?

There should always exist a suitable tool on systems where it is needed.
FWIW, I would just use the above in the Makefile though (after removing
the comments).

> I've found a problem with a circular dependency, but the patch for
> that didn't get reviewed:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

The hunk in that changing TEXI_GCCINT_FILES seems wrong, at least
gcc/doc/gccint.texi still has '@include tm.texi' so that's what the
dependency should be.

> If references to source / build trees are 'messed up' in other ways too,
> could you please be a bit more specific?

I think that should be it.  I was a bit confused when writing the
message.  Thanks.

[Bug libfortran/45839] Provide reasonable handling of I/O to/from FIFO file objects

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jerry DeLisle  2010-10-07 
02:57:46 UTC ---
After thinking about it some more and considering that a reasonable method was
found, I don't think this is worth pursuing further.  Closing.  If someone
thinks otherwise, feel free to reopen.

[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #19 from Jerry DeLisle  2010-10-07 
02:44:59 UTC ---
Fixed on trunk, 4.5, and 4.4.  Closing  Thanks for bug report.

[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle  2010-10-07 
02:38:04 UTC ---
Author: jvdelisle
Date: Thu Oct  7 02:38:00 2010
New Revision: 165080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165080
Log:
2010-10-06  Jerry DeLisle  

Backport from mainline
PR libfortran/45710
* gfortran.dg/namelist_65.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_65.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  2010-10-07 
02:31:18 UTC ---
Author: jvdelisle
Date: Thu Oct  7 02:31:14 2010
New Revision: 165079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165079
Log:
2010-10-06  Jerry DeLisle  

Backport from mainline:
PR libfortran/45710
* io/write.c (namelist_write_newline): Pad character array internal
unit records with spaces.

Modified:
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/io/write.c

[Bug target/45913] [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg00533.htm
   ||l
 CC||hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu  2010-10-07 02:24:12 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00533.html

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[samsonluk at gmail dot com]

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

--- Comment #11 from Samson Luk  2010-10-07 
01:47:23 UTC ---
(In reply to comment #8)

> In order to do a Canadian cross build - one where build != host (such as 
> your build with build = i686-pc-linux-gnu, host = arm-none-linux-gnueabi, 
> target = arm-none-linux-gnueabi) - you must first have built exactly the 
> same version of the compiler as a normal cross to the same target (build = 
> host - that is, in your case, build = host = i686-pc-linux-gnu, target = 
> arm-none-linux-gnueabi).

Understood, it mean I have to build the Cross Compiler which can be run in the
build machine, and this normal cross have to be the same version as the
Canadian cross!!!

> Once you have a build-x-target compiler with exactly the same version as 
> the Canadian cross you are trying to build, you can then build that 
> Canadian cross.  


> You also need a build-x-host compiler, which need not be 

Now I have to use Ubuntu gcc 4.4.3 to compile gcc 4.5.1 using: 
 build=i686-pc-linux-gnu 
  host=i686-pc-linux-gnu 
target=arm-none-linux-gnueabi

and I use the output normal cross which is in version 4.5.1 to:
 build=i686-pc-linux-gnu 
  host=arm-none-linux-gnueabi
target=arm-none-linux-gnueabi

and the output Canadian cross become 4.5.1. Finally I can copy this Canadian
cross together with the normal cross's target libraries to the arm machine.

Many thanks for the clear and detailed explanation! Do you know anywhere I can
find FAQ or documents for the mentioned procedures? I have google for half a
day and I found I lot on how to build a Cross Toolchain and no mention of how
to build a Canadian Cross compiler, especially for my case when the Canadian
Cross is one major version up.

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2010-10-07 
01:41:40 UTC ---
(In reply to comment #13)
> PS: I don't know if this can help you with your work, but today I wondered
> whether we should put to good use forward_as_tuple where we used to have tie
> and elsewhere too.

Good idea, I forgot we have that now.

I'll try to get a complete patch, including that idea, tomorrow.

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2010-10-07 
01:39:33 UTC ---
Super mega yeah!!!

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2010-10-07 
01:38:31 UTC ---
PS: I don't know if this can help you with your work, but today I wondered
whether we should put to good use forward_as_tuple where we used to have tie
and elsewhere too. Without having seriously analyzed the situation seems
strange that things like:

operator()(_Args&&... __args)
{
  return this->__call<_Result>(tuple<_Args...>
   (std::forward<_Args>(__args)...),
 can't be

operator()(_Args&&... __args)
{
  return this->__call<_Result>(forward_as_tuple(__args...),

or something like that... may need adjustments where tuple<_Args...> is now
expected, tough.

[Bug target/45913] [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #3 from H.J. Lu  2010-10-07 01:31:21 
UTC ---
Can we implement it

(insn:TI 110 50 107 (parallel [
(set (reg/v:SI 3 bx [orig:82 j ] [82])
(and:SI (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 4 [0x4])) [3 %sfp+-524 S4 A32])
(const_int 255 [0xff])))
(clobber (reg:CC 17 flags))
]) -1
 (nil))

as "movzbl m8,reg"?

[Bug target/45913] [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.07 01:25:13
 CC||matz at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-10-07 01:25:13 
UTC ---
It is triggered by revision 163998:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00290.html

[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  2010-10-07 
01:24:40 UTC ---
Author: jvdelisle
Date: Thu Oct  7 01:24:36 2010
New Revision: 165078

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165078
Log:
2010-10-06  Jerry DeLisle  

Backport from mainline
PR libfortran/45710
* gfortran.dg/namelist_65.f90: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_65.f90
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2010-10-07 
01:24:04 UTC ---
Great progress ;)

[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  2010-10-07 
01:20:28 UTC ---
Author: jvdelisle
Date: Thu Oct  7 01:20:23 2010
New Revision: 165077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165077
Log:
2010-10-06  Jerry DeLisle  

Backport from mainline:
PR libfortran/45710
* io/write.c (namelist_write_newline): Pad character array internal
unit records with spaces.

Modified:
branches/gcc-4_5-branch/libgfortran/ChangeLog
branches/gcc-4_5-branch/libgfortran/io/write.c

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[samsonluk at gmail dot com]

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

--- Comment #10 from Samson Luk  2010-10-07 
01:12:03 UTC ---
(In reply to comment #7)
> (In reply to comment #5)

> What configure command did you use to configure 4.5.1? (You only showed the
> command used to configure 4.4.1)

Jon, they are the same, sorry for the stupid cut and paste mistake.

[Bug middle-end/45926] [4.6 Regression] Revision 165057 breaks GOMP

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug middle-end/45926] New: [4.6 Regression] Revision 165057 breaks GOMP

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] Revision 165057 breaks GOMP
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


On Linux/ia32, revision 165057:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00239.html

caused:

http://gcc.gnu.org/ml/gcc-regression/2010-10/msg00058.html

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2010-10-07 
00:46:26 UTC ---
The _Bind and _Bind_result ctors need to be made into templates so that they
can deduce the arguments as either lvalue or rvalue references, allowing
_Bound_args elements to be move-constructed if an rvalue is passed to
std::bind.  Two template ctors are needed, for the case where the first
argument is an lvalue or an rvalue.

I added a copy ctor and move ctor, allowing _Bind and _Bind_result objects to
be moved

The new _Bind_helper and _Bindres_helper templates are simply to avoid
repeating typename _Maybe_wrap_member_pointer::type>::type in the return type and body of std::bind.

The call_once patch is for DR891, but is related to this PR because we use
std::bind to implement call_once.

[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.07 00:45:06
 Ever Confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  2010-10-07 
00:45:06 UTC ---
man...@gcc11:~$ test/164733M/build/gcc/cc1plus -Wall -Wextra test.C
 void G::fn() void G::fn() [with unsigned int NUM = 1u]
test.C:14:17:   instantiated from here
test.C:10:21: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]

man...@gcc11:~$ test/164733M/build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=test/164733M/build/gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: /home/manuel/test/src/configure
--prefix=/home/manuel/test/./164733M/install --enable-languages=all,ada
--enable-decimal-float --with-mpc=/opt/cfarm/mpc-0.8
--with-mpfr=/opt/cfarm/mpfr-2.4.1/
Thread model: posix
gcc version 4.6.0 20100929 (experimental) [trunk revision 146344] (GCC)

[Bug libstdc++/45924] [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.3   |4.5.2

--- Comment #5 from Jonathan Wakely  2010-10-07 
00:40:06 UTC ---
fixed for 4.5.2 and 4.6.0

[Bug libstdc++/45924] [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2010-10-07 
00:39:27 UTC ---
Author: redi
Date: Thu Oct  7 00:39:23 2010
New Revision: 165076

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165076
Log:
2010-10-07  Jonathan Wakely  

PR libstdc++/45924
* include/std/functional (_Bind_result::operator()): Do not expand
template parameter pack in forward call.
* testsuite/20_util/bind/45924.cc: New.

Added:
branches/gcc-4_5-branch/libstdc++-v3/testsuite/20_util/bind/45924.cc
Modified:
branches/gcc-4_5-branch/libstdc++-v3/ChangeLog
branches/gcc-4_5-branch/libstdc++-v3/include/std/functional

[Bug lto/45907] [4.6 Regression] Revision 164995 failed gcc.dg/torture/fp-int-convert-*.c

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  2010-10-07 
00:35:09 UTC ---
cris-elf too, whee.

[Bug tree-optimization/45921] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call at -O1

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/45921] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call at -O1

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #2 from H.J. Lu  2010-10-07 00:27:15 
UTC ---
It is caused by revision 159362:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00414.html

[Bug libstdc++/45924] [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-07 
00:19:33 UTC ---
Author: redi
Date: Thu Oct  7 00:19:18 2010
New Revision: 165075

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165075
Log:
2010-10-07  Jonathan Wakely  

PR libstdc++/45924
* include/std/functional (_Bind_result::operator()): Do not expand
template parameter pack in forward call.
* testsuite/20_util/bind/45924.cc: New.

Modified:
trunk/libstdc++-v3/ChangeLog

[Bug libstdc++/45924] [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2010-10-07 
00:17:30 UTC ---
Author: redi
Date: Thu Oct  7 00:17:24 2010
New Revision: 165072

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165072
Log:
PR libstdc++/45924
* include/std/functional (_Bind_result::operator()): Do not expand
template parameter pack in forward call.
* testsuite/20_util/bind/45924.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/bind/45924.cc
Modified:
trunk/libstdc++-v3/include/std/functional

[Bug objc/45925] New: New objc test failures

[hjl.tools at gmail dot com]

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

   Summary: New objc test failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: nicola.p...@meta-innovation.com


On Linux/x86-64, revision 165021 gave

FAIL: objc.dg/objc-foreach-1.m -fgnu-runtime (internal compiler error)
FAIL: objc.dg/objc-foreach-1.m -fgnu-runtime (test for excess errors)
FAIL: objc.dg/objc-foreach-2.m -fgnu-runtime (internal compiler error)
FAIL: objc.dg/objc-foreach-2.m -fgnu-runtime (test for excess errors)
FAIL: objc.dg/objc-foreach-3.m -fgnu-runtime (internal compiler error)
FAIL: objc.dg/objc-foreach-3.m -fgnu-runtime (test for excess errors)

Revision 165014 is OK.  It is caused by revision 165019:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00201.html

[Bug libstdc++/45924] [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.4.5
Version|4.5.3   |4.5.2
   Keywords||rejects-valid
   Last reconfirmed||2010.10.07 00:01:26
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
   Target Milestone|--- |4.5.3
  Known to fail||4.5.2, 4.6.0

--- Comment #1 from Jonathan Wakely  2010-10-07 
00:01:26 UTC ---
I'm testing a patch

[Bug libstdc++/45924] New: [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails

[redi at gcc dot gnu.org]

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

   Summary: [4.5/4.6 Regression] [C++0x] bind(x)(y, z) fails
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Notice while working on PR 45893, this fails:

#include 

struct f
{
  int operator()(int, int) { return 0; }
};

void test01()
{
  int i = 0;
  using namespace std::placeholders;
  std::bind(f(), _1, _2)(i, i);
}

int main()
{
  test01();
  return 0;
}

In file included from bind.cc:1:0:
/home/redi/gcc/4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/functional:
In member function ‘result_type std::_Bind_result<_Result, _Functor(_Bound_args
...)>::operator()(_Args&& ...) [with _Args = {int&, int&}, _Result = int,
_Functor = f, _Bound_args = {std::_Placeholder<1>, std::_Placeholder<2>},
result_type = int]’:
bind.cc:12:35:   instantiated from here
/home/redi/gcc/4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/functional:1327:31:
error: no matching function for call to ‘forward(int&)’


The reason is a misplaced template parameter pack expansion:
  tuple<_Args...>(std::forward<_Args...>(__args)...),
^^^
It should be:
  tuple<_Args...>(std::forward<_Args>(__args)...),

This is a regression against the version of std::bind in 4.4

[Bug c++/45923] New: constexpr diagnostic w/ non-literal

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr diagnostic w/ non-literal
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


This is pretty minor, but thought I'd point it out.


struct complex 
{
#if 0
  constexpr complex(double r, double i) : re(r), im(i) { } 
#else
  complex(double r, double i) : re(r), im(i) { } 
#endif
  constexpr double real() { return re; }
  double imag() const { return im; }

private:
  double re; 
  double im;
};

constexpr complex co1(0, 1); // literal object

//constant expression data initialized  by a user-defined literal
constexpr double dd2 = co1.real(); // OK


with:
%$bin/H-x86_64-gcc-constexpr.20101004/bin/g++ --version
g++ (GCC) 4.6.0 20101004 (experimental)

like so:
%$bin/H-x86_64-gcc-constexpr.20101004/bin/g++ -std=c++0x -c constexpr-basic.cc

gives:
constexpr-basic.cc:9:20: error: enclosing class of ‘constexpr double
complex::real() const’ is not a literal type

YES! Except the member function signature for real() has a superfulous "const"

constexpr-basic.cc:17:27: error: the type ‘const complex’ of constexpr variable
‘co1’ is not literal

YES! Except this is more like "invalid definition of constexpr variable 'co1'
of non-literal type 'complex'

constexpr-basic.cc:20:33: error: ‘double complex::real() const’ is not a
constexpr function

NO!

Perhaps the last one should read: 

constexpr-basic.cc:20:33: error: member function ‘constexpr double
complex::real()’ cannot be used in a constant expression with a non-literal
object

Or something.

[Bug c++/45148] [C++0x] constexpr g++ issues

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Benjamin Kosnik  2010-10-06 
23:36:19 UTC ---

this was fixed.

[Bug web/45922] New: notification email is not sent when an attachment is added

[zsojka at seznam dot cz]

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

   Summary: notification email is not sent when an attachment is
added
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


When I add an attachment to an existing bugreport, no email is sent. This may
cause the new testcase to old bugport to be ignored, because noone knows about
it.

This is what I see when I attach an attachment to an existing bugreport:


Attachment #21979 to bug 45875 created

Email sent to:
dcb...@hotmail.com, jamb...@gcc.gnu.org, hubi...@gcc.gnu.org 
Excluding:
gcc-bugs@gcc.gnu.org, unassig...@gcc.gnu.org 


This looks acceptable, but in the case of empty CC list, the situation gets
worse:


Attachment #21980 to bug 45921 created

Email sent to:
no one 
Excluding:
gcc-bugs@gcc.gnu.org, zso...@seznam.cz, unassig...@gcc.gnu.org 


There is no gcc dev aware of the new testcase, nor the notification is sent to
the mailing list. The newly attached testcase might be useful if there is no
useful testcase yet (because it is not reduced or the bug was hard to
reproduce).

[Bug tree-optimization/45921] New: [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call at -O1

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_stmts failed: invalid
conversion in gimple call at -O1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


This might be the same as PR45875 comment #6 (the testcase is very similiar)

Command line:
$ gcc -O testcase.C

Compiler output:
$ gcc -O testcase.C 
testcase.C: In function 'void* foo()':
testcase.C:16:1: error: invalid conversion in gimple call
void *

int

# .MEM_8 = VDEF <.MEM_11>
D.2143_4 = D.2145_3 (&obj.D.2078);

testcase.C:16:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165058 - ICE
r164716 - ICE
r163636 - segfault
r159696 - segfault
r158095 - OK

[Bug other/45920] Building gcc: flags passed during configure step not used everywhere

[phantall at gmail dot com]

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

--- Comment #1 from Brian Vandenberg  2010-10-06 
23:23:54 UTC ---
This is more systemic than just (...)/gcc.  Other Makefiles have the same issue
(eg, libdecnumber, libcpp to name a few).

-Brian

[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Paolo Carlini  2010-10-06 
23:18:20 UTC ---
Let's add Manuel in CC...

[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison

[yuri at tsoft dot com]

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

--- Comment #2 from Yuri  2010-10-06 23:16:21 UTC ---
No warning in 4.2.1 for example.

[Bug other/45920] New: Building gcc: flags passed during configure step not used everywhere

[phantall at gmail dot com]

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

   Summary: Building gcc: flags passed during configure step not
used everywhere
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


I'm on a network with a hodgepodge of tools of varying versions, and I'm
attempting to remedy the problem, but I can only build from sources for this
particular environment.

The build target is sparcv9-sun-solaris2.10, and I configured with:

mkdir /usr1/tools/gcc-4.5.1-build
cd /usr1/tools/gcc-4.5.1-build
../gcc-4.5.1/configure --prefix=/usr1/local/gcc-4.5.1 \
  --with-gmp=/usr1/local/gmp-5.0.1 \
  --with-mpfr=/usr1/local/mpfr-3.0.0 \
  --with-mpc=/usr1/local/mpc-0.8.2 \
  --build=sparcv9-sun-solaris2.10 \
  --enable-languages='c,c++' \
  --with-stage1-ldflags='-O2 -m64 -mptr64 -mcpu=v9' \
  --with-boot-ldflags='-O2 -m64 -mptr64 -mcpu=v9' \
  CC=/opt/csw/gcc3/bin/gcc \
  CFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  CPPFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  BOOT_CFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  LDFLAGS='-O2 -m64 -mptr64 -mcpu=v9'


The overload of flags is from me trying to find some way to get the portion I
encountered problems with to use the right flags.

During stage 1 (stage_last and stage_current both say stage 1 in them), it
enters the /gcc directory and executes the Makefile there.  It fails
after building (gensupport?) and errors when it tries to link them.  The link
step has the appropriate flags to target a 64-bit platform, but the other two
object files target ELF32.

The error I was receiving was "wrong ELF class, ELFCLASS32" during link.

On line 3675 or so of (...)/gcc/Makefile, it has the following line:


$(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \
  -o $@ $<


Neither BUILD_COMPILERFLAGS or BUILD_CPPFLAGS contain the appropriate flags I
set during the configure step.  Furthermore, around line 136 the CFLAGS line is
empty -- which is probably the cause.

As a temporary workaround I added appropriate flags to line 136.

[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  2010-10-06 
23:10:35 UTC ---
I suspect part of this is actually intended, we used to have stronger warnings
at some point in this area, but then people noticed that unavoidably too many
false positives are often produced with templates... Do you have any idea if we
ever warned for this, say, in 4.0,x, 4.1.x?

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #12 from Jerry DeLisle  2010-10-06 
22:56:40 UTC ---
Fixed on trunk. Thanks Keith for the report!

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  2010-10-06 
22:49:30 UTC ---
Author: jvdelisle
Date: Wed Oct  6 22:49:28 2010
New Revision: 165069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165069
Log:
2010-10-06  Jerry DeLisle  

PR fortran/45889
* gfortran.dg/alloc_comp_constraint_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_6.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  2010-10-06 
22:38:36 UTC ---
Author: jvdelisle
Date: Wed Oct  6 22:38:30 2010
New Revision: 165068

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165068
Log:
2010-10-06  Jerry DeLisle  

PR fortran/45889
* resolve.c (resolve_transfer): Use expression inside parenthesis to
find acutal component to be transgferred.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug tree-optimization/45919] New: [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference
(tree-ssa-ccp.c:1527) at -O1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Compiler output:
$ gcc -O testcase.c 
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165058 - crash
r164716 - crash
r163636 - OK

[Bug c++/45917] inaccessible types allowed as template argument in nested-name-specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|Friend of friend is allowed |inaccessible types allowed
   |the access to the private   |as template argument in
   |type through the template   |nested-name-specifier

--- Comment #2 from Jonathan Wakely  2010-10-06 
21:48:01 UTC ---
Here's another variation that should fail but doesn't, showing this has nothing
to do with friends:

template
struct list
{
  struct nested { };
};

class F
{
  struct R { };
};

void f() { list::nested n; }

list::nested n;


I've changed the summary to reflect this

[Bug c++/45918] New: Lack of warning on meaningless unsigned to zero comparison

[yuri at tsoft dot com]

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

   Summary: Lack of warning on meaningless unsigned to zero
comparison
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com


In this case idx
struct G {
  void fn();
};

template
void G::fn() {
for (size_t idx = 0; idx;

[Bug c++/45917] Friend of friend is allowed the access to the private type through the template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.06 21:40:27
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2010-10-06 
21:40:27 UTC ---
(In reply to comment #0)
> class F declares class Q a friend

There's no need for that, Q is a member of F so has access like any other
member.

Reduced:

template
struct list
{
  struct nested { };
};


class F
{
  struct R { };
  class Q
  {
friend void f(const Q &q) { list::nested n; }
  };
};

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|paolo.carlini at oracle dot |
   |com |
 Resolution||INVALID

--- Comment #9 from Paolo Carlini  2010-10-06 
21:29:03 UTC ---
Thanks Joseph, I think the issue is clear enough by now.

[Bug c++/45917] New: Friend of friend is allowed the access to the private type through the template

[yuri at tsoft dot com]

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

   Summary: Friend of friend is allowed the access to the private
type through the template
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com


testcase below has struct R as private in class F.
class F declares class Q a friend, allowing it to see it's private members.
But operator<< is friend in Q, not in F.
Why is it allowed for operator<< to instantiate list but not R r? This is a
bug.

--- testcase ---
#include 
#include 
using namespace std;

class F {
private:
  struct R {
  }; // R
  friend class Q;
  class Q {
list l;
friend ostream& operator<<(ostream &os, const Q &q) {
  // R r; // this breaks!
  for (list::const_iterator it = q.l.begin(); it != q.l.end(); it++) {
// this doesn't break! Why?
  }
  return os;
}
  }; // Q
}; // F

[Bug fortran/45916] [4.6 regression] ICE in match_procedure_in_type, at fortran/decl.c:7921

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org 2010-10-06 21:07:28 UTC ---
(In reply to comment #3)
> Ahem.
> OK. I didn't even read the comment.
> 
>   /* See if we already have a binding with this name in the symtree which
>  would be an error.  If a GENERIC already targetted this binding, it may
>  be already there but then typebound is still NULL.  */
> 
> A NULL is expected. I will revert.

Please add your reduced testcase to ensure
that future changes don't brek this. 

Thanks.

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  
2010-10-06 20:56:56 UTC ---
On Wed, 6 Oct 2010, muravev at yandex dot ru wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
> 
> --- Comment #9 from Ilya Murav'jov  2010-10-06 
> 19:43:30 UTC ---
> I've come across another weird warning emission in g++ 4.4:
> 
> $ cat test.cc
> #include 
> struct interface_type {
> 
> virtual interface_type* clone(void* storage) const
> {
> return ::new (storage) interface_type();
> }
> };
> 
> struct poly_base {
> 
> poly_base(const interface_type& x) { x.clone(data); }
> 
> typedef char storage_t[100];
> storage_t data;
> };
> 
> struct instance_t: interface_type {};
> 
> int main()
> {
> instance_t pi;
> poly_base p1(pi);
> 
> interface_type* ptr = (interface_type*)(p1.data);
> poly_base p2(*ptr);
> }
> $ g++ -O3 -Wstrict-aliasing test.cc -o /dev/null
> test.cc: In function ‘int main()’:
> test.cc:12: warning: dereferencing pointer ‘ptr’ does break strict-aliasing
> rules
> test.cc:25: note: initialized from here
> 
> $ g++ -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
> --enable-multiarch --enable-linker-build-id --with-system-zlib
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
> --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
> --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
> 
> I get this only in g++ 4.4, g++ 4.5 does not warn.
> 
> I want to note that this is a different type of warning about strict-aliasing
> rules, likely a more serious one. Can anyone tell what a difference between
> "warning: dereferencing type-punned pointer will break strict-aliasing rules"
> and "warning: dereferencing pointer ‘ptr’ does break strict-aliasing rules"?

The latter means that when doing pointer analysis GCC pruned all 
pointed-to objects using TBAA so the pointer ended up pointing to
nothing (but still was dereferenced).  The good news for you is that
GCC will assume the pointer points to anything in that case, not
nothing.

In GCC 4.5 points-to analysis doesn't use TBAA to prune the sets anymore
(because its fundamentally wrong), so the code emitting the warning
was removed.

Richard.

[Bug fortran/45916] [4.6 regression] ICE in match_procedure_in_type, at fortran/decl.c:7921

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.06 20:48:10
 Ever Confirmed|0   |1

--- Comment #3 from Mikael Morin  2010-10-06 
20:48:10 UTC ---
Ahem.
OK. I didn't even read the comment.

  /* See if we already have a binding with this name in the symtree which
 would be an error.  If a GENERIC already targetted this binding, it may
 be already there but then typebound is still NULL.  */

A NULL is expected. I will revert.

[Bug fortran/45916] [4.6 regression] ICE in match_procedure_in_type, at fortran/decl.c:7921

[mikael at gcc dot gnu.org]

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

--- Comment #2 from Mikael Morin  2010-10-06 
20:45:53 UTC ---
Reduced testcase:

module m_sort
  implicit none
  type, abstract :: sort_t
  contains
generic :: operator(.gt.) => gt_cmp
procedure(gt_cmp), deferred :: gt_cmp
  end type sort_t
end module m_sort

[Bug target/42070] FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
   Target Milestone|--- |4.5.2

[Bug java/43839] libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

   Target Milestone|4.5.1   |4.5.2

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[muravev at yandex dot ru]

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

--- Comment #9 from Ilya Murav'jov  2010-10-06 
19:43:30 UTC ---
I've come across another weird warning emission in g++ 4.4:

$ cat test.cc
#include 
struct interface_type {

virtual interface_type* clone(void* storage) const
{
return ::new (storage) interface_type();
}
};

struct poly_base {

poly_base(const interface_type& x) { x.clone(data); }

typedef char storage_t[100];
storage_t data;
};

struct instance_t: interface_type {};

int main()
{
instance_t pi;
poly_base p1(pi);

interface_type* ptr = (interface_type*)(p1.data);
poly_base p2(*ptr);
}
$ g++ -O3 -Wstrict-aliasing test.cc -o /dev/null
test.cc: In function ‘int main()’:
test.cc:12: warning: dereferencing pointer ‘ptr’ does break strict-aliasing
rules
test.cc:25: note: initialized from here

$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

I get this only in g++ 4.4, g++ 4.5 does not warn.

I want to note that this is a different type of warning about strict-aliasing
rules, likely a more serious one. Can anyone tell what a difference between
"warning: dereferencing type-punned pointer will break strict-aliasing rules"
and "warning: dereferencing pointer ‘ptr’ does break strict-aliasing rules"?

[Bug java/43839] libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

   Target Milestone|--- |4.5.1

[Bug fortran/33097] Function decl trees without proper argument list

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

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

--- Comment #17 from Jack Howarth  2010-10-06 
19:37:20 UTC ---
FYI, this PR apparently causes all of the remaining Polyhedron 2005 benchmark
compile failures when building with gcc 4.5.2 using the current dragonegg 2.8
plugin...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-October/035255.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-October/035256.html

While fixing this PR might not be particularly helpful in stock gcc trunk, it
would greatly enhance dragonegg's usefulness under the same.

[Bug fortran/45916] [4.6 regression] ICE in match_procedure_in_type, at fortran/decl.c:7921

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin  2010-10-06 
19:29:01 UTC ---
regressing commit http://gcc.gnu.org/viewcvs?view=revision&revision=165026

[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges

[mrs at gcc dot gnu.org]

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

--- Comment #9 from mrs at gcc dot gnu.org  2010-10-06 
19:28:42 UTC ---
Author: mrs
Date: Wed Oct  6 19:28:40 2010
New Revision: 165064

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165064
Log:
2010-10-06  Jack Howarth 

Backport from mainline
2010-08-18  Iain Sandoe  

PR debug/42487
* lib/target-supports.exp (check_effective_target_function_sections): New.
* gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Check that the target supports
function sections before proceding.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c
branches/gcc-4_5-branch/gcc/testsuite/lib/target-supports.exp

[Bug fortran/45916] New: [4.6 regression] ICE in match_procedure_in_type, at fortran/decl.c:7921

[mikael at gcc dot gnu.org]

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

   Summary: [4.6 regression] ICE in match_procedure_in_type, at
fortran/decl.c:7921
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mik...@gcc.gnu.org


Reported by Dominique at http://gcc.gnu.org/ml/fortran/2010-10/msg00076.html

testcases are the ones from PR43199, 43896 and pr41951. 
They are huge unfortunately.

[Bug target/42070] FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use

[mrs at gcc dot gnu.org]

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

--- Comment #6 from mrs at gcc dot gnu.org  2010-10-06 
19:22:40 UTC ---
Author: mrs
Date: Wed Oct  6 19:22:37 2010
New Revision: 165063

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165063
Log:
2010-10-06  Jack Howarth 

Backport from mainline
2010-09-10  Jack Howarth 

PR target/42070
* lib/profopt.exp: Prune warnings on execname2 compile.
* lib/prune.exp: Prune "can't add line info" warnings.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/lib/profopt.exp
branches/gcc-4_5-branch/gcc/testsuite/lib/prune.exp

[Bug target/43715] configure option --enable-plugin fails on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #10 from mrs at gcc dot gnu.org  2010-10-06 
19:09:14 UTC ---
Author: mrs
Date: Wed Oct  6 19:09:10 2010
New Revision: 165062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165062
Log:
2010-10-06  Jack Howarth  

Backport from mainline
2010-04-26  Jack Howarth 

PR 43715
* configure.ac: Pass -g for export_sym_check on darwin.
Use "-undefined dynamic_lookup" on darwin.
* configure: Regenerate.

testsuite:
2010-10-06  Jack Howarth  

Backport from mainline
2010-04-26  Jack Howarth 

PR 43715
* lib/plugin-support.exp: Use "-undefined
dynamic_lookup" on darwin.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/configure
branches/gcc-4_5-branch/gcc/configure.ac
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/lib/plugin-support.exp

[Bug other/45915] New: Check for gnu_unique_object in ld.so in gcc/configure.ac is broken for non-glibc ldd

[gcc-tgc at jupiterrise dot com]

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

   Summary: Check for gnu_unique_object in ld.so in
gcc/configure.ac is broken for non-glibc ldd
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-...@jupiterrise.com
  Host: i386-pc-solaris2.8


While building gcc-4.6-20101002 with this configure invocation:
./gcc-4.6-20101002/configure --prefix=/usr/tgcware/gcc46 --with-gnu-as
--with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--disable-nls --enable-shared --enable-languages=c,c++,fortran,ada

Where gas is from binutils 2.20.1 (Blastwave build).

I noticed this output:

checking assembler for gnu_unique_object... yes
expr: syntax error
/export/home/pkgsrc/build/gcc-4.6-20101002/gcc/configure: test: : integer
expression expected

Looking in gcc/configure.ac beginning in line 3840 is the problem.
It runs 'ldd --version' and expects output that can be parsed into an integer.
This fails on Solaris and $glibcmajor is empty when expr tries to do math with
it causing the error above to be printed.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[eager at eagercon dot com]

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

--- Comment #7 from Michael Eager  2010-10-06 
18:58:15 UTC ---
Attached patches should correct test case failures.  Tested on x86_64 and x86.

[Bug java/43839] libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix

[mrs at gcc dot gnu.org]

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

--- Comment #12 from mrs at gcc dot gnu.org  2010-10-06 
18:54:31 UTC ---
Author: mrs
Date: Wed Oct  6 18:54:14 2010
New Revision: 165061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165061
Log:
2010-10-06  Jack Howarth 

Backport from mainline
2010-05-03  Jack Howarth 

PR java/43839
* testsuite/Makefile.am: Override automake for site.exp creation
and add entry to set libiconv.
* testsuite/Makefile.in: Regenerate.
* testsuite/libjava.jni/jni.exp (gcj_jni_get_cxxflags_invocation):
Add new global variable libiconv to handle alternative libiconv
locations.

Modified:
branches/gcc-4_5-branch/libjava/ChangeLog
branches/gcc-4_5-branch/libjava/testsuite/Makefile.am
branches/gcc-4_5-branch/libjava/testsuite/Makefile.in
branches/gcc-4_5-branch/libjava/testsuite/libjava.jni/jni.exp

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  2010-10-06 18:53:27 UTC ---
On Wed, 6 Oct 2010, samsonluk at gmail dot com wrote:

> Now I understand... seems to me a chicken and egg problem... I am already 
> using
> the latest Cross Toolchain and it only came with gcc/c++ 4.4.1. It seems that
> gcc 4.5.x was build successfully, do you mean I have to make use of the new
> build gcc to build the c++ 4.5.x? In that case I have to move the new gcc to
> the target machine and native build again the whole 4.5.x?

In order to do a Canadian cross build - one where build != host (such as 
your build with build = i686-pc-linux-gnu, host = arm-none-linux-gnueabi, 
target = arm-none-linux-gnueabi) - you must first have built exactly the 
same version of the compiler as a normal cross to the same target (build = 
host - that is, in your case, build = host = i686-pc-linux-gnu, target = 
arm-none-linux-gnueabi).

Once you have a build-x-target compiler with exactly the same version as 
the Canadian cross you are trying to build, you can then build that 
Canadian cross.  You also need a build-x-host compiler, which need not be 
the same version as the Canadian cross you are trying to build.  (Thus, if 
you are building 4.5 with build = i686-pc-linux-gnu, host = i686-mingw32, 
target = arm-none-linux-gnueabi, then you need a compiler that runs on 
i686-pc-linux-gnu and targets i686-mingw32, any reasonable version, and 
one that runs on i686-pc-linux-gnu and targets arm-none-linux-gnueabi, 
which must be 4.5.)

Once you do have a build-x-target compiler, you can also speed things up 
by just doing "make all-gcc" (or "make all-host") and copying the target 
libraries from your build-x-target compiler instead of rebuilding them.

[Bug target/36732] Internal compiller bug

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #2 from Zdenek Sojka  2010-10-06 18:47:40 
UTC ---
I can reproduce this on x86_64-pc-linux-gnu with following versions:
4.2.4, 4.3.5
but not with versions:
4.4.4, 4.5.1, 4.6.0 (r164716)

(all except 4.6.0 are gentoo builds)

[Bug other/45914] New: Typo in gcc/configure.ac

[gcc-tgc at jupiterrise dot com]

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

   Summary: Typo in gcc/configure.ac
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-...@jupiterrise.com
  Host: i386-pc-solaris2.8


While building gcc-4.6-20101002 I noticed this output from configure:

checking linker and ld.so.1 TLS support...
/export/home/pkgsrc/build/gcc-4.6-20101002/gcc/configure: test: : integer
expression expected
yes

Looking in gcc/configure.ac I see that it is caused by an obvious typo in line
3017 where 'ls_vers_major' should have been 'ld_vers_major'.

[Bug target/45913] New: [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in insn_default_length, at
config/i386/i386.md:584 with -fselective-scheduling2
-fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Command line:
$ gcc -O2 -fselective-scheduling2 -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops testcase.c

Compiler output:
$ gcc -O2 -fselective-scheduling2 -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops testcase.c
testcase.c: In function 'foo':
testcase.c:19:1: error: unrecognizable insn:
(insn:TI 110 50 107 (parallel [
(set (reg/v:SI 3 bx [orig:82 j ] [82])
(and:SI (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 4 [0x4])) [3 %sfp+-524 S4 A32])
(const_int 255 [0xff])))
(clobber (reg:CC 17 flags))
]) -1
 (nil))
testcase.c:19:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:584
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r164716 - crash
r163636 - OK
4.5 r163761 - OK

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2010-10-06 
18:33:01 UTC ---
(In reply to comment #5)
> It seems that
> gcc 4.5.x was build successfully, do you mean I have to make use of the new
> build gcc to build the c++ 4.5.x?

That should happen automatically when you build gcc 4.5.1 with
enable-languages=c++

What configure command did you use to configure 4.5.1? (You only showed the
command used to configure 4.4.1)

> In that case I have to move the new gcc to
> the target machine and native build again the whole 4.5.x?

No

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.06 18:17:21
 Ever Confirmed|0   |1

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2010-10-06 
17:58:26 UTC ---
Only 4.5.x can build the 4.5.x C++ runtime library.

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[samsonluk at gmail dot com]

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

--- Comment #5 from Samson Luk  2010-10-06 17:56:57 
UTC ---
(In reply to comment #4)

Now I understand... seems to me a chicken and egg problem... I am already using
the latest Cross Toolchain and it only came with gcc/c++ 4.4.1. It seems that
gcc 4.5.x was build successfully, do you mean I have to make use of the new
build gcc to build the c++ 4.5.x? In that case I have to move the new gcc to
the target machine and native build again the whole 4.5.x?

[Bug c++/45908] [C++0x] ICE involving decltype: in tree_low_cst, at tree.h:4114

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2010-10-06 
17:37:32 UTC ---
(In reply to comment #7)
> re comment 2, is 4.5 correct to use a non-const access path to v.begin() in 
> the
> trailing-return-type?

Yes.  The trailing-return-type is not in the context of the function, so 'v' is
not based on 'this'.  I'll raise this as an issue with the committee.

[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6

[nate at ucar dot edu]

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

Nate  changed:

   What|Removed |Added

 CC||nate at ucar dot edu

--- Comment #10 from Nate  2010-10-06 17:35:53 UTC ---
I managed to get it to compile partially with the following:

flag=" -lgcc -I/usr/local/include/ -I/usr/include/ -L/usr/local/lib/ -Wl,-brtl
-Wl,-berok "
export BOOT_CFLAGS="-O2 -maix32 -g"
export PATH=/usr/local/bin/:$PATH
export CC="/usr/local/bin/gcc" CFLAGS=" $flag "
export CXX=/usr/local/bin/g++ CXXFLAGS=" $flag "
export CPP="$CC -E " CPPFLAGS=" $flag "
export CPPFLAGS=-fexceptions
export OBJECT_MODE=32
export LDFLAGS="-L/usr/local/lib/ -berok"
make clean
./configure --enable-languages=c,c++,fortran --prefix=/usr/local/gcc/4.5.1/
ABI=32 --enable-bootstrap --with-gmp=/usr/local/gcc/4.5.1/
--with-mpfr=/usr/local/gcc/4.5.1/ --with-mpc=/usr/local/gcc/4.5.1/ && \
make bootstrap

It gets all the way to here:
make[3]: Entering directory
`/usr/local/src/gcc-4.5.1/build-powerpc-ibm-aix5.3.0.0/libiberty'
if [ x"" != x ]; then \
  /usr/local/bin/gcc -c -DHAVE_CONFIG_H -lgcc -I/usr/local/include/
-I/usr/include/ -L/usr/local/lib/ -Wl,-brtl -Wl,-berok   -fexceptions -I.
-I../.././libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic   ../.././libiberty/physmem.c -o pic/physmem.o; \
else true; fi
/usr/local/bin/gcc -c -DHAVE_CONFIG_H -lgcc -I/usr/local/include/
-I/usr/include/ -L/usr/local/lib/ -Wl,-brtl -Wl,-berok   -fexceptions -I.
-I../.././libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  ../.././libiberty/physmem.c -o physmem.o
../.././libiberty/physmem.c: In function 'physmem_total':
../.././libiberty/physmem.c:96: error: storage size of 'pss' isn't known
../.././libiberty/physmem.c:97: warning: implicit declaration of function
'pstat_getstatic'
../.././libiberty/physmem.c:96: warning: unused variable 'pss'
../.././libiberty/physmem.c: In function 'physmem_available':
../.././libiberty/physmem.c:200: error: storage size of 'pss' isn't known
../.././libiberty/physmem.c:201: error: storage size of 'psd' isn't known
../.././libiberty/physmem.c:203: warning: implicit declaration of function
'pstat_getdynamic'
../.././libiberty/physmem.c:201: warning: unused variable 'psd'
../.././libiberty/physmem.c:200: warning: unused variable 'pss'
make[3]: *** [physmem.o] Error 1
make[3]: Leaving directory
`/usr/local/src/gcc-4.5.1/build-powerpc-ibm-aix5.3.0.0/libiberty'

[Bug tree-optimization/45912] [4.6 regression] Patch for PR tree-optimization/44972 caused 2500+ FAILs on Solaris 2/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.06 17:17:47
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Eric Botcazou  2010-10-06 
17:17:47 UTC ---
Investigating.

[Bug web/45911] bugzilla: Changing status to assigned no longer auto-adjusts the assign-to field

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-10-06 
17:01:37 UTC ---
Yes, I reported this in the bugzilla-test instance.
It would be useful to restore the "accept bug" button on UNCONFIRMED and NEW
bugs which sets Status=ASSIGNED and AssignedTo=me

[Bug libstdc++/45863] [4.6 regression] FAIL: libstdc++-abi/abi_check

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  2010-10-06 17:01:17 UTC 
---
Author: ro
Date: Wed Oct  6 17:01:11 2010
New Revision: 165055

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165055
Log:
PR libstdc++/45863
* scripts/extract_symvers: Restore revision 164879.
Only use pvs on SunOS.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/scripts/extract_symvers

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2010-10-06 
16:50:34 UTC ---
Just to expand a little bit on what Jon said: you are getting an error on
__is_trivial, which is a C++ front-end "builtin" available in 4.5.x and not
available in 4.4.x. Thus, the only way to make sense of your problem is that,
for some reason, you are building the 4.5.x C++ library with a 4.4.x compiler.
This is not going to work for the specific reason clarified above, and in
general should *never* happen for sane configuratons: the C++ library is always
built by the newly built C++ compiler. You are most definitely configuring
incorrectly.

[Bug tree-optimization/45912] New: [4.6 regression] Patch for PR tree-optimization/44972 caused 2500+ FAILs on Solaris 2/SPARC

[ro at gcc dot gnu.org]

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

   Summary: [4.6 regression] Patch for PR tree-optimization/44972
caused 2500+ FAILs on Solaris 2/SPARC
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org, jamb...@gcc.gnu.org
  Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
 Build: sparc-sun-solaris2.*


Created attachment 21973
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21973
stage1 assembler output

The Solaris 2/SPARC port (probably every SPARC port) is in a terrible state
with
2500+ execution failures in the testsuite (mostly 64-bit).

A reghunt revealed that this was introduced by this patch:

2010-09-10  Martin Jambor  

PR tree-optimization/44972
* tree-sra.c: Include toplev.h.
(build_ref_for_offset): Entirely reimplemented.
(build_ref_for_model): New function.
(build_user_friendly_ref_for_offset): New function.
(analyze_access_subtree): Removed build_ref_for_offset check.
(propagate_subaccesses_across_link): Likewise.
(create_artificial_child_access): Use
build_user_friendly_ref_for_offset.
[...]

The reghunt proved difficult because originally the tree didn't build due to
PR tree-optimization/45611 (fixed in r164244) and PR bootstrap/45630 (fixed in
r164163).  The problem is a miscompilation since it doesn't occur with the
stage1
compiler.

I've used the -O2 compilation of gcc.c-torture/execute/2706-5.c as the
testcase during the reghunt.  It can be compiled with

% cc1 2706-5.c -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -m64 -O2 -w

I'm attaching the stage1 and stage3 .s files for comparison.  The test SEGVs
here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0001098c in main ()
1: x/i $pc
=> 0x1098c :   st  %g3, [ %g4 + %g2 ]
(gdb) p/x $g4+$g2
$3 = 0x371d8

The target address is unmapped in the process, as can be seen with pmap:

19505:  /var/gcc/reghunt/102852/gcc/testsuite/gcc/stage3/2706-5.x2
0001  8K r-x-- 
/var/gcc/reghunt/102852/gcc/testsuite/gcc/stage3/2706-5.x2
00010010  8K rwx-- 
/var/gcc/reghunt/102852/gcc/testsuite/gcc/stage3/2706-5.x2
7F10   1216K r-x--  /lib/sparcv9/libc.so.1
7F23 48K r-x--  /lib/sparcv9/libc.so.1
7F30 24K rwx--[ anon ]
7F33C000 72K rwx--  /lib/sparcv9/libc.so.1
7F34E000  8K rwx--  /lib/sparcv9/libc.so.1
7F40640K r-x--  /lib/sparcv9/libm.so.2
7F50  8K rwx--[ anon ]
7F59E000 40K rwx--  /lib/sparcv9/libm.so.2
7F60 64K r-x--  /lib/sparcv9/ld.so.1
7F61 64K r-x--  /lib/sparcv9/ld.so.1
7F62 64K r-x--  /lib/sparcv9/ld.so.1
7F63 24K r-x--  /lib/sparcv9/ld.so.1
7F70 64K rwx--[ anon ]
7F736000 16K rwx--  /lib/sparcv9/ld.so.1
7F73A000  8K rwx--  /lib/sparcv9/ld.so.1
7FFF 64K rw---[ stack ]
 total 2440K

Please fix asap; it is almost impossible to do any useful work on a port that
broken.

Thanks.
  Rainer

[Bug web/45911] New: bugzilla: Changing status to assigned no longer auto-adjusts the assign-to field

[rth at gcc dot gnu.org]

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

   Summary: bugzilla: Changing status to assigned no longer
auto-adjusts the assign-to field
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Our bugzilla used to change the assign-to field away from
unassig...@gcc.gnu.org automatically.  Now you have to do
it in two steps.

[Bug rtl-optimization/33721] [meta-bug] Gcc can't properly align stack variable

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC||rth at gcc dot gnu.org

--- Comment #6 from Richard Henderson  2010-10-06 
16:34:08 UTC ---
Mine.

[Bug debug/12990] CFA not tracked in epilogues

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0

[Bug debug/12990] CFA not tracked in epilogues

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||rth at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Richard Henderson  2010-10-06 
16:30:13 UTC ---
This was fixed for gcc 4.5.

[Bug target/18749] GCC fails to mark stack-popping instruction in unwind-info

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||rth at gcc dot gnu.org
 Resolution||DUPLICATE
  Known to fail||

--- Comment #6 from Richard Henderson  2010-10-06 
16:25:24 UTC ---
Dup

*** This bug has been marked as a duplicate of bug 12990 ***

[Bug debug/12990] CFA not tracked in epilogues

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||davidm at hpl dot hp.com

--- Comment #4 from Richard Henderson  2010-10-06 
16:25:24 UTC ---
*** Bug 18749 has been marked as a duplicate of this bug. ***

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-06 
16:14:16 UTC ---
(In reply to comment #0)
> make[4]: Entering directory
> `/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/src'
> /bin/sh ../libtool --tag CXX   --mode=compile arm-none-linux-gnueabi-c++ 
> -I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi
> -I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include
> -I/home/samson/src/gcc-4.5.1/libstdc++-v3/libsupc++  -fno-implicit-templates
> -Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
> -ffunction-sections -fdata-sections  -g -O2 -D_GNU_SOURCE -std=gnu++0x -c
> /home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc
> libtool: compile:  arm-none-linux-gnueabi-c++
> ...

Is that using the previously-built 4.4.1 compiler, not the newly-built 4.5.1
one?

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[samsonluk at gmail dot com]

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

--- Comment #2 from Samson Luk  2010-10-06 15:57:13 
UTC ---

> I know very little about cross-compilation, but something seems badly wrong
> with the setup you are using: the 4.5.1 C++ front-end definitely implements 
> the
> __is_trivial "builtin".

I have been using this toolchain for kernel compile and compiling all sort of
packages without any problem as I said using the same options / setup to
compile gcc 4.4.1 without any problem.  Appreciated for any recommendation on
how to debug this issue.

[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O

[bredelin at ucla dot edu]

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

--- Comment #5 from bredelin at ucla dot edu 2010-10-06 15:46:08 UTC ---
This bug still existed as of Oct 4, 2010.

gcc version 4.6.0 20101004 (experimental) [trunk revision 164952] (Ubuntu
20101004-0ubuntu1) 

After this bug is fixed, I'll be able to do some more testing of 4.6 for a
large c++ program.

[Bug fortran/45910] compiler won't compile

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org 2010-10-06 15:19:53 UTC ---
The binaries from the gfortran wiki are supplied by one
or more individuals, and you'll need to contact the person
who created, because GCC does not distribute nor offer support 
for these binary distributions.  You may want to contact
fort...@gcc.gnu.org with your problem.

[Bug fortran/45910] compiler won't compile

[lawrencetinsley at hotmail dot com]

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

--- Comment #1 from Larry  2010-10-06 
15:04:59 UTC ---
I also compiled with the command gcc test.f95 -o test.exe

and saw mentioned somewhere gcc -Wall

and got the same error

[Bug fortran/45910] New: compiler won't compile

[lawrencetinsley at hotmail dot com]

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

   Summary: compiler won't compile
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lawrencetins...@hotmail.com


I tried to install gfortran MinGW build 4.6 in windows xp SP3 on a 32 bit.

I installed it in C:\Software\gfortran

and followed the instructions on

http://gcc.gnu.org/wiki/GFortranBinariesWindows

and put the correct directory (my directory) in MyComputer Properties PATH
variable.

This is what my PATH variable looks like

C:\Software\gfortran\libexec\gcc\i586-pc-mingw32\4.6.0;C:\Software\gfortran\bin

yes I have put command prompt into the directory of the file, and try to
compile a simple "hello world" program with

gfortran test.95 -o test.exe


the command returns an error of

:0:0 internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate

[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.06 14:51:02
 Ever Confirmed|0   |1

--- Comment #22 from Eric Botcazou  2010-10-06 
14:51:02 UTC ---
Investigating.

[Bug c++/45908] [C++0x] ICE involving decltype: in tree_low_cst, at tree.h:4114

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2010-10-06 
14:45:53 UTC ---
(In reply to comment #5)
> But paragraph 7 also applies (name used in a class outside a member function
> body), so the name needs to be declared before its use.

thanks, I missed that. So the testcase in comment 3 is invalid (I'll open a new
PR for the dup diagnostic)

re comment 2, is 4.5 correct to use a non-const access path to v.begin() in the
trailing-return-type?

[Bug c++/45908] [C++0x] ICE involving decltype: in tree_low_cst, at tree.h:4114

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2010-10-06 
14:35:33 UTC ---
Author: ebotcazou
Date: Wed Oct  6 14:35:25 2010
New Revision: 165031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165031
Log:
PR c++/45908
* typeck.c (cp_build_addr_expr_1): Add check for incomplete types in
code folding offsetof-like computations.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr45908.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg00457.htm
   ||l
 Resolution||FIXED

--- Comment #9 from Eric Botcazou  2010-10-06 
14:29:36 UTC ---
Presumably.