[Bug rtl-optimization/44013] [4.5 Regression] VTA produces wrong code

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-06-07 07:16 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|VTA produces wrong code |[4.5 Regression] VTA
   ||produces wrong code


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

[Bug c/44438] New: ISO C99 6.7.4p3 not obeyed in C99 mode

[nickc at redhat dot com]

Section 6.7.4 paragraph 3 of the ISO C99 standard states that:

An inline definition of a function with external
linkage ... shall not contain a reference to an identifier with
internal linkage.

GCC has code to check for this condition, but it does not work in C99 mode.

Reproduce by:

  % cat iso-c99-test.c
  static int a = 7;
  extern inline int foo (void) { return a; }
  int main (void) { return foo (); }

  % gcc -c iso-c99-test.c
  iso-c99-test.c:2:39: warning: 'a' is static but used in inline function 'foo'
which is not static [enabled by default]

  % gcc -c -std=c99 iso-c99-test.c
  %


-- 
   Summary: ISO C99 6.7.4p3 not obeyed in C99 mode
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #14 from sfilippone at uniroma2 dot it  2010-06-07 08:26 ---
(In reply to comment #13)
> The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this
> one can be closed.
> 
The attached variation of generic_23 still does not work. 

[sfili...@donald bug15]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20100606 (experimental) (GCC) 
[sfili...@donald bug15]$ gfortran -o generic_23_1 generic_23_1.f03
[sfili...@donald bug15]$ ./generic_23_1 
 FOO%DOIT base version
Abortito


-- 


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[sfilippone at uniroma2 dot it]

--- Comment #15 from sfilippone at uniroma2 dot it  2010-06-07 08:27 ---
Created an attachment (id=20853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853&action=view)
test case


-- 


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[rguenth at gcc dot gnu dot org]

--- Comment #38 from rguenth at gcc dot gnu dot org  2010-06-07 08:39 
---
*** Bug 44437 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jay dot krell at cornell dot
   ||edu


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

[Bug bootstrap/44437] 4.5 bootstrap failure on powerpc-linux

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-07 08:39 ---
Use STAGE1_CFLAGS="-O -g".

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/44439] New: Configure states wrong required versions for GMP, MPFR, and MPC

[singler at kit dot edu]

In case of wrong prerequisite versions, configure says

Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+

but the prerequisites page  says

GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
MPFR Library version 2.4.2 (or later)
MPC Library version 0.8.1 (or later)

which is apparently more correct.  This could cause some installation
headaches.


-- 
   Summary: Configure states wrong required versions for GMP, MPFR,
and MPC
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at kit dot edu


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

[Bug middle-end/44440] New: ira_initialization and buitins construction taking too much of startup time

[hubicka at gcc dot gnu dot org]

Hi,
oprofiling compilation of empty file I get:
4831959.8126  no-vmlinux   /no-vmlinux
3057  3.7842  ld-2.11.1.so do_lookup_x
2935  3.6331  libc-2.11.1.so   memset
2921  3.6158  ld-2.11.1.so _dl_relocate_object
1589  1.9670  as   /usr/bin/as
1270  1.5721  ld-2.11.1.so _dl_lookup_symbol_x
953   1.1797  cc1  ggc_alloc_stat
671   0.8306  libc-2.11.1.so   _int_malloc
610   0.7551  ld-2.11.1.so strcmp
595   0.7365  cc1  ira_init
594   0.7353  libc-2.11.1.so   strlen
493   0.6103  cc1  add_builtin_function_common.147729
491   0.6078  cc1  decl_attributes
483   0.5979  libc-2.11.1.so   memcpy
452   0.5595  libc-2.11.1.so   strcmp
446   0.5521  cc1  init_reg_sets_1.190433
400   0.4951  cc1  pop_scope

It is a lot of dynamic linking. Porifling cc1 binary only it is:
953   8.2525  ggc_alloc_stat
595   5.1524  ira_init
493   4.2691  add_builtin_function_common.147729
491   4.2518  decl_attributes
446   3.8621  init_reg_sets_1.190433
400   3.4638  pop_scope
387   3.3512  ix86_hard_regno_mode_ok
362   3.1347  c_write_global_declarations_1.9246.5242
357   3.0914  do_multiply.182320
328   2.8403  do_add.182279
302   2.6152  rtx_cost
293   2.5372  make_node_stat
258   2.2342  ix86_memory_move_cost.386116.7474
256   2.2168  do_divide.182325
255   2.2082  ht_lookup_with_hash
236   2.0436  ix86_rtx_costs.386572.6577
231   2.0003  bind.9267
223   1.9311  normalize.182203
212   1.8358  iterative_hash
194   1.6799  recog
176   1.5241  htab_find_with_hash
168   1.4548  tree_code_size
167   1.4461  def_builtin_1.17388.constprop.16.4002
132   1.1431  copy_node_stat
125   1.0824  is_attribute_with_length_p._part.7.371469
940.8140  debug_nothing_tree
900.7794  main
880.7620  build_int_cst_wide
800.6928  c_builtin_function

I guess especially ira initialization can be esially done lazilly on demand
like we I for regclass some time ago? The may_move_*_costs can be computed when
needed for given mode first time.
Note that this is LTO build, so ira_init gets cross module inlining of
functions called once into it.

Honza


-- 
   Summary: ira_initialization and buitins construction taking too
much of startup time
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at kit dot edu]

--- Comment #11 from singler at kit dot edu  2010-06-07 09:35 ---
Obviously, I'm not the only one having this problem, Jason has patched
libstdc++-v3/testsuite/util/testsuite_abi.h in the meantime.


r160313 | jason | 2010-06-05 15:13:46 +0200 (Sat, 05 Jun 2010) | 1 line

* testsuite/util/testsuite_abi.h: Work around glibc BZ 9694.

+// Include stddef now to work around glibc BZ 9694
+#include 

related to



This solves the problem testsuite_abi.h, but then, the next test fails, namely
testsuite_allocator.h.

I have tested all that using a different user ID, with a completely clean
environment and new checkout, but the problem persists.


-- 

singler at kit dot edu changed:

   What|Removed |Added

 CC||jason at redhat dot com
 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-06-07 09:41 ---
