[Bug libfortran/46373] fflush called when reading from a string

[e01reynier at gmail dot com]

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

--- Comment #4 from e01reynier at gmail dot com 2010-11-09 07:54:58 UTC ---
(In reply to comment #2)

> An internal unit fflush is:

Is there really an internal unit involved when reading an integer from a string
?

[Bug libfortran/46373] fflush called when reading from a string

[e01reynier at gmail dot com]

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

--- Comment #3 from e01reynier at gmail dot com 2010-11-09 07:50:37 UTC ---
(In reply to comment #1)
> See the documentation that comes with gfortran.
> 
> You can use 
> 
> * GFORTRAN_UNBUFFERED_ALL:: Don't buffer I/O for all units.
> * GFORTRAN_UNBUFFERED_PRECONNECTED:: Don't buffer I/O for preconnected units.
> 
> to control the buffering of IO.

I try under bash with:
  export GFORTRAN_UNBUFFERED_ALL=y
or
  export GFORTRAN_UNBUFFERED_PRECONNECTED=y
but fflush is always called when I read from a string.

Anyway reading from a string has nothing to do with buffered I/O !
Why the hell is fflush called ?

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[xinliangli at gmail dot com]

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

--- Comment #18 from davidxl  2010-11-09 07:22:43 
UTC ---
PR tree-optimization/46316?  I will make the change.

Thanks,

David

On Mon, Nov 8, 2010 at 11:01 PM, ebotcazou at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316
>
> --- Comment #17 from Eric Botcazou 
> 2010-11-09 07:01:26 UTC ---
> The PR reference in the ChangeLog is wrong so no cross-link to this audit
> trail
> has been generated.  Please look at the numerous examples in the ChangeLog.
>
> The testcase should have been added to gcc.c-torture/execute instead.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  2010-11-09 
07:01:26 UTC ---
The PR reference in the ChangeLog is wrong so no cross-link to this audit trail
has been generated.  Please look at the numerous examples in the ChangeLog.

The testcase should have been added to gcc.c-torture/execute instead.

[Bug tree-optimization/46315] [4.5 Regression] gcc-4.5.1 -O2 -fno-strict-overflow causes bad code generation

[dirtyepic at gentoo dot org]

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

Ryan Hill  changed:

   What|Removed |Added

 CC||dirtyepic at gentoo dot org

--- Comment #3 from Ryan Hill  2010-11-09 04:49:54 
UTC ---
Not to rush you, but I was wondering if there will be anyone looking at this in
the near future.  I was planning on releasing 4.5.1 into the unstable branch of
our repo this week but if a patch may be soon available I'll hold off.  If
there isn't any interest I'll do the release and mask it on our hardened
profiles (which use -fno-strict-overflow by default) for now.

[Bug c++/46382] constexpr vs. static_assert in constexpr ctors

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2010-11-09 
03:54:29 UTC ---
Author: jason
Date: Tue Nov  9 03:54:24 2010
New Revision: 166471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166471
Log:
PR c++/46382
* semantics.c (check_constexpr_ctor_body): New fn.
* parser.c (cp_parser_ctor_initializer_opt_and_function_body): Call it.
* cp-tree.h: Declare it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-sassert.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46335] [C++0X] [4.6 Regression] ICE: in gimple_add_tmp_var, at gimplify.c:701

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2010-11-09 
03:54:16 UTC ---
Author: jason
Date: Tue Nov  9 03:54:12 2010
New Revision: 166470

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166470
Log:
PR c++/46335
* tree.c (bot_manip): Check TREE_SIDE_EFFECTS as well.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-defarg.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/46385] [4.6 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug libstdc++/46385] New: [4.6 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FAIL:
20_util/weak_ptr/comparison/cmp_neg.cc
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: jwakely@gmail.com


On Linux/ia32, revision 166460 gave

FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc  (test for warnings, line 467)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for excess errors)

Revision 166458 is OK. It may be caused by revision 166460:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00347.html

[Bug target/46030] registers trashed with -Os

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #2 from Alan Modra  2010-11-09 03:18:03 
UTC ---
Fixed mainline

[Bug c/46384] New: ia64-linux: internal compiler error: in get_attr_first_insn, at config/ia64/itanium2.md:1909

[dannf at dannf dot org]

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

   Summary: ia64-linux: internal compiler error: in
get_attr_first_insn, at config/ia64/itanium2.md:1909
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@dannf.org


da...@merulo:~/gmp-5.0.1+dfsg/build/mpn$ ia64-linux-gnu-gcc -v -save-temps
-std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../..
-DOPERATION_sbpi1_div_q -Wall -g -D_REENTRANT -O3 -c sbpi1_div_q.c  -fPIC -DPIC
-o .libs/sbpi1_div_q.o
Using built-in specs.
Target: ia64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-4'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --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 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc
--with-system-libunwind --enable-checking=release --build=ia64-linux-gnu
--host=ia64-linux-gnu --target=ia64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-4) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.'
'-I../../mpn' '-I..' '-D__GMP_WITHIN_GMP' '-I../..' '-DOPERATION_sbpi1_div_q'
'-Wall' '-g' '-D_REENTRANT' '-O3' '-c' '-fPIC' '-DPIC' '-o'
'.libs/sbpi1_div_q.o'
 /usr/lib/gcc/ia64-linux-gnu/4.4.5/cc1 -E -quiet -v -I. -I../../mpn -I..
-I../.. -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sbpi1_div_q -D_REENTRANT
-DPIC sbpi1_div_q.c -std=gnu99 -Wall -fPIC -g -fworking-directory -O3
-fpch-preprocess -o sbpi1_div_q.i
ignoring nonexistent directory "/usr/local/include/ia64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/ia64-linux-gnu/4.4.5/../../../../ia64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../mpn
 ..
 ../..
 /usr/local/include
 /usr/lib/gcc/ia64-linux-gnu/4.4.5/include
 /usr/lib/gcc/ia64-linux-gnu/4.4.5/include-fixed
 /usr/include/ia64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.'
'-I../../mpn' '-I..' '-D__GMP_WITHIN_GMP' '-I../..' '-DOPERATION_sbpi1_div_q'
'-Wall' '-g' '-D_REENTRANT' '-O3' '-c' '-fPIC' '-DPIC' '-o'
'.libs/sbpi1_div_q.o'
 /usr/lib/gcc/ia64-linux-gnu/4.4.5/cc1 -fpreprocessed sbpi1_div_q.i -quiet
