[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

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

--- Comment #23 from Uros Bizjak  2012-08-26 06:59:43 
UTC ---
(In reply to comment #16)
> I think that the problems with the log test should be fixed now.

The problem resurfaced again on alpha [1]:

--- FAIL: log.TestAll (0.26 seconds)
:0: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello
23 world$" is ":0: hello 23 world"
:0: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello
23 world$" is ":0: hello 23 world"
:0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
:0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
:0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
:0: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23
world$" is ":0: hello 23 world"
:0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.721082 :0: hello 23 world"
:0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.743545 :0: hello 23 world"
:0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.772843 :0: hello 23 world"
:0: log output should match
"^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9]
[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/08/23
03:01:23.793352 :0: hello 23 world"
FAIL
FAIL: log

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02550.html

[Bug go/52583] Several new go testsuite failues on Solaris

[ubizjak at gmail dot com]

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

--- Comment #24 from Uros Bizjak  2012-08-26 07:53:02 
UTC ---
(In reply to comment #23)
> (In reply to comment #16)
> > I think that the problems with the log test should be fixed now.
> 
> The problem resurfaced again on alpha [1]:

Comment 11 has a testcase patch, when applied to log/log_test.go test source,
this problem will trigger on x86_64-pc-linux-gnu too.

[Bug libstdc++/54376] incorrect complaint about redefinition

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  2012-08-26 
07:54:41 UTC ---
Created attachment 28087
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28087
Alternate solution

What about this (completely untested) other solution? (reindentation is needed
after the patch, but too many white space changes make patches hard to read).

Then the only special case is normal_distribution, which befriends operator==
for all template parameters, not just its own (not that it can cause any
issue). Being friend only with your own operator== is complicated when you put
its definition outside the class, so I guess it makes sense to leave it that
way.

[Bug go/52583] Several new go testsuite failues on Solaris

[pinskia at gcc dot gnu.org]

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

--- Comment #25 from Andrew Pinski  2012-08-26 
08:41:25 UTC ---
(In reply to comment #23)
> The problem resurfaced again on alpha [1]:

And on mips64.

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #23 from Mikael Morin  2012-08-26 
09:14:16 UTC ---
Unassigning.

[Bug fortran/38113] on warning/error: skip whitespaces, move position marker to actual variable name

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

[Bug fortran/38113] on warning/error: skip whitespaces, move position marker to actual variable name

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  2012-08-26 
09:20:16 UTC ---
Unassigning.

[Bug fortran/41093] memory leaks with gfc_namespace

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #2 from Mikael Morin  2012-08-26 
09:21:23 UTC ---
Unassigning

[Bug libstdc++/54376] incorrect complaint about redefinition

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2012-08-26 
09:46:14 UTC ---
Thanks. I say, lets go with Marc's solution, both mainline and branch. Marc,
can you test it?

[Bug c++/39281] Error message 'multiple types in one declaration' need to be reworded

[cklists at gn dot apc.org]

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

Cedders  changed:

   What|Removed |Added

 CC||cklists at gn dot apc.org

--- Comment #1 from Cedders  2012-08-26 10:07:58 UTC 
---
+1 The problem here is that the line number given is at the end of a typedef or
class declaration and you tend to look at that unit, rather than at something
several lines earlier that may not have been correctly terminated.  

The hint suggested would tell you what to look for (in what a web search
suggests is the most common cause).

I wonder though why "class id {...} class..."  and "class id {...} id2
class..." give different errors, and in both cases the line number reported is
not the second "class" but can be several lines later.

[Bug c/44519] improve message for missing ";" after struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jonathan Wakely  2012-08-26 
10:34:31 UTC ---
GCC now gives:

mult.c:3:9: error: expected ‘;’, identifier or ‘(’ before ‘int’

and G++ gives:

mult.cc:1:21: error: expected ‘;’ after struct definition

[Bug c++/39281] Error message 'multiple types in one declaration' need to be reworded

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2012-08-26 
10:35:01 UTC ---
this is fixed in current releases

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

[Bug c/44519] improve message for missing ";" after struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||yuri at tsoft dot com

--- Comment #4 from Jonathan Wakely  2012-08-26 
10:35:01 UTC ---
*** Bug 39281 has been marked as a duplicate of this bug. ***

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[fdumont at gcc dot gnu.org]

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

--- Comment #2 from François Dumont  2012-08-26 
10:55:43 UTC ---
I will have a closer look but what I can say for the moment is that the tested
source code doesn't seem to match the latest trunk state, the line numbers
don't match. Can you have a check with latest version ?

For info, there is a check on the address of the key to avoid just what you
describe that is to say deallocate a node and keep on using the key part of it.

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-26
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2012-08-26 
12:31:10 UTC ---
I can confirm the valgrind error:

==7930== Memcheck, a memory error detector
==7930== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==7930== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==7930== Command: ./a.out
==7930== 
i = 47
==7930== Invalid read of size 4
==7930==at 0x40344C: std::equal_to::operator()(int const&, int const&)
const (in /home/paolo/Work/a.out)
==7930==by 0x402F6D: std::__detail::_Equal_helper, std::__detail::_Select1st, std::equal_to, unsigned long,
false>::_S_equals(std::equal_to const&, std::__detail::_Select1st const&,
int const&, unsigned long, std::__detail::_Hash_node,
false>*) (in /home/paolo/Work/a.out)
==7930==by 0x4027D5: std::__detail::_Hashtable_base, std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Hashtable_traits >::_M_equals(int const&,
unsigned long, std::__detail::_Hash_node, false>*)
const (in /home/paolo/Work/a.out)
==7930==by 0x401D8C: std::_Hashtable,
std::allocator >, std::__detail::_Select1st,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::erase(int const&) (in
/home/paolo/Work/a.out)
==7930==by 0x400EB6: main (in /home/paolo/Work/a.out)
==7930==  Address 0x5d6130c is 12 bytes inside a block of size 16 free'd
==7930==at 0x4C285BC: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7930==by 0x402D85:
__gnu_cxx::new_allocator,
false> >::deallocate(std::__detail::_Hash_node,
false>*, unsigned long) (in /home/paolo/Work/a.out)
==7930==by 0x402756: std::_Hashtable,
std::allocator >, std::__detail::_Select1st,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits
>::_M_deallocate_node(std::__detail::_Hash_node,
false>*) (in /home/paolo/Work/a.out)
==7930==by 0x401D29: std::_Hashtable,
std::allocator >, std::__detail::_Select1st,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::erase(int const&) (in
/home/paolo/Work/a.out)
==7930==by 0x400EB6: main (in /home/paolo/Work/a.out)
==7930== 
==7930== 
==7930== HEAP SUMMARY:
==7930== in use at exit: 0 bytes in 0 blocks
==7930==   total heap usage: 55 allocs, 55 frees, 1,488 bytes allocated
==7930== 
==7930== All heap blocks were freed -- no leaks are possible
==7930== 
==7930== For counts of detected and suppressed errors, rerun with: -v
==7930== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-08-26 
12:37:50 UTC ---
In current mainline line # is 1496.

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/54376] incorrect complaint about redefinition

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jason at gcc dot gnu.org|
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #13 from Paolo Carlini  2012-08-26 
12:59:29 UTC ---
Let me handle the library bits and let's move forward.

[Bug target/54378] New: code bloat for long << shifts

[gjl at gcc dot gnu.org]

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

 Bug #: 54378
   Summary: code bloat for long << shifts
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


Something goes woring with cost computaton fir shifts:

long ashl32_7 (long x)
{
return x << 7;
}

compiled with -O2 -dp -mmcu=atmega8 -S -fno-split-wide-types
results in


ashl32_7:
/* DEBUG: cost = 32.  */
lsl r22 ;  27*ashlsi3_const/4[length = 8]
rol r23
rol r24
rol r25
lsl r22
rol r23
rol r24
rol r25
/* DEBUG: cost = 32.  */
lsl r22 ;  28*ashlsi3_const/4[length = 8]
rol r23
rol r24
rol r25
lsl r22
rol r23
rol r24
rol r25
/* DEBUG: cost = 32.  */
lsl r22 ;  29*ashlsi3_const/4[length = 8]
rol r23
rol r24
rol r25
lsl r22
rol r23
rol r24
rol r25
/* DEBUG: cost = 16.  */
lsl r22 ;  30*ashlsi3_const/2[length = 4]
rol r23
rol r24
rol r25
/* DEBUG: pattern-cost = 4.  */
ret ;  26return[length = 1]


The insns are already there at .expand

[Bug target/54378] code bloat for long << shifts

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-26
 CC||eric.weddington at atmel
   ||dot com
 Ever Confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  2012-08-26 
13:06:28 UTC ---
... 3 typo in 2 words

Something goes wrong with cost computation for shifts

[Bug libstdc++/54297] [C++11] Segmentation fault with std::async and released shared state

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-08-26 
13:49:51 UTC ---
Author: redi
Date: Sun Aug 26 13:49:44 2012
New Revision: 190685

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190685
Log:
PR libstdc++/54297
* src/c++11/future.cc (~_Async_state_common): Move to...
* src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
Here.
(_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
* include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/future
trunk/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
trunk/libstdc++-v3/src/c++11/future.cc

[Bug libstdc++/54376] incorrect complaint about redefinition

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2

[Bug libstdc++/54297] [C++11] Segmentation fault with std::async and released shared state

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-08-26 
14:09:20 UTC ---
Author: redi
Date: Sun Aug 26 14:09:12 2012
New Revision: 190687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190687
Log:
PR libstdc++/54297
* src/c++11/future.cc (~_Async_state_common): Move to...
* src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
Here.
(_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
* include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.

Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/std/future
   
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/future.cc

[Bug c++/4970] vector::at not defined

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  2012-08-26 
14:40:27 UTC ---
Author: hjl
Date: Sun Aug 26 14:40:22 2012
New Revision: 190689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190689
Log:
Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

PR binutils/4970
* Makefile.def (host_modules): Rmove lib_path=.libs from bfd
and opcodes.
* Makefile.in: Regenerated.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug libstdc++/54376] incorrect complaint about redefinition

[paolo at gcc dot gnu.org]

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

--- Comment #14 from paolo at gcc dot gnu.org  
2012-08-26 17:22:50 UTC ---
Author: paolo
Date: Sun Aug 26 17:22:43 2012
New Revision: 190694

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190694
Log:
2012-08-26  Marc Glisse  
Paolo Carlini  

PR libstdc++/54376
* include/bits/random.h (lognormal_distribution<>::operator==,
gamma_distribution<>::operator==,
chi_squared_distribution<>::operator==,
fisher_f_distribution<>::operator==,
student_t_distribution<>::operator==,
binomial_distribution<>::operator==,
negative_binomial_distribution<>::operator==,
poisson_distribution<>::operator==): Change inline friend definition
to non-template.
* testsuite/26_numerics/random/binomial_distribution/requirements/
explicit_instantiation/1.cc: New.
* testsuite/26_numerics/random/cauchy_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/chi_squared_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/discrete_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/exponential_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/extreme_value_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/fisher_f_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/gamma_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/geometric_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/lognormal_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/negative_binomial_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/normal_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/piecewise_constant_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/piecewise_linear_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/poisson_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/student_t_distribution/requirements/
explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/uniform_int_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/uniform_real_distribution/
requirements/explicit_instantiation/1.cc: Likewise.
* testsuite/26_numerics/random/weibull_distribution/requirements/
explicit_instantiation/1.cc: Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/fisher_f_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/fisher_f_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/gamma_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/gamma_distribution/requirements/explicit_instantiation/1.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/geometric_distribution/requirements/explicit_instantiation/
   
trunk/libstdc++-v3/testsuite/26_numerics/random/geometric_distribution/requirements/explicit_instantiati

[Bug libffi/53014] [4.8 Regression] libffi failures on mips64-linux-gnu with soft-float

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2012-08-26 
18:29:26 UTC ---
Author: pinskia
Date: Sun Aug 26 18:29:21 2012
New Revision: 190696

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190696
Log:
2012-08-26  Andrew Pinski  

PR libffi/53014
* src/mips/ffi.c (ffi_prep_closure_loc): Allow n32 with soft-float and n64
with
soft-float.


Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/mips/ffi.c

[Bug libffi/53014] [4.8 Regression] libffi failures on mips64-linux-gnu with soft-float

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Andrew Pinski  2012-08-26 
18:30:16 UTC ---
Fixed.

[Bug libstdc++/54102] generated html vs. utf8

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-26
 Ever Confirmed|0   |1

--- Comment #1 from Gerald Pfeifer  2012-08-26 
19:56:47 UTC ---
I established utf-8 on a global base for gcc.gnu.org, so the immediate
cases should be covered.

Fixing up the generated web pages for libstdc++ still will be good.

[Bug c++/53958] [4.6/4.7/4.8 Regression] set_slot_part and canon_value_cmp using 90% of compile time

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

Summary|set_slot_part and   |[4.6/4.7/4.8 Regression]
   |canon_value_cmp using 90%   |set_slot_part and
   |of compile time |canon_value_cmp using 90%
   ||of compile time
  Known to fail||4.6.3, 4.7.1, 4.8.0

--- Comment #2 from Steven Bosscher  2012-08-26 
20:36:42 UTC ---
Another one on the heap of var-tracking slowness issues...

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-08-26 
23:07:14 UTC ---
Interestingly, however, I'm seeing a *very* similar valgrind error with 4.6.2
and 4.5.4 (which had the "old" implementation).

Dennis, which is the oldest GCC version which worked fine with your code?

Because the snippet attached here, whatever it shows in terms of valgrind,
doesn't look like a regression, frankly. Maybe it's a serious issue, we should
investigate further - false alarms are possible, though - but it's something
which isn't new. Dennis, likely we need a snippet closer to the code actually
crashing for you to make further progress.

[Bug c++/54379] New: Suggestion for type attribute similar to warn_unused_result

[jewillco at osl dot iu.edu]

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

 Bug #: 54379
   Summary: Suggestion for type attribute similar to
warn_unused_result
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jewil...@osl.iu.edu


I think it would be useful to extend GCC with an attribute similar to
`warn_unused_result` but applying to a user-defined type rather than just a
single function.  The effect would be that all expressions (variable
references, function calls, etc.) that return some object of that type would
warn if their results were unused.  The intended use case is for C++ patterns
such as expression templates in which purely-functional code builds up an
expression tree which does not make sense to discard; in some cases, operator=
would just add to the expression tree as well, leading to a source of bugs. 
This would probably require the kind of cast-to-void override mechanism that PR
25509 is about, since these annotations would strictly be recommendations.

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P2  |P3

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-08-26 
23:20:25 UTC ---
And of course I concur with Francois about the weird line number: current 4.8.0
doesn't have that line of code at that line number, it looks like Dennis you
are not using 4.8.0 but something else. But more importantly we badly need a
snippet actually crashing and also it would be very useful to know which older
version worked for you.

[Bug lto/54380] New: Lto bootstrap fails on i686-pc-linux-gnu

[juhani.viherakoski at gmail dot com]

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

 Bug #: 54380
   Summary: Lto bootstrap  fails on i686-pc-linux-gnu
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: juhani.viherako...@gmail.com


I just updated my trunk using svn. Configure command is:

../gcc-trunk/configure --prefix=/home/misty/gcc --enable-languages=c,c++,lto
--program-suffix=-trunk --enable-checking=release
--with-build-config=bootstrap-lto

Then I just typed 'time make', this was the end result:

/home/misty/testaus/obj-gcc/./prev-gcc/g++
-B/home/misty/testaus/obj-gcc/./prev-gcc/
-B/home/misty/gcc/i686-pc-linux-gnu/bin/ -nostdinc++
-B/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/include
-I/home/misty/testaus/gcc-trunk/libstdc++-v3/libsupc++
-L/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/misty/testaus/obj-gcc/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions -fno-rtti
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
tree-mudflap.o i386-c.o default-c.o \
  cc1-checksum.o libbackend.a main.o  libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  
-lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
In file included from ../../gcc-trunk/gcc/attribs.c:3215:0,
 from :7090:
../../gcc-trunk/libcpp/lex.c: In function ‘search_line_sse2’:
../../gcc-trunk/libcpp/lex.c:369:53: internal compiler error: in convert_move,
at expr.c:325
   const v16qi repl_nl = *(const v16qi *)repl_chars[0];
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [/tmp/cc6fsipn.ltrans29.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c/54381] New: -Wsizeof-pointer-memaccess refers to "destination" for strncmp

[gerald at pfeifer dot com]

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

 Bug #: 54381
   Summary: -Wsizeof-pointer-memaccess refers to "destination" for
strncmp
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@pfeifer.com


In this example

  #include 

  int f(const char *s) {
const char *t = "a string";

return strncmp(t,s,sizeof t);
  }

-Wsizeof-pointer-memaccess nicely detects that sizeof probably is
not what the programmer meant.

  x.c: In function ‘f’:
  x.c:6:29: warning: argument to ‘sizeof’ in ‘strncmp’ call is the same
expression as the destination; did you mean to provide an explicit
length?[-Wsizeof-pointer-memaccess]
   return strncmp(t,s,sizeof t);
 ^

However, t is not really a "destination".  The first two parameters
of strcmp and strncmp both are sources.

[Bug c++/53958] [4.6/4.7/4.8 Regression] set_slot_part and canon_value_cmp using 90% of compile time

[steven at gcc dot gnu.org]

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

--- Comment #3 from Steven Bosscher  2012-08-26 
23:41:41 UTC ---
Created attachment 28088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28088
Somewhat reduced, preprocessed test case

On x86_64, compile with:

$ ./cc1plus -m32 -quiet -ftime-report -std=gnu++98 -O2 -g2 PR53958.cc

With 1 "HUN" line I have:

 var-tracking dataflow   :   1.54 (24%) usr
 var-tracking emit   :   1.58 (25%) usr
 TOTAL :   6.43


With 2 "HUN" lines, this changes to:

 var-tracking dataflow   :   9.19 (37%) usr
 var-tracking emit   :   8.85 (36%) usr
 TOTAL :  24.86


With 3 "HUN" lines, things begin to get really ugly:

 var-tracking dataflow   :  33.39 (43%) usr
 var-tracking emit   :  31.79 (41%) usr
 TOTAL :  77.44

With 4 "HUN lines, the last test I ran, the timings are:

 var-tracking dataflow   :  69.47 (80%) usr
 var-tracking emit   :   0.03 ( 0%) usr
 TOTAL :  87.2495353 kB

So both the var-tracking dataflow and note emitting initially show quadratic
behavior for this test case, but the emitting appears to have some kind of
cut-off to make it disappear for the last test:

PR53958.cc: In function 'void
construct_core_types(simple_list&)':
PR53958.cc:234:6: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
 void construct_core_types(simple_list &typelist)

This limit is never reached in the original test case.

[Bug lto/54380] Lto bootstrap fails on i686-pc-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-08-26 
23:50:36 UTC ---
This is the attribute target causing issues with LTO.

[Bug lto/54380] Lto bootstrap fails on i686-pc-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Andrew Pinski  2012-08-26 
23:51:17 UTC ---
Dup of bug 45475

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

[Bug lto/45475] target use in libcpp breaks LTO bootstrap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||juhani.viherakoski at gmail
   ||dot com

--- Comment #14 from Andrew Pinski  2012-08-26 
23:51:17 UTC ---
*** Bug 54380 has been marked as a duplicate of this bug. ***

[Bug fortran/54382] New: gfortran show_locus: Invalid read of size 4

[burnus at gcc dot gnu.org]

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

 Bug #: 54382
   Summary: gfortran show_locus: Invalid read of size 4
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


For the following program, valgrind shows:

Invalid read of size 4
at 0x57BD98: _ZL10show_locusP5locusii.isra.3 (error.c:392)
by 0x57C3D5: error_print(char const*, char const*, __va_list_tag*)
(error.c:661)
by 0x57CEF8: gfc_error(char const*, ...) (error.c:956)
by 0x5C3296: match_complex_part(gfc_expr**) (primary.c:1205)


The program consists of the two lines:
!--
r =
  (r + m)
end
!--

Namely, the first line has 101 characters. It is crucial for this valgrind
warning that the line is very long.

The warning is printed for
   292  show_locus (locus *loc, int c1, int c2)
...
   309lb = loc->lb;
...
   388p = &(lb->line[offset]);
   389for (i = 0; i <= cmax; i++)
   390  {
   391int spaces, j;
   392spaces = gfc_widechar_display_length (*p++);

where offset == 21 and, initially, c1 == 96 and c2 == -1.