(In reply to comment #14)
> The attached variation of generic_23 still does not work. 
> 
> [sfili...@donald bug15]$ ./generic_23_1 
>  FOO%DOIT base version
 Aborted (core dumped)

(In reply to comment #15)
> Created an attachment (id=20853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853&action=view) [edit]

REOPEN as the issue of the attachment is different from PR 44434; it uses
allocatable scalars and might be thus yet another problem.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug target/44364] Wrong code with e500 double floating point

[amodra at gmail dot com]

--- Comment #25 from amodra at gmail dot com  2010-06-07 09:53 ---
Yes it seems the patch is not sufficient on 4.4.  On mainline the code looks
good by inspection.  (I don't have e500 hardware to run tests on.)


-- 


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

[Bug c/44438] ISO C99 6.7.4p3 not obeyed in C99 mode

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2010-06-07 09:54 ---
That's not an "inline definition", so that constraint does not apply.

If all of the file scope declarations for a function in a translation
unit include the inline function specifier without extern, then the
definition in that translation unit is an inline definition.

(6.7.4#6)


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-06-07 10:09 
---
Yes, it's a glibc bug (I don't have available any machine using that old
glibc), and if you look at the mailing list, I already commented that could be
related to your issue. I think we should use the same workaround for that other
testsuite header and closw this sucker. Any patch along these lines is
pre-approved, in any case I would not be able to test it.


-- 


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

[Bug bootstrap/44439] Configure states wrong required versions for GMP, MPFR, and MPC

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-07 10:13 ---
Prerequesites states the recommended versions, configure only tests the
minimal required versions.  The inconsistency is "ok".


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2010-06-07 10:18 
---
As a matter of fact, in testsuite_allocator.h the problem can be solved much
more cleanly by simply qualifying with std:: the size_t and ptrdiff_t in tge
second half of the file, I can do that later today. 


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[amodra at gmail dot com]

--- Comment #26 from amodra at gmail dot com  2010-06-07 10:29 ---
Doh!  No, it's still broken on mainline too.  I wasn't testing what I thought I
was...


-- 


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

[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime

[iains at gcc dot gnu dot org]

--- Comment #14 from iains at gcc dot gnu dot org  2010-06-07 10:45 ---
closing after back-porting to 4.5;
 if anyone feels passionately about a merge to 4.4 ... they can re-open.


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/44159] CPU options cause testsuite failures

[ktietz at gcc dot gnu dot org]

--- Comment #2 from ktietz at gcc dot gnu dot org  2010-06-07 10:57 ---
Subject: Bug 44159

Author: ktietz
Date: Mon Jun  7 10:56:44 2010
New Revision: 160363

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160363
Log:
2010-06-07  Kai Tietz  

PR target/44159
* gcc.target/i386/abi-2.c: Check sysv abi here.
* gcc.target/i386/aes-avx-check.h: Call test in noinline
function to avoid failures by different ABIs.
* gcc.target/i386/aes-check.h: Likewise.
* gcc.target/i386/avx-check.h: Likewise.
* gcc.target/i386/fma4-check.h: Likewise.
* gcc.target/i386/mmx-3dnow-check.h: Likewise.
* gcc.target/i386/mmx-check.h: Likewise.
* gcc.target/i386/pclmul-avx-check.h: Likewise.
* gcc.target/i386/pclmul-check.h: Likewise.
* gcc.target/i386/sse-check.h: Likewise.
* gcc.target/i386/sse2-check.h: Likewise.
* gcc.target/i386/sse3-check.h: Likewise.
* gcc.target/i386/sse4_1-check.h: Likewise.
* gcc.target/i386/sse4_2-check.h: Likewise.
* gcc.target/i386/sse4a-check.h: Likewise.
* gcc.target/i386/ssse3-check.h: Likewise.
* gcc.target/i386/xop-check.h: Likewise.
* gcc.target/i386/pr27971.c: Fix for LLP64.
* gcc.target/i386/pr39139.c: Likewise.
* gcc.target/i386/pr39315-check.c: Likewise.
* gcc.target/i386/vararg-1.c: Likewise.
* gcc.target/i386/vararg-2.c: Likewise.
Additional add dg-compile to avoid failure due
missing foo symbol.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/abi-2.c
trunk/gcc/testsuite/gcc.target/i386/aes-avx-check.h
trunk/gcc/testsuite/gcc.target/i386/aes-check.h
trunk/gcc/testsuite/gcc.target/i386/avx-check.h
trunk/gcc/testsuite/gcc.target/i386/fma4-check.h
trunk/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h
trunk/gcc/testsuite/gcc.target/i386/mmx-check.h
trunk/gcc/testsuite/gcc.target/i386/pclmul-avx-check.h
trunk/gcc/testsuite/gcc.target/i386/pclmul-check.h
trunk/gcc/testsuite/gcc.target/i386/pr27971.c
trunk/gcc/testsuite/gcc.target/i386/pr39139.c
trunk/gcc/testsuite/gcc.target/i386/pr39315-check.c
trunk/gcc/testsuite/gcc.target/i386/sse-check.h
trunk/gcc/testsuite/gcc.target/i386/sse2-check.h
trunk/gcc/testsuite/gcc.target/i386/sse3-check.h
trunk/gcc/testsuite/gcc.target/i386/sse4_1-check.h
trunk/gcc/testsuite/gcc.target/i386/sse4_2-check.h
trunk/gcc/testsuite/gcc.target/i386/sse4a-check.h
trunk/gcc/testsuite/gcc.target/i386/ssse3-check.h
trunk/gcc/testsuite/gcc.target/i386/vararg-1.c
trunk/gcc/testsuite/gcc.target/i386/vararg-2.c
trunk/gcc/testsuite/gcc.target/i386/xop-check.h


-- 


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

[Bug libstdc++/44441] New: std::getline set failbit in situation when shouldn't

[qwak82 at gmail dot com]

In this code s failbit is set if last line in s is empty (stream ends with
\n\n):
std::istream s;
//s is some kind of input stream like std::istringstream s("\n\n");
while (s.good()) {
 std::string line;
 std::getline(s, line);
}


-- 
   Summary: std::getline set failbit in situation when shouldn't
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qwak82 at gmail dot com
  GCC host triplet: ubuntu linux x86-64


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

[Bug testsuite/44159] CPU options cause testsuite failures

[ktietz at gcc dot gnu dot org]

--- Comment #3 from ktietz at gcc dot gnu dot org  2010-06-07 11:09 ---
Subject: Bug 44159

Author: ktietz
Date: Mon Jun  7 11:08:46 2010
New Revision: 160365

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160365
Log:
2010-06-07  Kai Tietz  

Backport from mainline:
PR target/44159
* gcc.target/i386/abi-2.c: Check sysv abi here.
* gcc.target/i386/aes-avx-check.h: Call test in noinline
function to avoid failures by different ABIs.
* gcc.target/i386/aes-check.h: Likewise.
* gcc.target/i386/avx-check.h: Likewise.
* gcc.target/i386/fma4-check.h: Likewise.
* gcc.target/i386/mmx-3dnow-check.h: Likewise.
* gcc.target/i386/mmx-check.h: Likewise.
* gcc.target/i386/pclmul-avx-check.h: Likewise.
* gcc.target/i386/pclmul-check.h: Likewise.
* gcc.target/i386/sse-check.h: Likewise.
* gcc.target/i386/sse2-check.h: Likewise.
* gcc.target/i386/sse3-check.h: Likewise.
* gcc.target/i386/sse4_1-check.h: Likewise.
* gcc.target/i386/sse4_2-check.h: Likewise.
* gcc.target/i386/sse4a-check.h: Likewise.
* gcc.target/i386/ssse3-check.h: Likewise.
* gcc.target/i386/xop-check.h: Likewise.
* gcc.target/i386/pr27971.c: Fix for LLP64.
* gcc.target/i386/pr39139.c: Likewise.
* gcc.target/i386/pr39315-check.c: Likewise.
* gcc.target/i386/vararg-1.c: Likewise.
* gcc.target/i386/vararg-2.c: Likewise.
Additional add dg-compile to avoid failure due
missing foo symbol.

* gcc.dg/compound-literal-1.c: Fix for llp64.
* gcc.dg/pr32370.c: Likewise.
* gcc.dg/pr37561.c: Likewise.
* gcc.dg/pr41340.c: Likewise.
* gcc.dg/pr41551.c: Likewise.


Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/compound-literal-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr32370.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr37561.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr41340.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr41551.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/abi-2.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/aes-avx-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/aes-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/fma4-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/mmx-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pclmul-avx-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pclmul-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr27971.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr39139.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr39315-check.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse2-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse3-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4_1-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4_2-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4a-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/ssse3-check.h
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/vararg-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/vararg-2.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/xop-check.h


-- 


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

[Bug testsuite/44159] CPU options cause testsuite failures

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2010-06-07 11:09 ---
Fixed an 4.5 branch and on mainline.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2010-06-07 11:19 ---
You are getting eof.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

--- Comment #4 from kazu at gcc dot gnu dot org  2010-06-07 11:35 ---
Posted a patch.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||06/msg00514.html


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

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

[qwak82 at gmail dot com]

--- Comment #2 from qwak82 at gmail dot com  2010-06-07 11:36 ---
But also fail bit, this program prints:
line: a  //this is OK, first line
line://this is also OK, second (empty) line
fail bit //eof is set - OK; but fail bit should be set here?

#include 
#include 

int main() {
std::istringstream s("a\n");
while (s.good()) {
 std::string line;
 std::getline(s, line);
 std::cout << "line: " << line << std::endl;
}
if (s.fail()) std::cout << "fail bit";
return 0;
}


-- 


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

[Bug fortran/44442] New: Useless temporary with RESHAPE

[dominiq at lps dot ens dot fr]

While playing with -Warray-temporaries, I noticed that the warning is emitted
twice for RESHAPE as illustrated by the following example:

[macbook] f90/bug% cat pr36928_red.f90
! { dg-do compile }
! { dg-options "-Warray-temporaries" }
! PR 36928 - optimize array interleaving array temporaries
program main
  integer :: i, m, n
  real, dimension(4,5) :: b
  real, dimension(5,4) :: c
  b = reshape([(i, i=1,20)],[4,5])
  m = 5
  n = 4
  c = reshape(b, [m,n])
end program main
[macbook] f90/bug% gfc -Warray-temporaries pr36928_red.f90
pr36928_red.f90:11.17:

  c = reshape(b, [m,n])
 1
Warning: Creating array temporary at (1)
pr36928_red.f90:11.17:

  c = reshape(b, [m,n])
 1
Warning: Creating array temporary at (1)

(see the polyhedron test capacita.f90 for "real life" code). If I read
correctly the dump

...
  atmp.3.dtype = 265;
  atmp.3.dim[0].stride = 1;
  atmp.3.dim[0].lbound = 0;
  atmp.3.dim[0].ubound = 1;
  atmp.3.data = (void * restrict) &A.4;
  atmp.3.offset = 0;
  (*(integer(kind=4)[2] * restrict) atmp.3.data)[0] = m;
  (*(integer(kind=4)[2] * restrict) atmp.3.data)[1] = n;
  atmp.6.dtype = 521;
  atmp.6.dim[0].stride = 1;
  atmp.6.dim[0].lbound = 0;
  atmp.6.dim[0].ubound = 1;
  atmp.6.data = (void * restrict) &A.7;
  atmp.6.offset = 0;
  {
integer(kind=8) S.8;

S.8 = 0;
while (1)
  {
if (S.8 > 1) goto L.1;
(*(integer(kind=8)[2] * restrict) atmp.6.data)[S.8] =
(integer(kind=8)) (*(integer(kind=4)[2] * restrict) atmp.3.data)[S.8];
S.8 = S.8 + 1;
  }
L.1:;
  }
  _gfortran_reshape_r4 (&parm.1, &parm.2, &atmp.6, 0B, 0B);
}
  }
}