-dumpbase sbpi1_div_q.c -auxbase-strip .libs/sbpi1_div_q.o -g -O3 -Wall
-std=gnu99 -version -fPIC -o sbpi1_div_q.s
GNU C (Debian 4.4.5-4) version 4.4.5 (ia64-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c36293eab4c31a0b95cfd1a7a0979720
sbpi1_div_q.c: In function '__gmpn_sbpi1_div_q':
sbpi1_div_q.c:292: error: unrecognizable insn:
(insn:TI 1701 1666 1727 119 (parallel [
(set (reg:DI 134 f6)
(asm_operands:DI ("xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0") ("=&f") 0 [
(reg:DI 135 f7)
(reg/v:DI 130 f2 [orig:544 dinv ] [544])
]
 [
(asm_input:DI ("f") 0)
(asm_input:DI ("f") 0)
] 367998))
(set (reg:DI 135 f7)
(asm_operands:DI ("xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0") ("=f") 1 [
(reg:DI 135 f7)
(reg/v:DI 130 f2 [orig:544 dinv ] [544])
]
 [
(asm_input:DI ("f") 0)
(asm_input:DI ("f") 0)
] 367998))
]) -1 (nil))
sbpi1_div_q.c:292: internal compiler error: in get_attr_first_insn, at
config/ia64/itanium2.md:1909
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

[bergner at gcc dot gnu.org]

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

--- Comment #17 from Peter Bergner  2010-11-09 
01:50:48 UTC ---
The patch looks good on powerpc64-linux.

=== libstdc++ Summary ===

# of expected passes16234
# of expected failures  170
# of unsupported tests  200

[Bug target/46353] [4.6 regression] fma testsuite failures

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2010-11-08 08:09:05 |2010.11.09 00:34:40
 Ever Confirmed|0   |1

--- Comment #3 from Michael Meissner  2010-11-09 
00:34:40 UTC ---
Now that the tree code knows about FMA, the rs6000 backend needs to add
fmav4df4, fmav2df4, etc. named patterns so the vectorizer can properly
vectorize calls to fma, fmas, etc.

[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #13 from Jerry DeLisle  2010-11-09 
00:25:11 UTC ---
Waiting

[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 AssignedTo|jvdelisle at gcc dot|unassigned at gcc dot
   |gnu.org |gnu.org

--- Comment #12 from Jerry DeLisle  2010-11-09 
00:24:02 UTC ---
This latest patch gets rid of the bogus unused warning.  Remaining, but not
real important is to warn on an unused namelist.  I think this will involve
marking namelists as used when resolving or translating I/O statements and then
at some point, scan for any namelists not marked.  I almost think its not worth
it, but will leave this opened until others weigh in on it.

Even if a namelist is used, a particular variable within it may not be used. 
For example, if the users nml file does not contain an assignment for a
particular variable in the list, it will remain unused.  No value in the read
operation.

[Bug tree-optimization/46383] [4.6 Regression] ICE: in get_binfo_at_offset, at tree.c:10947

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.09 00:16:18
 CC||mjambor at suse dot cz
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-09 00:16:18 
UTC ---
It is caused by revision 166192:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00078.html

[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  2010-11-09 
00:08:24 UTC ---
Author: jvdelisle
Date: Tue Nov  9 00:08:20 2010
New Revision: 166461

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166461
Log:
2010-11-08  Jerry DeLisle  

PR fortran/43899
* trans-decl.c (generate_local_decl): Do not generate unused warning
for variables in namelists.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c

[Bug tree-optimization/46383] [4.6 Regression] ICE: in get_binfo_at_offset, at tree.c:10947

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
Summary|ICE: in |[4.6 Regression] ICE: in
   |get_binfo_at_offset, at |get_binfo_at_offset, at
   |tree.c:10947|tree.c:10947

[Bug c++/45383] [4.5/4.6 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|dseketel at redhat dot com  |
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |

[Bug tree-optimization/46383] New: ICE: in get_binfo_at_offset, at tree.c:10947

[marc.glisse at normalesup dot org]

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

   Summary: ICE: in get_binfo_at_offset, at tree.c:10947
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


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

The attached C++ code compiles without optimization or with -O1 but not -O2:
bug.cpp:250:1: internal compiler error: in get_binfo_at_offset, at tree.c:10947

component chosen randomly as usual.

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org 2010-11-08 22:46:09 UTC ---
r166458 fixes comment #11 (by building the vtab early).

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 2010-11-08 22:42:41 UTC ---
Author: janus
Date: Mon Nov  8 22:42:34 2010
New Revision: 166458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166458
Log:
2010-11-08  Janus Weil  

PR fortran/46344
* decl.c (build_struct): Build vtab immediately if derived type
has already been declared.

2010-11-08  Janus Weil  

PR fortran/46344
* gfortran.dg/class_28.f03: Extended.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_28.f03

[Bug debug/45997] [4.6 Regression] __unknown__ type name for typedef'd int

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli  2010-11-08 
22:39:09 UTC ---
At some point modified_type_die is called for volatile_const_my_int with
is_volatile and is_const_type set to 0, meaning we want to emit the DIE
of the cv-unqualified version of volatile_const_my_int i.e, my_int.

The problem is that the line

  /* See if we already have the appropriately qualified variant of
 this type.  */
  qualified_type
= get_qualified_type (type,
  ((is_const_type ? TYPE_QUAL_CONST : 0)
   | (is_volatile_type ? TYPE_QUAL_VOLATILE : 0)));

fails to give us the the my_int (cv-unqualified version of
volatile_const_my_int) we want and returns NULL instead. That's because
get_qualified_type doesn't look through typedefs as it must preserve
TYPE_NAMEs (see the comment in get_qualified_type). From this point, I
think we are likely to loose.

So, maybe if we try harder to come up with the cv-unqualified version of
the input type, things will get better?

This patch that (only lightly tested seems) to fix the problem too. What
do you think?

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9bb569b..f639e24 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -12715,6 +12715,19 @@ modified_type_die (tree type, int is_const_type, int
is_volatile_type,
   ((is_const_type ? TYPE_QUAL_CONST : 0)
| (is_volatile_type ? TYPE_QUAL_VOLATILE : 0)));

+  /* If TYPE is a typedef and we want its cv-unqualified version,
+ get_qualified_type just returns NULL because it doesn't look
+ through typedefs; In that case, let's use the underlying type of
+ the typedef.  */
+  if (qualified_type == NULL
+  && typedef_variant_p (type)
+  && (is_const_type < TYPE_READONLY (type)
+  || is_volatile_type < TYPE_VOLATILE (type)))
+qualified_type =
+  get_qualified_type (DECL_ORIGINAL_TYPE (TYPE_NAME (type)),
+  ((is_const_type ? TYPE_QUAL_CONST : 0)
+   | (is_volatile_type ? TYPE_QUAL_VOLATILE : 0)));
+
   if (qualified_type == sizetype
   && TYPE_NAME (qualified_type)
   && TREE_CODE (TYPE_NAME (qualified_type)) == TYPE_DECL)

[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

[ubizjak at gmail dot com]

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

--- Comment #16 from Uros Bizjak  2010-11-08 22:20:12 
UTC ---
(In reply to comment #13)

> Patch.  Testing on x86_64-linux, testing elsewhere is appreciated.

Works OK on alphaev68-unknown-linux-gnu:

Running target unix
FAIL: 22_locale/collate/hash/char/wrapped_env.cc execution test
FAIL: 22_locale/collate_byname/named_equivalence.cc execution test
FAIL: 22_locale/ctype/is/char/2.cc execution test
FAIL: 22_locale/ctype/is/char/wrapped_env.cc execution test

=== libstdc++ Summary ===

# of expected passes7526
# of unexpected failures4
# of expected failures83
# of unsupported tests298

[Bug c++/46382] New: constexpr vs. static_assert in constexpr ctors

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr vs. static_assert in constexpr ctors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


The current implementation has the nice feature that in addition to a return
statement, a constexpr function can also contain the following:

1) typedefs
2) static_asserts

Both make sense. Hurray! However, this is different for member functions and
so-called "special member functions." In particular, constructors. Here's an
example of something that would be nice if it worked.


---


#include 

template
 struct A
  {
int _M_i;

constexpr A(int i) : _M_i(i)
{
#if BUT_WE_WANT_IT_HERE_TOO
  static_assert(std::is_fundamental<_Tp>::value, "no"); // not really
#endif
}


constexpr bool notwhatyouwant() 
{ 
  typedef _Tp type; // ok
  static_assert(std::is_fundamental<_Tp>::value, "no"); // ok
  return _M_i == 0; 
}
  };


int main()
{
  constexpr A obj(5);

  constexpr bool b = obj.notwhatyouwant();
  return 0;
}

[Bug target/44981] cfstring_format_type support needed darwin10

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #4 from mrs at gcc dot gnu.org  2010-11-08 
22:00:20 UTC ---
I'm fine with a backport, just ask Joseph to weigh in.

[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2010-11-08 21:56:58 UTC 
---
I'm now using the attached patch as a workaround, simply disabling the
lto-plugin.

[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2010-11-08 21:56:25 UTC 
---
Created attachment 22337
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22337
workaround patch

[Bug debug/46375] [4.6 Regression] -fcompare-debug failure (length) with -O -fgcse -fno-tree-dominator-opts

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.08 21:48:15
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-08 21:48:15 
UTC ---
It is caused by revision 166316:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00202.html

[Bug c++/46381] New: G++ doesn't catch duplicate members produced by template instantation

[jason at gcc dot gnu.org]

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

   Summary: G++ doesn't catch duplicate members produced by
template instantation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Core issue 996:

  template
  struct Outer {
template struct Inner;
template struct Inner {};
template struct Inner {};
  };
  Outer outer;  // #1

Here the instantiation of Outer is ill-formed, because the two
partial specializations of Inner have the same arguments, but we don't
currently give an error.

[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  2010-11-08 20:12:43 
UTC ---
> 
> But the cgraph code is messy^2 as well.  Bah.
Thanks for working on this.  Have at least rewrite of this unreachable function
removal pass
in queue for next stage1;)

Honza

[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-08 
19:57:07 UTC ---
Created attachment 22336
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22336
gcc46-pr46360.patch

Untested fix.

[Bug target/44757] lm32.md: In function ‘gen_ashlsi3’:unused variable ‘one’

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-08 19:45:59 UTC ---
Patch has been applied to trunk.

[Bug target/44757] lm32.md: In function ‘gen_ashlsi3’:unused variable ‘one’

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-11-08 19:44:47 UTC ---
Author: amylaar
Date: Mon Nov  8 19:44:42 2010
New Revision: 166451

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166451
Log:
2010-11-08  Joern Rennecke  
Richard Henderson 

PR target/44757 
* config/lm32/lm32.h (LEGITIMATE_CONSTANT_P): Call
lm32_legitimate_constant_p.
* config/lm32/lm32.md (ashlsi3): Remove unused variable.
* config/lm32/lm32.c (gen_int_relational): Make new block for
LE / LT / LEU / LTU case.  Declare variables at start of block.
(lm32_block_move_inline): Use XALLOCAVEC.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/lm32/lm32.c
trunk/gcc/config/lm32/lm32.h
trunk/gcc/config/lm32/lm32.md

[Bug tree-optimization/46351] [4.6 regression] incorrect scalarization (2)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.08 19:44:09
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Martin Jambor  2010-11-08 
19:44:09 UTC ---
Scary stuff.  I will look into it nevertheless.

[Bug tree-optimization/46380] New: vec-scal-opt*.c tests fail on hppa*-*-* (32-bit)

[danglin at gcc dot gnu.org]

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

   Summary: vec-scal-opt*.c tests fail on hppa*-*-* (32-bit)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa*-*-* (32-bit)
Target: hppa*-*-* (32-bit)
 Build: hppa*-*-* (32-bit)


FAIL: gcc.dg/vec-scal-opt.c scan-tree-dump-times veclower ">> k.[0-9_]*" 1
FAIL: gcc.dg/vec-scal-opt1.c scan-tree-dump-times veclower ">> 2" 1
FAIL: gcc.dg/vec-scal-opt2.c scan-tree-dump-times veclower ">> 2" 1

;; Function main (main)

main (int argc, char * * argv)
{
  short int D.1948;
  short int D.1947;
  short int D.1946;
  short int D.1945;
  short int D.1944;
  short int D.1943;
  short int D.1942;
  short int D.1941;
  short int D.1940;
  short int D.1939;
  short int D.1938;
  short int D.1937;
  short int D.1936;
  short int D.1935;
  short int D.1934;
  short int D.1933;
  short int D.1932;
  short int D.1931;
  short int D.1930;
  short int D.1929;
  short int D.1928;
  short int D.1927;
  short int D.1926;
  short int D.1925;
  vector(8) short int r1;
  vector(8) short int v2;
  vector(8) short int v0;
  short int D.1922;
  int D.1921;
  vector(8) short int r1.2;
  short int k.1;
  short int k.0;

:
  k.0_2 = (short int) argc_1(D);
  k = k.0_2;
  k.0_3 = (short int) argc_1(D);
  v0_4 = {k.0_3, 1, 2, 3, 4, 5, 6, 7};
  k.1_5 = k;
  k.1_6 = k;
  k.1_7 = k;
  k.1_8 = k;
  k.1_9 = k;
  k.1_10 = k;
  k.1_11 = k;
  k.1_12 = k;
  v2_13 = {k.1_12, k.1_12, k.1_12, k.1_12, k.1_12, k.1_12, k.1_12, k.1_12};
  D.1925_20 = BIT_FIELD_REF ;
  D.1926_21 = BIT_FIELD_REF ;
  D.1927_22 = D.1925_20 >> D.1926_21;
  D.1928_23 = BIT_FIELD_REF ;
  D.1929_24 = BIT_FIELD_REF ;
  D.1930_25 = D.1928_23 >> D.1929_24;
  D.1931_26 = BIT_FIELD_REF ;
  D.1932_27 = BIT_FIELD_REF ;
  D.1933_28 = D.1931_26 >> D.1932_27;
  D.1934_29 = BIT_FIELD_REF ;
  D.1935_30 = BIT_FIELD_REF ;
  D.1936_31 = D.1934_29 >> D.1935_30;
  D.1937_32 = BIT_FIELD_REF ;
  D.1938_33 = BIT_FIELD_REF ;
  D.1939_34 = D.1937_32 >> D.1938_33;
  D.1940_35 = BIT_FIELD_REF ;
  D.1941_36 = BIT_FIELD_REF ;
  D.1942_37 = D.1940_35 >> D.1941_36;
  D.1943_38 = BIT_FIELD_REF ;
  D.1944_39 = BIT_FIELD_REF ;
  D.1945_40 = D.1943_38 >> D.1944_39;
  D.1946_41 = BIT_FIELD_REF ;
  D.1947_42 = BIT_FIELD_REF ;
  D.1948_43 = D.1946_41 >> D.1947_42;
  r1.2_14 = {D.1927_22, D.1930_25, D.1933_28, D.1936_31, D.1939_34, D.1942_37,
D.1945_40, D.1948_43};
  r1 = r1.2_14;
  D.1922_15 = BIT_FIELD_REF ;
  D.1921_16 = (int) D.1922_15;
  return D.1921_16;

}

[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-11-08 
19:18:37 UTC ---
Reduced testcase (fails without any options, -Wwrite-strings is not needed):

__attribute__((gnu_inline, always_inline)) extern inline char *
strncpy (char *dest, const char *src, __SIZE_TYPE__ len)
{
  return __builtin_strncpy (dest, src, len);
}

void
foo (char *s)
{
  strncpy (s, "", 0);
}

The problem is the fold_stmt Honza added to gimplify_call_expr.  
Unfortunately fold_stmt doesn't expect it is being called when still not in SSA
form.  Seems
gimplify_and_update_call_from_tree
has been adjusted for that in PR45073, but
update_call_from_tree still needs doing that.  Will work on it tomorrow.

[Bug c++/46369] [4.6 Regression] ICE: unexpected expression '((unsigned char*)&*r)[24]' of kind bit_field_ref

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.08 19:12:04
 CC||jason at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-08 19:12:04 
UTC ---
It is introduced by revision 166167:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html

[Bug target/44758] frv.md: incompatible enum comparisons / return

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-08 19:09:25 UTC ---
Patch applied to trunk.

[Bug target/46379] New: frv.md:*movdf_nodouble+6 is nonsense

[amylaar at gcc dot gnu.org]

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

   Summary: frv.md:*movdf_nodouble+6 is nonsense
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org


(define_split
  [(set (match_operand:DF 0 "register_operand" "")
(match_operand:DF 1 "const_int_operand" ""))]

won't match.

[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Michael Meissner  2010-11-08 
19:04:23 UTC ---
Fixed in subversion id: 166448.

[Bug target/46378] Powerpc -mcpu=power5 selects FP found instructions (should use -mcpu=power5+)

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Michael Meissner  2010-11-08 
19:03:35 UTC ---
Fixed in subversion revision: 166448.

[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  2010-11-08 
19:02:39 UTC ---
Author: meissner
Date: Mon Nov  8 19:02:35 2010
New Revision: 166448

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166448
Log:
Fix PR 46378 and PR 45585

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/darwin.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug target/46378] Powerpc -mcpu=power5 selects FP found instructions (should use -mcpu=power5+)

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2010-11-08 
19:02:40 UTC ---
Author: meissner
Date: Mon Nov  8 19:02:35 2010
New Revision: 166448

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166448
Log:
Fix PR 46378 and PR 45585

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/darwin.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2010-11-08 14:53:32 |2010.11.08 19:01:20
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from H.J. Lu  2010-11-08 19:01:20 
UTC ---
It is caused by revision 165972:

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

[Bug target/46378] Powerpc -mcpu=power5 selects FP found instructions (should use -mcpu=power5+)

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.08 19:00:52
 AssignedTo|unassigned at gcc dot   |meissner at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/46378] New: Powerpc -mcpu=power5 selects FP found instructions (should use -mcpu=power5+)

[meissner at gcc dot gnu.org]

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

   Summary: Powerpc -mcpu=power5 selects FP found instructions
(should use -mcpu=power5+)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org


Created attachment 22335
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22335
Patch to fix the problem.

In my change on August 23rd, 2010 and September 2nd, 2010, I mistakenly enabled
the floating round instructions (-mfprnd) for -mcpu=power5 (ISA 2.02), while
these instructions weren't added until later (ISA 2.04, or -mcpu=power5+).  The
-mcpu=power5 option should not enable the floating point round instructions.

[Bug target/44758] frv.md: incompatible enum comparisons / return

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-11-08 18:53:00 UTC ---
Author: amylaar
Date: Mon Nov  8 18:52:51 2010
New Revision: 166447

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166447
Log:
2010-11-08  Joern Rennecke  
Richard Henderson 

PR target/44758
* config/frv/frv.md (attribute cpu): Cast value to enum attr_cpu.
(attribute acc_group): Cast value to enum attr_acc_group.
(*movdi_nodouble+6): Use gen_int_mode.
* config/frv/frv-protos.h (frv_trampoline_size): Declare no matter
if RTX_CODE is defined or not.
* config/frv/frv.c (enum frv_io_type): New enum, broken out of
struct frv_io.
(frv_handle_option): Mark parameter value with ATTRIBUTE_UNUSED.
(frv_frame_access, frv_expand_prologue): Remove unused variables.
(frv_expand_block_clear): Likewise.
(frv_trampoline_init): Use LCT_NORMAL.
(struct frv_packet_group): New struct, broken out of type of
frv_packet.
(frv_start_packet, frv_reorder_packet): Initialize group to GROUP_I,
use cast in loop counter increment.
(frv_extract_membar): Cast HOST_WIDE_INT to enum frv_io_type before
assigning to io->type.
(bdesc_set): Use rtx_code UNKNOWN in initializer.
(bdesc_1arg, bdesc_2arg, bdesc_int_void2arg): Likewise.
(bdesc_prefetches, bdesc_cut, bdesc_2argimm, bdesc_void2arg): Likewise.
(bdesc_void3arg, bdesc_voidacc, bdesc_loads, bdesc_stores): Likewise.
(frv_read_argument): Use expand_normal.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/frv/frv-protos.h
trunk/gcc/config/frv/frv.c
trunk/gcc/config/frv/frv.md

[Bug c++/45399] [C++0x] Warning for \0 in raw strings

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2010-11-08 
18:31:47 UTC ---
(In reply to comment #5)
> As you can see, I somehow believe that "\n" and "\r" are not interpreted
> correctly and replace these (should it be necessary, at least at one time it
> was?) and then added the same for chr(0) later on.

There's no need to replace newlines. There's only a need to replace nuls to
avoid a warning.  Carriage returns in the source code seem to get stripped from
the raw string.

> And the intention of a C++ feature, since when did it ever come to limit its
> use?

Agreed, I was just answering your question "What else is the purpose of raw
strings other than to contain binary blobs?"

[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jorn Wolfgang Rennecke  
2010-11-08 17:59:33 UTC ---
Patch has been applied to trunk.

[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[zsojka at seznam dot cz]

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

--- Comment #19 from Zdenek Sojka  2010-11-08 17:58:36 
UTC ---
Created attachment 22334
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22334
testcase failing in r166433

Thanks for fixing this! It seems there is one further failing testcase:

$ gcc -O -fcse-follow-jumps -fpartial-inlining -freorder-blocks
-frerun-cse-after-loop -fschedule-insns2 -fsel-sched-pipelining
-fselective-scheduling2 -funroll-loops -funswitch-loops testcase.C
testcase.C: In function 'void __fill_bvector(_Bit_iterator_base,
_Bit_iterator_base, bool)':
testcase.C:41:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7092
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46377] [4.6 regression] incorrect scalarization (3)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  2010-11-08 
17:58:19 UTC ---
Created attachment 22333
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22333
opt11.ads

[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429

[amylaar at gcc dot gnu.org]

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

--- Comment #5 from Jorn Wolfgang Rennecke  
2010-11-08 17:57:42 UTC ---
Author: amylaar
Date: Mon Nov  8 17:57:35 2010
New Revision: 166445

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166445
Log:
PR bootstrap/46358
* config/i386/i386.c (ix86_expand_split_stack_prologue):
Avoid warnings when HOST_WIDE_INT is 32 bit.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug tree-optimization/46377] [4.6 regression] incorrect scalarization (3)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  2010-11-08 
17:57:40 UTC ---
Created attachment 22332
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22332
opt11.adb

[Bug tree-optimization/46377] New: [4.6 regression] incorrect scalarization (3)

[ebotcazou at gcc dot gnu.org]

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

   Summary: [4.6 regression] incorrect scalarization (3)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org


The fix for PR tree-opt/44972 has introduced regressions in Ada, specifically:

(sra_modify_assign): Removed ref_expr_for_all_replacements_p checks,
checks for return values of build_ref_for_offset.

This is a third example, potentially a duplicate of PR tree-opt/46351, but it
can be reproduced on 32-bit targets:

e...@atlantis:~/build/gcc/native32> gcc/xgcc -Bgcc -S -O opt11.adb
+===GNAT BUG DETECTED==+
| 4.6.0 20101105 (experimental) [trunk revision 166350] (i586-suse-linux-gnu)
GCC error:|
| in build_ref_for_offset, at tree-sra.c:1345  |
| Error detected around opt11.adb:12:1   

The testcase is suitable for addition to the gnat.dg testsuite.

[Bug middle-end/46368] [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-11-08 
17:53:34 UTC ---
Reducing right now...

[Bug target/46280] [4.6 regression] Several testcases FAIL with 16byte alignment ABI warning on Solaris 8/9 x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #6 from Rainer Orth  2010-11-08 17:48:42 UTC 
---
Fixed for 4.6.0.

[Bug libfortran/46373] fflush called when reading from a string

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  2010-11-08 
17:47:14 UTC ---
An internal unit fflush is:

static int
mem_flush (unix_stream * s __attribute__ ((unused)))
{
  return 0;
}

So I don't think this is your issue.

Maybe something else?

[Bug target/46208] redundant extensions of argument registers

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2010-11-08 
17:46:31 UTC ---
> I was just looking into the same problem with MIPS too. I almost think
> TARGET_PROMOTE_PROTOTYPES in all targets be removed but that is up to each
> target maintainer.

Yes, this should make sense with sane ABIs.  But IIRC the ARM has a comment
saying that it cannot return false unconditionally.

[Bug target/46280] [4.6 regression] Several testcases FAIL with 16byte alignment ABI warning on Solaris 8/9 x86

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2010-11-08 17:44:46 UTC 
---
Author: ro
Date: Mon Nov  8 17:44:40 2010
New Revision: 166444

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166444
Log:
gcc:
* config/i386/i386.c (ix86_function_arg_boundary): Fix warning
message.

gcc/testsuite:
* gcc.dg/pr35442.c: Adapt warning.

PR target/46280
* g++.dg/eh/simd-2.C: Add -msse to dg-options, add
dg-require-effective-target sse_runtime for for i?86-*-*, x86_64-*-*.
* g++.dg/torture/pr36444.C: Add dg-options -msse for
i?86-*-* x86_64-*-*.
* g++.dg/torture/pr36445.C: Likewise.
* gcc.c-torture/compile/pr34856.c: Likewise.
* gcc.c-torture/compile/pr39928-1.c: Likewise.
* gcc.c-torture/compile/vector-1.c: Likewise.
* gcc.c-torture/compile/vector-2.c: Likewise.
* gcc.dg/pr32912-1.c: Likewise.
* gcc.c-torture/execute/va-arg-25.c: Move ...
* gcc.dg/torture/va-arg-25.c: ... here.
Add dg-do run.
Add dg-options -msse, dg-require-effective-target sse_runtime for
for i?86-*-*, x86_64-*-*.
* gcc.c-torture/execute/vector-1.c: Likewise.
* gcc.c-torture/execute/vector-2.c: Likewise.
* gcc.dg/tree-ssa/forwprop-5.c: Add -msse to dg-options for
i?86-*-*, x86_64-*-*.
* gcc.dg/tree-ssa/fre-vce-1.c: Likewise.
* gcc.dg/tree-ssa/sra-4.c: Likewise.
* gcc.dg/tree-ssa/vector-1.c: Likewise.
* gcc.dg/tree-ssa/vector-2.c: Likewise.
* gcc.target/i386/vect-args.c: Add -Wno-psabi to dg-options.

Added:
trunk/gcc/testsuite/gcc.dg/torture/va-arg-25.c
  - copied, changed from r166441,
trunk/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c
trunk/gcc/testsuite/gcc.dg/torture/vector-1.c
  - copied, changed from r166441,
trunk/gcc/testsuite/gcc.c-torture/execute/vector-1.c
trunk/gcc/testsuite/gcc.dg/torture/vector-2.c
  - copied, changed from r166441,
trunk/gcc/testsuite/gcc.c-torture/execute/vector-2.c
Removed:
trunk/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c
trunk/gcc/testsuite/gcc.c-torture/execute/vector-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/vector-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/eh/simd-2.C
trunk/gcc/testsuite/g++.dg/torture/pr36444.C
trunk/gcc/testsuite/g++.dg/torture/pr36445.C
trunk/gcc/testsuite/gcc.c-torture/compile/pr34856.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/vector-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/vector-2.c
trunk/gcc/testsuite/gcc.dg/pr32912-1.c
trunk/gcc/testsuite/gcc.dg/pr35442.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/fre-vce-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-2.c
trunk/gcc/testsuite/gcc.target/i386/vect-args.c

[Bug c++/45399] [C++0x] Warning for \0 in raw strings

[kayhayen at gmx dot de]

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

--- Comment #5 from Kay Hayen  2010-11-08 17:43:23 UTC 
---
(In reply to comment #4)
> The motivating examples in the original raw strings proposal are for
> simplifying regular expressions and HTML markup, there's no mention of binary
> blobs.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2053.html

I tend to agree that avoiding of backslashes is already something. But raw
strings are definitely also useful to store arbitrary data.

I use them in Nuitka to store the binary blobs from marshaled constants.
Currently I have to have Python code like this to do that:

def _encodeString( self, value ):
delimiter = self._pickRawDelimiter( value )

start = 'R"' + delimiter + "("
end = ")" + delimiter + '"'

result = start + value + end

# Replace \n, \r and \0 in the raw strings. The \0 gives a silly
warning from
# gcc (bug reported) and \n and \r even lead to wrong strings. Somehow
the
# parser of the C++ doesn't yet play nice with these.

def decide( match ):
if match.group(0) == "\n":
return end + r' "\n" ' + start
elif match.group(0) == "\r":
return end + r' "\r" ' + start
else:
return end + r' "\0" ' + start

result = re.sub( "\n|\r|" + chr(0), decide, result )

As you can see, I somehow believe that "\n" and "\r" are not interpreted
correctly and replace these (should it be necessary, at least at one time it
was?) and then added the same for chr(0) later on.

I consider the necessity to do each of those a bug. In my mind all it should
take would be a delimiter not present in the string. Still I am thankful for
raw strings as those are way easier to get right than a readable Python to
plain C++ string translation.

And the intention of a C++ feature, since when did it ever come to limit its
use? I admit that files with "\0" inside are not the sane thing to write. But
for me C++ is something I generate as a temporary intermediate step. Please
provide a means to disable that warning without disabling everything, or even
stop it for raw strings.

Yours,
Kay

PS: If you are interested in what I do with Nuitka, feel free to visit
http://kayhayen24x7.homelinux.org/blog/nuitka-a-python-compiler/what-is-nuitka/

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-11-08 
17:40:15 UTC ---
Created attachment 22331
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22331
gcc46-pr45894.patch

Ok, I'll bootstrapp/regtest this then.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[hjl.tools at gmail dot com]

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

--- Comment #97 from H.J. Lu  2010-11-08 17:30:36 
UTC ---
(In reply to comment #96)
> (In reply to comment #88)
> > I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
> > function '__popcountsi2' is still there, so this must be a separate issue.
> 
> I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous
> r164552.  That revision has recently been reverted, so current trunk should
> hopefully be better.

I suggest you open a bug report, if there isn't one already, and make it
depend on PR 46257 so that Bernds can double check it when he works on
the proper fix.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[mikpe at it dot uu.se]

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

--- Comment #96 from Mikael Pettersson  2010-11-08 
17:24:29 UTC ---
(In reply to comment #88)
> I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
> function '__popcountsi2' is still there, so this must be a separate issue.

I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous
r164552.  That revision has recently been reverted, so current trunk should
hopefully be better.

[Bug c++/46364] basic_string.h:541:32: internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.08 17:22:28
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.5.2
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-08 17:22:28 
UTC ---
It is caused by revision 154200:

http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00421.html

and fixed on trunk by revision 160019:

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

[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2010-11-08 17:13:24 
UTC ---
The testcase looks invalid to me:

static bitstream_init (picture_t * picture, void *start)
{
  picture->bitstream_ptr = start;
}
...
xine_xvmc_t * xvmc = bitstream_init (picture, buffer);

[Bug target/46357] Unnecessary movzx instruction

[justin.lebar+bug at gmail dot com]

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

--- Comment #2 from Justin Lebar  2010-11-08 
17:08:36 UTC ---
(In reply to comment #1)
> We always use zero/sign-extending moves to avoid partial register stalls.

Sure, but the whole instruction on line 10 is unnecessary.

[Bug lto/46376] LTO, MinGW and virtual base classes don't work together

[rodrigorivascosta at gmail dot com]

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

--- Comment #1 from Rodrigo Rivas  
2010-11-08 17:07:11 UTC ---
Sorry for the previous empty body... my dog ate my keyboard ;-)

Anyway, the following code fails when compiled with MinGW:

$ i686-mingw32msvc-g++ -v
Using built-in specs.
COLLECT_GCC=i686-mingw32msvc-g++
COLLECT_LTO_WRAPPER=/home/rodrigo/local/mingw/libexec/gcc/i686-mingw32msvc/4.6.0/lto-wrapper
Target: i686-mingw32msvc
Configured with: ../configure --prefix=/home/rodrigo/local/mingw
--target=i686-mingw32msvc --build=i686-linux --with-sysroot=/home/rodrigo/local
--enable-lto --enable-languages=c,c++,lto --enable-multilib=no
--with-system-zlib=yes --enable-threads --disable-nls --with-arch-32=i686
--disable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20101108 (experimental) (GCC) 


*** File: test.h
#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED

struct VBase
{
virtual ~VBase()
{
}
};

struct MyClass : virtual public VBase
{
};

#endif /* TEST_H_INCLUDED */

*** File: test.cpp
#include "test.h"

int main()
{
MyClass x;
return 0;
}

*** File: foo.cpp
#include "test.h"

int main()
{
MyClass x;
return 0;
}

*** File: bar.cpp
#include "test.h"

int bar()
{
MyClass x;
return 0;
}


$ i686-mingw32msvc-g++ -flto *.cpp
test.h:11:8: error: '_ZTv0_n12_N7MyClassD1Ev' has already been defined
test.h:11:8: note: previously defined here
test.h:11:8: error: '_ZTv0_n12_N7MyClassD0Ev' has already been defined
test.h:11:8: note: previously defined here
lto-wrapper: i686-mingw32msvc-g++ returned 1 exit status
collect2: lto-wrapper returned 1 exit status

However, with a native build of the exactly same GCC revision it compiles and
links correctly.

This *may* be a duplicate of Bug 45343.

Regards.
Rodrigo

[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed

[abel at gcc dot gnu.org]

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

--- Comment #1 from Andrey Belevantsev  2010-11-08 
17:05:38 UTC ---
Sorry, I have checked that the test doesn't ICE but missed the additional
warnings.  How about the below patch, do you think it makes sense?  I have
verified that the test still ICEs without the PR45352 patch.

Index: gcc/testsuite/gcc.target/i386/pr45352-2.c
===
--- gcc/testsuite/gcc.target/i386/pr45352-2.c   (revision 166441)
+++ gcc/testsuite/gcc.target/i386/pr45352-2.c   (working copy)
@@ -55,7 +55,7 @@
 picture->f_motion.ref
   [0]
   [0]
-  = forward_reference_frame->base + (offset ? picture->pitches[0] : 0);
+  = (char) (long) (forward_reference_frame->base + (offset ?
picture->pitches[0] : 0));
   picture->f_motion.ref[0][1] = (offset);
   if (picture->picture_structure)
   picture->pitches[0] <<= picture->pitches[1] <<= 1;
@@ -90,7 +90,7 @@
 mpeg2_xvmc_slice
   (mpeg2dec_accel_t * accel, picture_t * picture, int code, uint8_t buffer,int
mba_inc)
 {
-  xine_xvmc_t * xvmc = bitstream_init (picture, buffer);
+  xine_xvmc_t * xvmc = (xine_xvmc_t *) (long) bitstream_init (picture, (void
*) (long) buffer);
   slice_xvmc_init (picture, code);
 while (1)
   {

[Bug libfortran/46373] fflush called when reading from a string

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.11.08 17:05:08
 CC||kargl at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org 2010-11-08 17:05:08 UTC ---
See the documentation that comes with gfortran.

You can use 

* GFORTRAN_UNBUFFERED_ALL:: Don't buffer I/O for all units.
* GFORTRAN_UNBUFFERED_PRECONNECTED:: Don't buffer I/O for preconnected units.

to control the buffering of IO.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #95 from dave at hiauly1 dot hia.nrc.ca 2010-11-08 17:00:41 UTC ---
>   CC  fs/ioctl.o
> fs/ioctl.c: In function 'do_vfs_ioctl':
> fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877
> Please submit a full bug report,

Here is full compile command:

hppa64-linux-gnu-gcc -Wp,-MD,fs/.ioctl.o.d  -nostdinc -isystem
/home/dave/opt/gnu/gcc64/lib/gcc/hppa64-linux-gnu/4.6.0/include
-I/home/dave/linux/linux-2.6.36.y/arch/parisc/include -Iinclude  -include
include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -O2 -pipe -mno-space-regs -mfast-indirect-calls
-mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000
-Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(ioctl)"  -D"KBUILD_MODNAME=KBUILD_STR(ioctl)"  -c
-o fs/ioctl.o fs/ioctl.c

Attached preprocessed source.

[Bug lto/46376] New: LTO, MinGW and virtual base classes don't work together

[rodrigorivascosta at gmail dot com]

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

   Summary: LTO, MinGW and virtual base classes don't work
together
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rodrigorivasco...@gmail.com

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2010-11-08 
16:39:39 UTC ---
Created attachment 22329
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22329
gcc46-pr43808-2.patch

Another possible fix (also untested).

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  2010-11-08 
16:38:55 UTC ---
Created attachment 22328
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22328
gcc46-pr43808-1.patch

One possible fix (so far untested).

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[danglin at gcc dot gnu.org]

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

--- Comment #94 from John David Anglin  2010-11-08 
16:39:09 UTC ---
In doing a 2.6.36 kernel build with

d...@mx3210:~/opt/gnu/gcc64/bin$ ./hppa64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./hppa64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/dave/opt/gnu/gcc64/libexec/gcc/hppa64-linux-gnu/4.6.0/lto-wrapper
Target: hppa64-linux-gnu
Configured with: ../gcc/configure --with-gnu-as
--with-as=/usr/bin/hppa64-linux-gnu-as --with-gnu-ld
--with-ld=/usr/bin/hppa64-linux-gnu-ld --disable-shared --disable-nls
--prefix=/home/dave/opt/gnu/gcc64 --disable-threads --disable-target-libiberty
--disable-libmudflap --disable-libssp --build=hppa-linux-gnu
--host=hppa-linux-gnu --target=hppa64-linux-gnu --enable-languages=c
--disable-bootstrap
Thread model: single
gcc version 4.6.0 20101108 (experimental) [trunk revision 166433] (GCC)

I get the following assertion failure:

  CC  fs/ioctl.o
fs/ioctl.c: In function 'do_vfs_ioctl':
fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877
Please submit a full bug report,

[Bug fortran/45636] Failed to fold simple Fortran string

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from Steve Ellcey  2010-11-08 16:08:19 
UTC ---
The mempcpy is not inlined with -Os.  Presumbably because that would increase
the size of the resulting object.

[Bug target/46208] redundant extensions of argument registers

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2010-11-08 
16:04:18 UTC ---
(In reply to comment #4)
> * config/sparc/sparc.c (TARGET_PROMOTE_PROTOTYPES): Delete.

I was just looking into the same problem with MIPS too. I almost think
TARGET_PROMOTE_PROTOTYPES in all targets be removed but that is up to each
target maintainer.

[Bug debug/46375] New: [4.6 Regression] -fcompare-debug failure (length) with -O -fgcse -fno-tree-dominator-opts

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] -fcompare-debug failure (length) with
-O -fgcse -fno-tree-dominator-opts
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fgcse -fno-tree-dominator-opts -fcompare-debug -O pr46375.c 
gcc: error: pr46375.c: -fcompare-debug failure (length)
$ diff pr46375.*gkd
53a54
> (code_label 5 0 0 5 "" [0 uses])

Tested revisions:
r166414 - fail
r165699 - OK
4.5 r165781 - OK

[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #3 from Sebastian Pop  2010-11-08 15:49:36 
UTC ---
Mine.

[Bug c/46374] Add nooverflow attribute

[lfsxs0 at gmail dot com]

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

--- Comment #2 from Luís Fernando Schultz Xavier da Silveira  2010-11-08 15:48:47 UTC ---
(In reply to comment #1)
> That code is really:
> bool
> f (uint16_t x, uint16_t y)
> {
>   return ((int)x) + 8 == ((int)y) - 17;
> }

I am very sorry. I forgot the implicit conversion rules.

Please consider:

bool
f (uint16_t x, uint16_t y)
{
  x+= 8;
  y-= 17;
  return x == y;
}

[Bug c/46374] Add nooverflow attribute

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-11-08 
15:41:30 UTC ---
That code is really:
bool
f (uint16_t x, uint16_t y)
{
  return ((int)x) + 8 == ((int)y) - 17;
}


--- CUT ---
There should be no zero extends in that code because the ABI requires them to
be zero extended already.  If there is then that is the bug and really a
nooverflow attribute is not required there.

[Bug target/46372] format '%f' expects type 'double', but argument 3 has type 'float'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2010-11-08 
15:39:05 UTC ---
This is a dup of the older bug 35649 which some other targets have the same
issue.

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

[Bug c/35649] Incorrect printf warning: expect double has float

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||corsepiu at gcc dot gnu.org

--- Comment #10 from Andrew Pinski  2010-11-08 
15:39:05 UTC ---
*** Bug 46372 has been marked as a duplicate of this bug. ***

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2010-11-08 
15:38:21 UTC ---
Ah,
  if (optimize)
update_alias_info_with_stack_vars ();
explains that.  Guess it should be if (optimize || ...).
if (optimize || flag_strict_aliasing) would work for this testcase, but not
sure
if things still wouldn't break for -O0 -fschedule-insns or similar.

[Bug c/46374] New: Add nooverflow attribute

[lfsxs0 at gmail dot com]

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

   Summary: Add nooverflow attribute
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lfs...@gmail.com


When representing a small width unsigned integer in a larger width register,
the compiler has to clear the upper bits of the register before many
expressions, notably shift rights and comparisons. Consider the additional
instructions that have to be inserted in the following code, as opposed to a
signed version in a cpu that always passes parameters in full registers, such
as the ARM.

bool
f (uint16_t x, uint16_t y)
{
  return x + 8 == y - 17;
}

It would be helpful if the compiler provided something such as a type attribute
nooverflow that would indicate no overflow involving values of the
corresponding unsigned type may occur. This way, not only this problem is
solved, but optimizations analogous to the ones involving signed values would
apply to these unsigned ones (such as turning for (i = 1; i != 0; ++i) into an
infinite loop).

I respect you possible decision to ignore this report. This is a mere
suggestion. Also, if you consider this a bad idea, please explain why.

Thank you for your attention.

[Bug libfortran/46373] New: fflush called when reading from a string

[e01reynier at gmail dot com]

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

   Summary: fflush called when reading from a string
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e01reyn...@gmail.com


When reading a integer from a string (ie READ(string,'(I3)') number) it calls
fflush from flush_if_preconnected routine inside data_transfer_init routine.
It causes me trouble in a C thread waiting for keyboard calling getc.
Is there a valid reason for calling fflush while reading a string ?

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Guenther  2010-11-08 
15:35:38 UTC ---
I will still have a look.

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2010-11-08 
15:32:03 UTC ---
(In reply to comment #6)
> Indeed, for
> x:
> (mem/s:DI (reg/f:DI 117 [ D.1692 ]) [6 MEM[(struct a[2] *)D.1692_63]+0 S8 
> A64])
> mem:
> (mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
> (const_int -384 [0xfe80])) [3 D.1548.i.data+0 S8 A64])
> rtx_refs_may_alias_p (x, mem, 0)
> returns 0.
> indirect_ref_may_alias_decl_p is called with base1 the MEM_REF and base2
> VAR_DECL D.1548.
> 
> And the problem is that may_be_aliased is false for D.1548.  Sure, it doesn't
> have address taken.  But as expansion decided to share its slot together with
> other variables and those are may_be_aliased, this of course breaks.
> 
> I wonder whether expansion shouldn't somehow make sure that if at least one 
> var
> in the partition is may_be_aliased, all of them are.  Be it by not merging 
> vars
> that have different may_be_aliased, or by say marking the non-addressable vars
> TREE_ADDRESSABLE if anything in the partition is addressable.
> 
> Richard?

We do this already, see cfgexpand.c:add_partitioned_vars_to_ptset and
update_alias_info_with_stack_vars and alias.c:ao_ref_from_mem:

  /* If this is a reference based on a partitioned decl replace the
 base with an INDIRECT_REF of the pointer representative we
 created during stack slot partitioning.  */
  if (TREE_CODE (base) == VAR_DECL
  && ! TREE_STATIC (base)
  && cfun->gimple_df->decls_to_pointers != NULL)
{
  void *namep;
  namep = pointer_map_contains (cfun->gimple_df->decls_to_pointers, base);
  if (namep)
ref->base = build_simple_mem_ref (*(tree *)namep);
}

and we try to handle this particular case in update_alias_info_with_stack_vars:

  /* Make all points-to sets that contain one member of a partition
 contain all members of the partition.  */
  if (decls_to_partitions)
{
  unsigned i;
  struct pointer_set_t *visited = pointer_set_create ();
  bitmap temp = BITMAP_ALLOC (NULL);

  for (i = 1; i < num_ssa_names; i++)
{
...


So you say that for some reason this doesn't work.

[Bug middle-end/46368] [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2010-11-08 
15:27:33 UTC ---
I'll look at this.

[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-11-08 
15:21:41 UTC ---
Indeed, for
x:
(mem/s:DI (reg/f:DI 117 [ D.1692 ]) [6 MEM[(struct a[2] *)D.1692_63]+0 S8 A64])
mem:
(mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -384 [0xfe80])) [3 D.1548.i.data+0 S8 A64])
rtx_refs_may_alias_p (x, mem, 0)
returns 0.
indirect_ref_may_alias_decl_p is called with base1 the MEM_REF and base2
VAR_DECL D.1548.

And the problem is that may_be_aliased is false for D.1548.  Sure, it doesn't
have address taken.  But as expansion decided to share its slot together with
other variables and those are may_be_aliased, this of course breaks.

I wonder whether expansion shouldn't somehow make sure that if at least one var
in the partition is may_be_aliased, all of them are.  Be it by not merging vars
that have different may_be_aliased, or by say marking the non-addressable vars
TREE_ADDRESSABLE if anything in the partition is addressable.

Richard?

[Bug target/46372] New: format '%f' expects type 'double', but argument 3 has type 'float'

[corsepiu at gcc dot gnu.org]

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

   Summary: format '%f' expects type 'double', but argument 3 has
type 'float'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: corse...@gcc.gnu.org


I am facing the warning from the subject when compiling this snippet below with
avr-*gcc's:

-- snip --
#include 

int main()
{
  float f = 2.0;
  fprintf( stdout, "%f\n", f );
}
-- snip --

# avr-rtems4.10-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6: warning: format '%f' expects type 'double', but argument 3 has type
'float'

#  avr-rtems4.10-gcc --version
avr-rtems4.10-gcc (GCC) 4.4.5 20101001 (RTEMS
gcc-4.4.5-2.fc13/newlib-1.18.0-17.fc13)



# avr-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6:3: warning: format '%f' expects type 'double', but argument 3 has type
'float'

# avr-gcc --version
avr-gcc (Fedora 4.5.1-2.fc13) 4.5.1

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

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] SELECT TYPE: scalar coarray variable is rejected
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: do...@gcc.gnu.org


Example has been taken from the interpretation request at
http://j3-fortran.org/doc/meeting/193/10-209r1.txt ; the IR does not contain a
suggested edits.

The following program, which needs two images at run time is regarded as valid
(with select 1 commented out) - if the ALLOCATE is not commented out. (The
ALLOCATE statement is commented-out because of PR 46370.)


Using gfortran -fcorarray=single, it fails with:

select type(o_foo)! 3 VALID
   1
Error: Selector in SELECT TYPE at (1) is not a named variable; use
associate-name=>


module m
  type :: foo
integer :: i = 0
  end type
end module m
program p
  use m
  type(foo), allocatable :: o_foo[:]
  integer :: j

!  allocate(foo :: o_foo[*])
  if (this_image() == 1) then

!select type(a => o_foo[2])! 1 INVALID
!  type is(foo)
!  j = a%i
!end select

!select type(a => o_foo)   ! 2 VALID
!  type is(foo)
!  j = a[2]%i
!   end select

select type(o_foo)! 3 VALID
  type is(foo)
  j = o_foo[2]%i
end select

  end if
end program p

[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever Confirmed|1   |0

[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-08 
15:02:02 UTC ---
Created attachment 22326
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22326
preprocessed source

Hm, it seems initial attachment doesn't work.

[Bug fortran/46370] New: [OOP] ALLOCATE: Error allocating CLASS coarrays

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] ALLOCATE: Error allocating CLASS coarrays
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Based on the test case at http://j3-fortran.org/doc/meeting/193/10-209r1.txt

The following program (compile with "-fcoarray=single") is rejected with:

allocate (t :: a[*])
 1
Error: Unexpected coarray designator at (1)


It works with TYPE instead of CLASS.

type t
end type t
class(t), allocatable :: a[:]
allocate (t :: a)
end

[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.11.08 14:53:32
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-08 14:53:32 
UTC ---
Please provide expproc.ii.

[Bug c++/46369] [4.6 Regression] ICE: unexpected expression '((unsigned char*)&*r)[24]' of kind bit_field_ref

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug c++/46369] New: [4.6 Regression] ICE: unexpected expression '((unsigned char*)&*r)[24]' of kind bit_field_ref

[rguenth at gcc dot gnu.org]

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

   Summary: [4.6 Regression] ICE: unexpected expression
'((unsigned char*)&*r)[24]' of kind bit_field_ref
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: i?86-*-linux


Created attachment 22325
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22325
preprocessed source

The package yast2-hardware-detection-2.17.1 fails with

> ./cc1plus  -quiet ~/HwParse.ii -m32 -std=c++0x
HwParse.cc: In member function 'YCPMap HwProbe::resource_type2map(const
res_any_t*, const char**)':
HwParse.cc:219:71: internal compiler error: unexpected expression '((unsigned
char*)&*r)[24]' of kind bit_field_ref
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.08 14:50:25
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-08 14:50:25 
UTC ---
It is caused by revision 164438:

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