there are two temporaries atmp.3 and atmp.6, and I don't see any reason why the
second one should be needed (all the arguments are INTENT(IN), isn't it?).


-- 
   Summary: Useless temporary with RESHAPE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-06-07 11:56 ---
[lib.string.io] paragraph 8
If the function extracts no characters, it calls is.setstate(ios_base::failbit)
which may throw ios_base::failure (27.4.4.3).


-- 


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

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

[gccbug at oxyware dot com]

--- Comment #9 from gccbug at oxyware dot com  2010-06-07 12:12 ---
The patch doesn't seem to handle != as a terminating condition:

#pragma omp parallel for
for (int i = 0; i != 1000; i++) {}

doesn't compile on 4.4.1, whereas i<1000 does.


-- 


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

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-06-07 12:17 ---
That's correct, it shouldn't compile.
The OpenMP standard doesn't allow != comparisons in omp for condition, only <,
<=, >, >=.


-- 


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

[Bug c++/14258] typename in a using declaration not supported

[fabien at gcc dot gnu dot org]

-- 

fabien at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fabien at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-09-03 21:39:11 |2010-06-07 12:43:20
   date||


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

[Bug c++/44443] New: [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

[jakub at gcc dot gnu dot org]

int i;

void
f1 ()
{
  const int * __attribute__((unused)) a = &i;
  const int *b __attribute__((unused)) = &i;
}

warns for a (incorrectly) and not for b in C++, in C it correctly doesn't warn
at all.


-- 
   Summary: [4.6 Regression] -Wunused-but-set-variable problem with
unused attribute on type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug c++/44444] New: [4.6 Regression] -Wunused-but-set-variable problem with field references

[jakub at gcc dot gnu dot org]

struct S
{
  const int &u;
  const int &v;
  S (const int &a, const int &b) : u(a), v(b) { }
};

bool
f1 ()
{
  bool t = false;
  S z = S (1, 2);
  t |= z.u == 1;
  t |= z.v == 2;
  return t;
}

void
f2 ()
{
  S z = S (1, 2);
  z.u;
}

int i;

void
f3 ()
{
  S z = S (1, 2);
  i++, z.u;
}

warns with -Wunused when it shouldn't (except for no effect warnings).


-- 
   Summary: [4.6 Regression] -Wunused-but-set-variable problem with
field references
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #27 from Kyle dot D dot Moffett at boeing dot com  2010-06-07 
12:49 ---
(In reply to comment #25)
> Yes it seems the patch is not sufficient on 4.4.  On mainline the code looks
> good by inspection.  (I don't have e500 hardware to run tests on.)

If you'd like login access to one of our protoboards, just post an SSH public
key on bugzilla and we'll set up port-forwarded access to one of our Debian
buildd servers.  We're thankful for all the assistance you've been able to
provide.


-- 


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

--- Comment #5 from kazu at gcc dot gnu dot org  2010-06-07 13:12 ---
Subject: Bug 44404

Author: kazu
Date: Mon Jun  7 13:12:42 2010
New Revision: 160372

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160372
Log:
gcc/
PR rtl-optimization/44404
* auto-inc-dec.c (find_inc): Use reg_overlap_mentioned_p instead
of count_occurrences to see if it's safe to modify mem_insn.insn.
gcc/testsuite/

gcc/testsuite/
PR rtl-optimization/44404
* gcc.dg/pr44404.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr44404.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/auto-inc-dec.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

--- Comment #6 from kazu at gcc dot gnu dot org  2010-06-07 13:15 ---
Fixed.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/30195] Using declaration doesn't work in template.

[fabien at gcc dot gnu dot org]

-- 

fabien at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fabien at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-12-30 18:42:41 |2010-06-07 13:17:07
   date||


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

--- Comment #7 from kazu at gcc dot gnu dot org  2010-06-07 13:17 ---
Subject: Bug 44404

Author: kazu
Date: Mon Jun  7 13:17:32 2010
New Revision: 160374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160374
Log:
gcc/
PR rtl-optimization/44404
* auto-inc-dec.c (find_inc): Use reg_overlap_mentioned_p instead
of count_occurrences to see if it's safe to modify mem_insn.insn.
gcc/testsuite/

gcc/testsuite/
PR rtl-optimization/44404
* gcc.dg/pr44404.c: New.

Modified:
trunk/gcc/ChangeLog


-- 


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

[Bug middle-end/44440] ira_initialization and buitins construction taking too much of startup time

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-07 13:36 ---
Created an attachment (id=20854)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20854&action=view)
callgrind.startup.bz2

Callgrind dump for --enable-checking=release trunk cc1 from today on an empty
file.


-- 


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

[Bug c/44445] New: gcc-4.5.0 cannot find gmp-5.0.1

[zero at boolean-domain dot net]

I'm trying to build a gcc cross-compiler.

The configure script was passed the following arguments: --prefix=${tools}/usr
--build=${host} --host=${host} --target=${target} --with-sysroot=${sysroot}
--with-newlib --enable-languages=c --with-gmp=${tools}/usr
--with-mpfr=${tools}/usr --disable-decimal-float --disable-threads
--disable-shared --disable-libmudflap --disable-libssp --disable-libgomp
--disable-multilib

Where: tools=/media/data/linux/tools host=x86_64-cross-linux-gnu
target=x86_64-unknown-linux-gnu sysroot=/media/data/linux/sysroot

I got the following error:

Configuring in x86_64-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-cross-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for x86_64-unknown-linux-gnu-ar...
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/bin/ar
checking for x86_64-unknown-linux-gnu-lipo... x86_64-unknown-linux-gnu-lipo
checking for x86_64-unknown-linux-gnu-nm...
/media/data/linux/sources/gcc-4.4.4-build/./gcc/nm
checking for x86_64-unknown-linux-gnu-ranlib...
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/bin/ranlib
checking for x86_64-unknown-linux-gnu-strip...
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/bin/strip
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc...
/media/data/linux/sources/gcc-4.4.4-build/./gcc/xgcc
-B/media/data/linux/sources/gcc-4.4.4-build/./gcc/
-B/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/bin/
-B/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/include -isystem
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/media/data/linux/sources/gcc-4.4.4-build/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/media/data/linux/sources/gcc-4.4.4-build'
make: *** [all] Error 2

The relevant config.log in the build directory contains the following error
message:

/media/data/linux/sources/gcc-4.4.4-build/./gcc/cc1: error while loading shared
libraries: libgmp.so.10: cannot open shared object file: No such file or
directory

The fact is that libgmp.so.10 is present in the place where gcc should look
for, that is /media/data/linux/tools/usr/lib64.

The problem occurs only with gmp-5.0.1; if I use gmp-4.3.2, instead, I obtain
no build failures.


-- 
   Summary: gcc-4.5.0 cannot find gmp-5.0.1
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zero at boolean-domain dot net
 GCC build triplet: x86_64-cross-linux-gnu
  GCC host triplet: x86_64-cross-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/44442] Useless temporary with RESHAPE

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-06-07 13:49 ---
Useless temporaries are also emitted for PAD and ORDER optional arguments:

program main
  integer :: i, k, l, m, n
  real :: e1, e2
  real, dimension(4,5) :: b
  real, dimension(5,4) :: c
  b = reshape([(i, i=1,20)],[4,5])
  m = 5
  n = 4
  c = reshape(b, [m,n])
  e1 = 1.0
  e2 = 2.0
  k = 2
  l = 1
  c = reshape(b, [m,n], [e1,e2], [k,l])
end program main

pr36928_red.f90:17.24:

  c = reshape(b, [m,n], [e1,e2], [k,l])
1
Warning: Creating array temporary at (1)
pr36928_red.f90:17.24:

  c = reshape(b, [m,n], [e1,e2], [k,l])
1
Warning: Creating array temporary at (1)
pr36928_red.f90:17.33:

  c = reshape(b, [m,n], [e1,e2], [k,l])
 1
Warning: Creating array temporary at (1)
pr36928_red.f90:17.33:

  c = reshape(b, [m,n], [e1,e2], [k,l])
 1
Warning: Creating array temporary at (1)


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-07 14:02:15
   date||


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

[Bug libstdc++/44436] Associative containers lack emplace() and emplace_hint() methods.

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-07 14:03 
---
Yes, we lack *tons* of other C++0x things.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-07 
14:03 ---
Subject: Re:  [4.6 regression] gmp multilib support broke bootstrap with static
libgmp

> --- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-04 17:48 
> ---
> First off this is not a regression; I ran into this issue back a couple of
> years ago with libjava requiring libgmp.

It sure is: you used to be able to bootstrap with a static, non-PIC
libgmp until this change went in, and now bootstrap fails.  If this is
not a regression, what is?

Rainer


-- 


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

[Bug c/44445] gcc-4.5.0 cannot find gmp-5.0.1

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-07 14:24 ---
You need to adjust LD_LIBRARY_PATH.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/43073] libiberty fails to build when using gcc-core

[zero at boolean-domain dot net]

--- Comment #5 from zero at boolean-domain dot net  2010-06-07 14:35 ---
I obtain a similar error message when building a gcc-4.5.0 cross compiler:

/media/data/linux/sources/gcc-4.4.4-build/./gcc/xgcc
-B/media/data/linux/sources/gcc-4.4.4-build/./gcc/
-B/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/bin/
-B/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/include -isystem
/media/data/linux/tools/usr/x86_64-unknown-linux-gnu/sys-include -c
-DHAVE_CONFIG_H -g -O2 -march=core2-I.
-I../../../gcc-4.4.4/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic 
../../../gcc-4.4.4/libiberty/regex.c -o regex.o
../../../gcc-4.4.4/libiberty/regex.c:51:25: error: sys/types.h: No such file or
directory
../../../gcc-4.4.4/libiberty/regex.c:130: warning: function declaration isn’t a
prototype
../../../gcc-4.4.4/libiberty/regex.c:130: warning: conflicting types for
built-in function ‘malloc’
../../../gcc-4.4.4/libiberty/regex.c:131: warning: function declaration isn’t a
prototype
../../../gcc-4.4.4/libiberty/regex.c:131: warning: conflicting types for
built-in function ‘realloc’
../../../gcc-4.4.4/libiberty/regex.c:158:25: error: strings.h: No such file or
directory
In file included from ../../../gcc-4.4.4/libiberty/../include/xregex.h:26,
 from ../../../gcc-4.4.4/libiberty/regex.c:193:
../../../gcc-4.4.4/libiberty/../include/xregex2.h:360: error: expected
specifier-qualifier-list before ‘size_t’
../../../gcc-4.4.4/libiberty/../include/xregex2.h:447: error: expected
declaration specifiers or ‘...’ before ‘size_t’
../../../gcc-4.4.4/libiberty/../include/xregex2.h:543: error: expected
declaration specifiers or ‘...’ before ‘size_t’
../../../gcc-4.4.4/libiberty/../include/xregex2.h:547: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘xregerror’
../../../gcc-4.4.4/libiberty/regex.c:196:20: error: ctype.h: No such file or
directory
../../../gcc-4.4.4/libiberty/regex.c: In function ‘init_syntax_once’:
../../../gcc-4.4.4/libiberty/regex.c:284: warning: implicit declaration of
function ‘bzero’
../../../gcc-4.4.4/libiberty/regex.c:284: warning: incompatible implicit
declaration of built-in function ‘bzero’
../../../gcc-4.4.4/libiberty/regex.c:287: warning: implicit declaration of
function ‘isalnum’
../../../gcc-4.4.4/libiberty/regex.c: At top level:
../../../gcc-4.4.4/libiberty/regex.c:408: error: expected declaration
specifiers or ‘...’ before ‘size_t’
In file included from ../../../gcc-4.4.4/libiberty/regex.c:638:
../../../gcc-4.4.4/libiberty/regex.c:2283: error: expected declaration
specifiers or ‘...’ before ‘size_t’
../../../gcc-4.4.4/libiberty/regex.c: In function ‘byte_regex_compile’:
../../../gcc-4.4.4/libiberty/regex.c:2318: error: ‘size’ undeclared (first use
in this function)
../../../gcc-4.4.4/libiberty/regex.c:2318: error: (Each undeclared identifier
is reported only once
../../../gcc-4.4.4/libiberty/regex.c:2318: error: for each function it appears
in.)
../../../gcc-4.4.4/libiberty/regex.c:2401: error: ‘struct re_pattern_buffer’
has no member named ‘fastmap_accurate’
../../../gcc-4.4.4/libiberty/regex.c:2402: error: ‘struct re_pattern_buffer’
has no member named ‘not_bol’
../../../gcc-4.4.4/libiberty/regex.c:2402: error: ‘struct re_pattern_buffer’
has no member named ‘not_eol’
../../../gcc-4.4.4/libiberty/regex.c:2410: error: ‘struct re_pattern_buffer’
has no member named ‘re_nsub’
../../../gcc-4.4.4/libiberty/regex.c:2439: warning: implicit declaration of
function ‘free’
../../../gcc-4.4.4/libiberty/regex.c:2439: warning: incompatible implicit
declaration of built-in function ‘free’
../../../gcc-4.4.4/libiberty/regex.c:2500: warning: incompatible implicit
declaration of built-in function ‘free’
../../../gcc-4.4.4/libiberty/regex.c:2533: warning: incompatible implicit
declaration of built-in function ‘free’
../../../gcc-4.4.4/libiberty/regex.c:2640: warning: incompatible implicit
declaration of built-in function ‘free’
../../../gcc-4.4.4/libiberty/regex.c:3124: warning: incompatible implicit
declaration of built-in function ‘bzero’
../../../gcc-4.4.4/libiberty/regex.c:3253: warning: implicit declaration of
function ‘strcmp’
../../../gcc-4.4.4/libiberty/regex.c:3280: warning: implicit declaration of
function ‘isalpha’
../../../gcc-4.4.4/libiberty/regex.c:3282: warning: implicit declaration of
function ‘iscntrl’
../../../gcc-4.4.4/libiberty/regex.c:3284: warning: implicit declaration of
function ‘isdigit’
../../../gcc-4.4.4/libiberty/regex.c:3285: warning: implicit declaration of
function ‘isprint’
../../../gcc-4.4.4/libiberty/regex.c:3285: warning: implicit declaration of
function ‘isspace’
../../../gcc-4.4.4/libiberty/regex.c:3286: warning: implicit declaration of
function ‘islower’
../../../gcc-4.4.4/libiberty/regex.c:3289: warning: implicit declaration of
function ‘ispunct’
../../../gcc-4.4.4/libiberty/regex.c:3291: warning: implicit declaration of
function ‘isu

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-06-07 14:52 
---
I think Jon is right on both accounts: the request is reasonable, but, even
before that last changes, thus since the very beginning of v3:

if (!__r)
  __r =  __size - __osize;

thus, I think we want something that while efficient preserves this behavior
(without overflowing). I'm not sure we can do much better, given the
constraints...


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2010-06-07 15:17 
---
Created an attachment (id=20855)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20855&action=view)
Tentative patch (only sanity checked on a system not affected by the glibc
issue)


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #15 from paolo dot carlini at oracle dot com  2010-06-07 15:23 
---
Johannes, can you try the patch and in case, give me some details about the
remaining issues? The idea is simply that if a glibc header has been included
by  before , then __GLIBC__ is defined and __GLIBC_MINOR__
set to the proper value. If the minor is < 10, thus  is buggy, we
include by hand  *before* . It should work. Unless the
library is somehow including  somewhere else outside . That
should be also fixed.


-- 


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

[Bug middle-end/44386] builtin_object_size_ assumes a flexible array for a long array in a structure of known length

[meklund at cisco dot com]

--- Comment #4 from meklund at cisco dot com  2010-06-07 15:26 ---
I see your point that some legacy code might use a larger size as a flexible
array.

What is you opinion on the possibility of adding a bit-flag to
__builtin_object_size() (like 0x04) that tightens the allowed flexible array
size to be only 0 or 1?  Larger sizes would be accepted as the total array
size.  This would be closer to that in
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Zero-Length.html#Zero-Length.


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #16 from paolo dot carlini at oracle dot com  2010-06-07 15:27 
---
Errata: "... by  before ..." should read "... before
 wants to include ..."


-- 


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

[Bug fortran/44446] New: Error with protected pocedure pointer

[mrestelli at gmail dot com]

When compiling the attached code with gfortran I get:

procedure(i_f), pointer, protected :: p_f => null()
  1
Error: PROTECTED attribute conflicts with EXTERNAL attribute at (1)

I think that the code is legal, according to the standard 

  C535 (R501) The PROTECTED attribute is permitted only for a
  procedure pointer or named variable that is not in a common block.

gfortran --version
GNU Fortran (GCC) 4.6.0 20100520 (experimental)

module m
 implicit none
 abstract interface
  pure function i_f(x) result(y)
   real, intent(in) :: x
   real :: y
  end function i_f
 end interface
 !procedure(i_f), pointer :: p_f => null() ! this works
 procedure(i_f), pointer, protected :: p_f => null()
end module m


-- 
   Summary: Error with protected pocedure pointer
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrestelli at gmail dot com
  GCC host triplet: x86_64 AMD Turion(tm) 64 Mobile Technology


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

[Bug c++/39055] [4.3/4.4/4.5/4.6 regression] ICE with questionable default parameter of a member function

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2010-06-07 15:51 ---
Suspending.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug fortran/44446] Error with protected pocedure pointer

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-06-07 15:58 ---
Untested:

--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -567,8 +567,9 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
 }

   conf (is_protected, intrinsic)
-  conf (is_protected, external)
   conf (is_protected, in_common)
+  if (!attr->proc_pointer)
+conf (is_protected, external)

   conf (asynchronous, intrinsic)
   conf (asynchronous, external)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2010-06-07 15:58:33
   date||


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

[Bug fortran/44442] Useless temporary with RESHAPE

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2010-06-07 15:59 ---
(In reply to comment #1)
> Useless temporaries are also emitted for PAD and ORDER optional arguments:
> 

This is a known limitation of array constructors handling by gfortran.
For passing to the library function, a temporary will be created anyway.
The array constructor will fill an intermediary temporary on top of the
previous one.


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-07 15:59:13
   date||


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

[Bug rtl-optimization/44447] New: [MinGW GCC]: Faulty code optimization when -masm=intel added

[dg dot recrutement31 at gmail dot com]

Occurred on Windows Vista, with GCC 4.5.0 and 4.4.0 and -masm=intel and -Ox
x>0,
the code generation produces a faulty output with -O1 and a faulty control frow
leading to SIGSEGV when -O2 or -O3.

When -masm=intel or -Ox deleted, no SIGSEGV occurs and output is right.

This phenomena doesn't occur on Linux version of GCC (tested with 4.4.3).


-- 
   Summary: [MinGW GCC]: Faulty code optimization when -masm=intel
added
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dg dot recrutement31 at gmail dot com
  GCC host triplet: Windows VISTA


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

[Bug rtl-optimization/44447] [MinGW GCC]: Faulty code optimization when -masm=intel added

[dg dot recrutement31 at gmail dot com]

--- Comment #1 from dg dot recrutement31 at gmail dot com  2010-06-07 16:20 
---
Created an attachment (id=20856)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20856&action=view)
source file in which a faulty control flow occurs.

Compiled with gcc 4.5 with the following potions: -ansi -Wall -pedantic -W
-Wl,--enable-auto-import  -masm=intel -save-temps -O2

line 1891: if ((pMyDisasm->Reserved_.MemDecoration >100) &&
(pMyDisasm->Reserved_.MemDecoration < 199))

The control flow is transmitted to this if branch whereas
pMyDisasm->Reserved_.MemDecoration == 0
SIGSEGV is, hence, raised when attempting to access
GoAsmPrefixes[pMyDisasm->Reserved_.MemDecoration-1] at line 1918.

The control flow should be given to the 'else' branch, line 1944.

Hoping it helps to investigate.


-- 


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

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

[manu at gcc dot gnu dot org]

--- Comment #11 from manu at gcc dot gnu dot org  2010-06-07 16:21 ---
(In reply to comment #10)
> That's correct, it shouldn't compile.
> The OpenMP standard doesn't allow != comparisons in omp for condition, only <,
> <=, >, >=.

Is it so difficult to write that in the error message? Would you approve such a
patch?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug rtl-optimization/44447] [MinGW GCC]: Faulty code optimization when -masm=intel added

[dg dot recrutement31 at gmail dot com]

--- Comment #2 from dg dot recrutement31 at gmail dot com  2010-06-07 16:24 
---
(From update of attachment 20856)
The program in which this bug occurs have been tested with valgrind that does
not reveal memory leak and other bug.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-07 
16:32 ---
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

I've now analysed this further: the test only fails at -O3.  The failure
is an abort in l.23:

  DDA1 = ATAN2 ((/(REAL(J1,KV),J1=1,10)/),
 $ REAL((/(J1,J1=nf10,nf1,mf1)/), KV))   !fails
  DDA2 = ATAN2 (DDA, DDA(10:1:-1))
  if (any (DDA1 .ne. DDA2)) call abort ()

Investigating with gdb, I find that only the 10th array element differs:

(gdb ) p dda1
$1 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269,
0.876058042, 1.05165017, 1.21202564, 1.35212743, 1.47112763)
(gdb) p dda2
$2 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269,
0.876058042, 1.05165017, 1.21202564, 1.35212743, 8.40779079e-45)

I've verified that atan2f is called with exactly the same input sequence
in both cases.  The problem is that at -O0 (and probably up to -O2),
atan2f is called 2 x 10 times as expected, and atan2f only appears twice
in the assembler output.

On the other hand, at -O3 the second time through, atan2f(1.0) isn't
called.  Instead, the loop is unrolled, but incorrectly, it seems: there
are now only19 calls to atan2f in the assembler output.

Rainer


-- 


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

[Bug fortran/44448] New: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at gcc dot gnu dot org]

The last remaining gfortran testsuite failure on Solaris 10/11 x86 is

FAIL: gfortran.dg/atan2_1.f90  -O0  execution test

(only for 32-bit).  The test aborts at l.12:

do i = 1, 10
  if(atan(1.0,  i/10.0)  -atan2(1.0,  i/10.)/= 0.0)   call abort()
  if(atan(1.0d0,i/10.0d0)-atan2(1.0d0,i/10.0d0) /= 0.0d0) call abort()
end do

at the first if for i=1.  This is very strange, since I've verified that
atan2f is called both times with identical args.  I'm uncertain how to proceed
from here and don't know how to investigate the i387 floating point registers
in gdb.


-- 
   Summary: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris
1[01]/x86 at -O0
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.1[01]
  GCC host triplet: i386-pc-solaris2.1[01]
GCC target triplet: i386-pc-solaris2.1[01]


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

--- Comment #18 from ro at gcc dot gnu dot org  2010-06-07 16:48 ---
Created an attachment (id=20857)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20857&action=view)
assembler output at -O0


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

--- Comment #19 from ro at gcc dot gnu dot org  2010-06-07 16:49 ---
Created an attachment (id=20858)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20858&action=view)
assembler output at -O3


-- 


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

[Bug tree-optimization/44406] wrong code generation with -ftree-sra

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2010-06-07 16:51 ---
Moreover, I cannot reproduce this bug on the 4.5 branch since:

r159866 | rguenth | 2010-05-26 13:46:01 +0200 (Wed, 26 May 2010) | 12 lines

2010-05-26  Richard Guenther  

PR rtl-optimization/44164
* tree-ssa-alias.c (aliasing_component_refs_p): Fix the
no-common access-path disambiguation.
(indirect_ref_may_alias_decl_p): Adjust.
(indirect_refs_may_alias_p): Likewise.
(refs_may_alias_p_1): Likewise.

* gcc.c-torture/execute/pr44164.c: New testcase.
* g++.dg/tree-ssa/pr13146.C: Adjust.


So, I think it is the same bug and mark it accordingly.



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


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jamborm at gcc dot gnu dot org]

--- Comment #26 from jamborm at gcc dot gnu dot org  2010-06-07 16:51 
---
*** Bug 44406 has been marked as a duplicate of this bug. ***


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||torbenh at users dot
   ||sourceforge dot net


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

[Bug c++/44449] New: incorrectly allows assignment to arrays from braced-init-list (c++0x)

[cubbi at cubbi dot org]

I am able to compile this using -std=c++0x (not even -std=gnu++0x):

#include 
int main()
{
int test[] = {1,2,3};
std::cout << test[0] << test[1] << test[2];
test = {4,5,6};
std::cout << test[0] << test[1] << test[2] << std::endl;
}

it compiles without warnings (-Wall -Wextra -pedantic) and prints 123456.

Tested on GCC 4.4.3 and GCC 4.5.1-pre

The C++0x final draft (N3092) says, under 5.17/9 [expr.ass]

A braced-init-list may appear on the right-hand side of
— an assignment to a scalar [...]
— an assignment defined by a user-defined assignment operator [..]

The standard does not allow assignment from a braced-init-list to arrays (and
if was allowed, then, logically, assignment of arrays to arrays would be
allowed as well)


-- 
   Summary: incorrectly allows assignment to arrays from braced-
init-list (c++0x)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cubbi at cubbi dot org
  GCC host triplet: x86_64-pc-linux-gnu-4.5.1-pre


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2010-06-07 16:56 ---
(In reply to comment #5)
> 
> have a look at PR44406... i believe its the same thing.
> 

I think it probably is because the patch of mine would lead to code
very similar to what exposed PR 44406.  However, PR 44406 actually no
longer happens on the trunk because it is very likely a duplicate of
PR 44164.

So can you please verify that this miscompilation still takes place
with the current 4.5 branch before I go into all the troubles of
looking at what compiles differently and where?  Thanks.


-- 


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

[Bug middle-end/44450] New: gcc.dg/lto/20090210 fails with emutls

[ro at gcc dot gnu dot org]

I've recently compared testsuite results on Solaris 11/x86 with --enable-tls
(the default) and --disable-tls before going on to investigate TLS problems on
Solaris 8 and 9, especially given that emutls has been broken on mainline (and
the
4.5 branch) for quite some time.

In doing so, I noticed an LTO testcase that fails with --disable-tls, but
passes
without:

+FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0
-fwhopr
+UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute
-O0 -fwhopr

ld: fatal: symbol `__emutls_v.value.1595.2037' is multiply-defined:



+FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2
-fwhopr
+UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute
-O2 -fwhopr

  likewise, just -O2


-- 
   Summary: gcc.dg/lto/20090210 fails with emutls
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug c++/44449] incorrectly allows assignment to arrays from braced-init-list (c++0x)

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-06-07 17:03 ---
I think this is Bug 44045 and was fixed for 4.6 


-- 


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

[Bug middle-end/44451] New: libgomp.c/pr33880.c and libgomp.fortran/omp_parse1.f90 fail with emultls

[ro at gcc dot gnu dot org]

During my investigtion of testsuite differences with and without --enable-tls
(cf. PR middle-end/44450), I noticed another bunch of failures that only happen
with emutls, but only for 32-bit:

+FAIL: libgomp.c/pr33880.c execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O0  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O1  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O2  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -O3 -g  execution test
+FAIL: libgomp.fortran/omp_parse1.f90  -Os  execution test

I haven't yet analysed this further.


-- 
   Summary: libgomp.c/pr33880.c and libgomp.fortran/omp_parse1.f90
fail with emultls
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug target/44364] Wrong code with e500 double floating point

[amodra at gmail dot com]

--- Comment #28 from amodra at gmail dot com  2010-06-07 17:05 ---
Please bootstrap and test this addition to e500.h

/* When setting up caller-save slots (MODE == VOIDmode) ensure we
   allocate space for DFmode.  Save gprs in the correct mode too.  */
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
  (TARGET_E500_DOUBLE && ((MODE) == VOIDmode || (MODE) == DFmode)   \
   ? DFmode \
   : choose_hard_reg_mode ((REGNO), (NREGS), false))


-- 


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

[Bug c++/44449] incorrectly allows assignment to arrays from braced-init-list (c++0x)

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-06-07 17:10 ---
pr.cc: In function 'int main()':
pr.cc:6:22: error: assigning to an array from an initializer list


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/44452] New: gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86

[ro at gcc dot gnu dot org]

Investigating the few remaining testsuite failures on Solaris 11/x86, I came
across

FAIL: gcc.target/i386/abi-2.c scan-assembler-times ymm0 1

In the assembler output, ymm0 appears twice:

   vmovdqa .LC0, %ymm0
   vmovdqa %ymm0, (%eax)

FAIL: gcc.target/i386/pr22076.c scan-assembler-times movq 3

movq appears only twice:

paddb   .LC0, %mm0
movl24(%esp), %eax
movq%mm0, 8(%esp)

FAIL: gcc.target/i386/pr22076.c scan-assembler-not movl

movl appears 5 times

The failures occur only for 32-bit.

Both failures seem to be due to i386.c (ix86_sol10_return_in_memory): unlike
return_in_memory_32, that function doesn't know about AVX yet.  It seems like
the testcase needs to take the differing Solaris 2/x86 ABI for MMX, though
it's unusual that the 32-bit ABI should have changed between Solaris 9 and 10.
Perhaps Richard can shed some light on this?

Given this divergence between the generic and sol10 function, it seems unwise
to leave them separate.  Instead, I'd rather have code (conditional on say
TARGET_SOLARIS or TARGET_SOLARIS10) in return_in_memory_32 to handle the
Solaris ABI requirements there.  The only problem with such an approach is
that i386/vx-common.h uses ix86_sol10_return_in_memory, too, but would probably
be interested in every possible code conditional on TARGET_SOLARIS.


-- 
   Summary: gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c
fail on 32-bit Solaris 10+/x86
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713

[amodra at gmail dot com]

--- Comment #5 from amodra at gmail dot com  2010-06-07 17:25 ---
Created an attachment (id=20859)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20859&action=view)
fix pr42427 fallout

Would someone with e500 hardware please bootstrap and regression test this
patch?  I'm running powerpc-linux bootstrap to ensure pr42427 doesn't regress.


-- 


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

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-06-07 17:29 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug c/44420] [feature request] Warn for certain integer overflows

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-07 17:34 ---
>  foo = bar << 20;

Yes this can overflow but so can "bar * 2" and "bar + 1".  Maybe I am missing
something here because we don't warn for those cases.  Do you want a warning
where the assignment happens to be a wider type?  That is:

uint64_t = uint32_t OP uint32_t;  With an implicit casting to uint64_t?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|middle-end  |c
   Keywords||diagnostic


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

[Bug c/44420] [feature request] Warn for certain integer overflows

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-06-07 17:36 ---
(In reply to comment #1)
> uint64_t = uint32_t OP uint32_t;  With an implicit casting to uint64_t?

If that is the case this is a dup of bug 42935.


-- 


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

[Bug c++/44443] [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-07 17:49 ---
Subject: Bug 3

Author: jakub
Date: Mon Jun  7 17:49:06 2010
New Revision: 160387

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160387
Log:
PR c++/3
* decl.c (initialize_local_var): If TREE_USED is set on the type,
set also DECL_READ_P on the decl.

* c-c++-common/Wunused-var-11.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wunused-var-11.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44444] [4.6 Regression] -Wunused-but-set-variable problem with field references

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-07 17:50 ---
Subject: Bug 4

Author: jakub
Date: Mon Jun  7 17:50:10 2010
New Revision: 160388

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160388
Log:
PR c++/4
* expr.c (mark_exp_read): Handle INDIRECT_REF.
* cvt.c (convert_to_void): Handle INDIRECT_REF like
handled_component_p.

* g++.dg/warn/Wunused-var-12.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/cp/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44401] [4.5/4.6 regression] Doesn't correctly hide injected class name

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-03 18:55:26 |2010-06-07 17:50:43
   date||


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

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-06-07 17:52 ---
  uint32_t bar;
  uint64_t foo;
  ...
  foo = bar << 20;

Is another testcase from PR 44420.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-02-24 00:16:51 |2010-06-07 17:52:46
   date||
Summary|Warning "u64 = u32 * u32;" -|warn if a binary operation
   |i.e. not casting one u32 to |is performed on a type but
   |u64 |the result is then casted to
   ||a larger type


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

[Bug c/44420] [feature request] Warn for certain integer overflows

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2010-06-07 17:53 ---
I think it is a duplicate.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2010-06-07 17:53 ---
*** Bug 44420 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fm3 at os dot inf dot tu-
   ||dresden dot de


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

[Bug rtl-optimization/42461] Missed optimisation for pure functions with __builtin_unreachable

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2010-06-07 17:53 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-22 15:13:38 |2010-06-07 17:53:44
   date||


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

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2010-06-07 18:04 ---



I think the condition of this warning should be:

warn if a binary operation is performed on a type but the result is then
implicitly converted to a larger type. The workaround for a valid case should
be casting to the same type as the result beforehand. For example:

unsigned val1 = 0x1000, val2 = 0x100;
unsigned long long val3 = val1 * val2; // "warning: binary operation '*' is
performed on type 'unsigned int' but the result is converted to type 'double'"
unsigned long long val4 = (unsigned) (val1 * val2); // silence

This probably can be implemented in convert_and_check in c-common.c or in
build_binary_op in c-typeck.c. I am not working on this.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|i686-pc-cygwin  |
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |


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

[Bug c++/44443] [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-07 18:05 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/44444] [4.6 Regression] -Wunused-but-set-variable problem with field references

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-07 18:05 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/44354] implied do loop with its own variable name as upper bound

[tkoenig at gcc dot gnu dot org]

--- Comment #22 from tkoenig at gcc dot gnu dot org  2010-06-07 18:11 
---
Adjusting subject, setting severity to "enhancement" and
adding "diagnostic" keyword.(In reply to comment #21)
> (In reply to comment #18)
> > Expected:
> > a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu 
> > one
> > could consider a default-enabled warning)
> > b) Reject it for -std=f(95,2003,2008)
> 
> I'd vote to reject it for any -std=*. This extension just asks for trouble.

I concur.  I would also favor a warning at least for -Wuninitialized.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
   Keywords||diagnostic
Summary|incorrect output at run time|implied do loop with its own
   ||variable name as upper bound


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

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

[dj at redhat dot com]

--- Comment #3 from dj at redhat dot com  2010-06-07 18:14 ---
Subject: Re:  gengtype: don't test undefined value after vasprintf failure


> If the libiberty maintainers won't review the xvasprintf patch,

I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html


-- 


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

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

[jim at meyering dot net]

--- Comment #4 from jim at meyering dot net  2010-06-07 18:24 ---
Good!  I see that there's already a patch to deal with all of the unchecked
asprintf calls, too.


-- 


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

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

[changpeng dot fang at amd dot com]

--- Comment #14 from changpeng dot fang at amd dot com  2010-06-07 18:27 
---
Here is the current status of my investigation:

(1) 465.tonto regression (~9%):
The regressions mainly comes from loops which have array references with both
constant (prefetch_mod = 8) and non-constant (prefetch_mod=1) steps. The loops
are unrolled 8 times, and 8 non-constant step prefetches are inserted into the
unrolled loops.

The ideal way to solve the problem is to compute the prefetch count considering
the effect of unrolling, i.e. we should count 8 non-constant step prefetches
in stead of 1.

(2) 416.gamess regression (~5%):
The regression is from non-constant-step prefetching for outer loops. I am
proposing not to do non-constant step prefetching for outer loops to solve the
problem.


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #29 from Kyle dot D dot Moffett at boeing dot com  2010-06-07 
18:28 ---
Awesome!!! Both of our testcases that were failing pass with this patch
applied!

I'm not going to call it a 100% victory yet, I want to rebuild our native
compilers and build-and-run the PostgreSQL, GMP and MPFR testsuites first.

Here's hoping though! *crosses fingers*


-- 


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

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

[changpeng dot fang at amd dot com]

--- Comment #15 from changpeng dot fang at amd dot com  2010-06-07 18:30 
---
Created an attachment (id=20860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view)
Don't consider effect of unrolling in the computation of insn-to-prefetch ratio


-- 


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

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

[changpeng dot fang at amd dot com]

--- Comment #16 from changpeng dot fang at amd dot com  2010-06-07 18:32 
---
Created an attachment (id=20861)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20861&action=view)
Limit non-constant step prefetching only to the innermost loops


-- 


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

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

[changpeng dot fang at amd dot com]

--- Comment #17 from changpeng dot fang at amd dot com  2010-06-07 18:37 
---
(In reply to comment #15)
> Created an attachment (id=20860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view) [edit]
> Don't consider effect of unrolling in the computation of insn-to-prefetch 
> ratio
> 

To compute the insn-to-prefetch ratio precisely, we may need to compute this
after
schedule_prefetches to know exactly how many prefetches are scheduled (we also
need to compute the exact number of insns in the unrolled body). For now, I
would
like to unable my previous commit of using (unroll_factor * insns) for the
total
insns in the unrolled body.


-- 


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

[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris

[ro at gcc dot gnu dot org]

--- Comment #3 from ro at gcc dot gnu dot org  2010-06-07 18:50 ---
Revised patch available.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2010-   |patches/2010-
   |05/msg01365.html|06/msg00600.html


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

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #30 from Kyle dot D dot Moffett at boeing dot com  2010-06-07 
18:56 ---
Ok, the cross-compiler built with this patch fails to build a native GCC for
the target with the following ICE:

../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd128':
../../../src/libgcc/../libdecnumber/decLibrary.c:71: error: unrecognizable
insn: (insn 6 5 7 2 ../../../src/libgcc/../libdecnumber/decLibrary.c:68 (set
(subreg:TI (reg:TD 122 [ arg ]) 0) (reg:TI 123)) -1 (nil))
../../../src/libgcc/../libdecnumber/decLibrary.c:71: internal compiler error:
in extract_insn, at recog.c:2001


-- 


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

[Bug middle-end/42371] dead code not eliminated during folding with whole-program

[matt at use dot net]

--- Comment #4 from matt at use dot net  2010-06-07 19:46 ---
Let me know when this is implemented on trunk (preferrably by marking this
report as resolved) and I'll test my proprietary test cases here.

Thanks!


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jan dot kratochvil at redhat dot com]

--- Comment #23 from jan dot kratochvil at redhat dot com  2010-06-07 20:03 
---
(In reply to comment #9)
> In debug info we could use DW_OP_call{2,4} to refer to those
> DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.

FYI FSF GDB HEAD supports them now:
http://sourceware.org/bugzilla/show_bug.cgi?id=10640

DW_OP_call_ref is still not supported, though:
http://sourceware.org/bugzilla/show_bug.cgi?id=11674


-- 


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

[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib

[ro at gcc dot gnu dot org]

--- Comment #16 from ro at gcc dot gnu dot org  2010-06-07 20:11 ---
Subject: Bug 32499

Author: ro
Date: Mon Jun  7 20:10:41 2010
New Revision: 160395

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160395
Log:
toplevel:
Backport from mainline:
2010-03-01  Rainer Orth  

PR libstdc++/32499
* configure.ac (RANLIB): Default to true.
(STRIP): Likewise.
(RANLIB_FOR_TARGET): Remove superfluous : argument.
* configure: Regenerate.

libstdc++-v3:
Backport from mainline:
2010-03-01  Rainer Orth  

PR libstdc++/32499
* testsuite/Makefile.am (check-DEJAGNU
$(check_DEJAGNU_normal_targets)): Export AR, RANLIB.
* testsuite/Makefile.in: Regenerate.

Modified:
branches/gcc-4_4-branch/ChangeLog
branches/gcc-4_4-branch/configure
branches/gcc-4_4-branch/configure.ac
branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
branches/gcc-4_4-branch/libstdc++-v3/testsuite/Makefile.am
branches/gcc-4_4-branch/libstdc++-v3/testsuite/Makefile.in


-- 


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

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2010-06-07 20:17 ---
Subject: Re:  gengtype: don't test undefined value after
 vasprintf failure

On Mon, 7 Jun 2010, dj at redhat dot com wrote:

> > If the libiberty maintainers won't review the xvasprintf patch,
> 
> I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html

That's a review of an older version.  The URLs I gave were of a version a 
different person updated to take account of your original review comments.


-- 


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

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #18 from rakdver at kam dot mff dot cuni dot cz  2010-06-07 
20:24 ---
Subject: Re:  Big spec cpu2006 prefetch regressions
on gcc 4.6 on x86

> --- Comment #14 from changpeng dot fang at amd dot com  2010-06-07 18:27 
> ---
> Here is the current status of my investigation:
> 
> (1) 465.tonto regression (~9%):
> The regressions mainly comes from loops which have array references with both
> constant (prefetch_mod = 8) and non-constant (prefetch_mod=1) steps. The loops
> are unrolled 8 times, and 8 non-constant step prefetches are inserted into the
> unrolled loops.
> 
> The ideal way to solve the problem is to compute the prefetch count 
> considering
> the effect of unrolling, i.e. we should count 8 non-constant step prefetches
> in stead of 1.
> 
> (2) 416.gamess regression (~5%):
> The regression is from non-constant-step prefetching for outer loops. I am
> proposing not to do non-constant step prefetching for outer loops to solve the
> problem.

both of these sound reasonable to me,

Zdenek


-- 


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