[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7/4.8 Regression]
   |std::string::append() fails |std::string::assign() fails
   |to update length|to update length

--- Comment #3 from Jonathan Wakely  2012-08-29 
07:35:36 UTC ---
For some reason my fingers keep typing append when I mean assign.

s/append/assign/g

[Bug c++/54401] New: Missing diagnostics about type-alias at class scope

[gdr at gcc dot gnu.org]

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

 Bug #: 54401
   Summary: Missing diagnostics about type-alias at class scope
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org


The following simple and innocuous (ill-formed)
programs leads g++ in C++11 mode to produce a
very misleading unhelpful diagnostic:

gauss[3:28]% cat b.C
template
struct X {
   using type = T;
};

When compiled with g++ in C++11 mode, I get:

gauss[3:32]% ~/gnu/bin/g++ -std=c++11 b.C 
b.C:3:10: error: expected nested-name-specifier before 'type'
using type = T;
  ^
b.C:3:10: error: using-declaration for non-member at class scope
b.C:3:15: error: expected ';' before '=' token
using type = T;
   ^
b.C:3:15: error: expected unqualified-id before '=' token


(you need monospace fonts to make sense of the carets in the diagnostics)

The real problem is that `T' is undeclared (presumably a template
type parameter.)  

I would expect the compiler to accept the syntax as a valid 
alias declaration, and complain later that `T' isn't in scope.
In short it should be semantics error, not a parse error.

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

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

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2012-08-29 
09:18:01 UTC ---
Test case by Wolfgang Kilian in the "Function questions?" thread:
https://groups.google.com/d/msg/comp.lang.fortran/r4PVbtaBnFM/hufoSWKHDBIJ

When handling the deallocation, we need to ensure that also the FINAL wrapper
properly handles it.

[Bug debug/54402] New: [4.8 Regression] var-tracking does not scale

[steven at gcc dot gnu.org]

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

 Bug #: 54402
   Summary: [4.8 Regression] var-tracking does not scale
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


A C test case for another var-tracking issue:

typedef struct astruct_d
{
  void *data;
} astruct;

/* Generate a whole bunch of unique fake mallocs, this
   keeps the vartrack dump simpler to understand (all
   the "size" arguments have a unique name).  */
#define DE0(X)  \
  void *malloc##X (unsigned long size##X);
#define DE1(X)  \
  DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
  DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X)  \
  DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
  DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X)  \
  DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
  DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X)  \
  DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
  DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
#undef DE0
#undef DE1
#undef DE2
#undef DE3
#undef DE4

void foo (void)
{
/* Now call all those mallocs and generate a series of
   variables while at it.  */
#define DE0(X)  \
  astruct *A##X = (astruct *) malloc##X(sizeof (astruct));
#define DE1(X)  \
  DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
  DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X)  \
  DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
  DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X)  \
  DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
  DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X)  \
  DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
  DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
DE4(1)
}

-->

 var-tracking dataflow   :  34.51 (33%) usr
 var-tracking emit   :  59.46 (57%) usr

[Bug debug/54402] [4.8 Regression] var-tracking does not scale

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-29
 CC||aoliva at gcc dot gnu.org
  Known to work||4.3.2
 Ever Confirmed|0   |1
  Known to fail||4.8.0

[Bug c++/54403] New: [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler

[ripper-tm at yandex dot ru]

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

 Bug #: 54403
   Summary: [C++11] operator! applied to a member of a templated
class in a lambda expression that captures 'this'
pointer crashes compiler
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ripper...@yandex.ru


Created attachment 28097
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28097
Source code

operator! applied to a member of a templated class in lambda that captures this
pointer crashes g++-4.7.1:

$ g++-4.7.1 bug.cpp -c --std=c++0x
bug.cpp: In lambda function:
bug.cpp:10:27: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions. 

$ g++-4.7.1 --version
g++-4.7.1 (Gentoo 4.7.1 p1.0, pie-0.5.3) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ emerge -pv gcc
...
[ebuild   R   #] sys-devel/gcc-4.7.1  USE="cxx fortran mudflap multislot nls
nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -go -graphite
-gtk (-hardened) (-libssp) (-multilib) -nocxx -nopie -nossp -objc -objc++
-objc-gc -test -vanilla" 36 kB

[Bug target/54404] New: [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186789

[dominiq at lps dot ens.fr]

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

 Bug #: 54404
   Summary: [4.8 Regression] *cfstring* failures for (obj-c|g)++
on *-apple-darwin* after revision 186789
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: howa...@bromo.med.uc.edu, ia...@gcc.gnu.org,
mikest...@comcast.net
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*


This is a follow up of pr53283 for the remaining failures of some *cfstring*
tests on *-apple-darwin* after revision 186789:

FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98  (test for errors, line 21)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98  (test for errors, line 22)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11  (test for errors, line 21)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11  (test for errors, line 22)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (test for excess errors)

FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for
warnings, line 22)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for
warnings, line 23)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for
warnings, line 25)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for
warnings, line 26)

The errors are

Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:13:79: error:
CFString literal expression is not a string constant
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:13:79: error:
CFString literal expression is not a string constant

or

/opt/gcc/work/gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm: In function
'void foo()':
/opt/gcc/work/gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm:21:18:
warning: non-ASCII character in CFString literal [--CLASSPATH]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm:24:18:
warning: embedded NUL in CFString literal [--CLASSPATH]

i.e., missing warnings for obj-c++.

[Bug c++/54403] [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler

[ripper-tm at yandex dot ru]

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

--- Comment #1 from Pavel  2012-08-29 10:38:21 UTC 
---
This is a regression. 4.6.3 works well.

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[michael.haubenwallner at salomon dot at]

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

--- Comment #4 from Michael Haubenwallner  2012-08-29 10:50:22 UTC ---
(In reply to comment #0)

Extending the testcase shows even more bad behavior in 4.4.3 and earlier:

#include 
#include 

int main()
{
std::string s1, s2;
s1.assign(s2.c_str(), 1);
assert( s1.size() == 1 );

std::string s3;
assert( s3.size() == 0 ); // up to gcc-4.4.3 fail here
}

[Bug fortran/54405] New: bad debugging info which lead to a wrong behavior of reverse-next in gdb

[Edouard.Canot at irisa dot fr]

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

 Bug #: 54405
   Summary: bad debugging info which lead to a wrong behavior of
reverse-next in gdb
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: edouard.ca...@irisa.fr


Created attachment 28098
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28098
short fortran source file used in the example

Reverse debugging works badly with the attached fortran source file, at least
when using GCC 4.6.3 and GCC 4.7.1.

More precisely, during debugging, the first use of the 'reverse-next' command
(after using record, of course), makes the debugger jump back the first line
where the 'record' command was applied; for example:

===

(gdb) break MAIN__
Breakpoint 1 at 0x402f87: file essai_1.f90, line 3.
(gdb) run
Starting program: .../essai_1 

Breakpoint 1, essai_1 () at essai_1.f90:3
3   x = 1.0
(gdb) record
(gdb) n
4   print *, "x = ", x
(gdb) n
 x =1.
6   x = 2.5
(gdb) n
7   print *, "x = ", x
(gdb) n
 x =2.5000
9   x = 3.14159265
(gdb) n
10   print *, "x = ", x
(gdb) n
 x =3.14159274
12end program
(gdb) reverse-next
4   print *, "x = ", x

==

The behavior is correct with GCC 4.5.4, so I think it is a regression problem.

The problem has been detected with gdb-7.4 and gdb-7.5.

[Bug fortran/54406] New: random_number() sometimes returns duplicate values when called from parallel threads

[bugzilla.tmschr at wronghead dot com]

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

 Bug #: 54406
   Summary: random_number() sometimes returns duplicate values
when called from parallel threads
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla.tms...@wronghead.com


When called from an OMP parallel section (e.g. $OMP parallel do), the
random_number() intrinsic occasionally returns the same value twice in
succession.

I've attached a simple test program, to be compiled with:
   gfortran -fopenmp rnd.f08

Some quick statistics showed that the effect is less when:
 - directly using random_number() in the main loop,
 - using a static schedule, and/or
 - omitting the (useless) inner loop.

The effect vanishes when using 'print*,fct()' directly, i.e. omitting storage
or the return value in variable r.

For BASH users, there's a simple and obvious script to get some statistics on
the number of duplicated values:
   while true; do echo "10-`./a.out|uniq|wc -l`" | bc; done

I quote from "Using GNU Fortran":
"Please note, this RNG is thread safe if used within OpenMP directives, i.e.,
its state will be consistent while called from multiple threads. However, the
KISS generator does not create random numbers in parallel from multiple
sources, but in sequence from a single source. If an OpenMP-enabled application
heavily relies on random numbers, one should consider employing a dedicated
parallel random number generator instead."

While I understand that the period is finite, it says that "The overall period
exceeds 2^123", i.e. ca. 1.06E37.

Thus, to my understanding, duplication of values should never happen even when
considering all the caveats mentioned.

[Bug fortran/54406] random_number() sometimes returns duplicate values when called from parallel threads

[bugzilla.tmschr at wronghead dot com]

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

--- Comment #1 from bugzilla.tmschr at wronghead dot com 2012-08-29 12:39:55 
UTC ---
Created attachment 28099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28099
Test to check for duplicate random numbers

Changing variable M may in-/decrease the effect. On my machine, the program -
as is - put out about 10 out of 100,000 duplicate values on average.

[Bug debug/54395] GCC should be able to put DWARF tables in a non-mapped/strippable section for debug-only use

[bugdal at aerifal dot cx]

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

--- Comment #6 from Rich Felker  2012-08-29 12:43:23 
UTC ---
I seem to remember gcc -g -fno-asynchronous-unwind-tables -fno-unwind-tables
producing a warning that these options are incompatible and that debugging will
not work, but at the moment it seems to be doing the right thing. Was I
imagining things or are there some gcc versions where the combination is
problematic?

I'd like to investigate the situation/behavior a bit longer before closing this
bug, but it seems like you may have provided a solution. If this solution does
work, however, I still think the documentation is lacking; it's not clear that
these options would not remove the tables in a way that interferes with
debugging.

[Bug fortran/54405] bad debugging info which lead to a wrong behavior of reverse-next in gdb

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-08-29 
13:04:13 UTC ---
If one generates the line information using
  gfortran -fdump-tree-original-lineno debug.f90
and looks at debug.f90.003t.original, it - kind of - looks fine.

(-fdump-tree-original-lineno generates a dump of the internal representation,
which is C like and does *not* contain the full information.)


Of course, in "main", it would be nice to have the _set_*/essai_1() referring
to line 1 and only "return 0" to line 12, but otherwise ...

At least I do not see anything which looks wrong. The only difference I see is
the outer  { ... } which has line number 12 in 4.6/4.7/4.8 and is not existing
in 4.5. As there is no code associated with it, I don't think it should cause
problems.

(That { ... } belongs to TRY_FINALLY_EXPR, which is used, e.g., for automatic
deallocation when leaving the scope.)


Nonetheless, it is completely unclear to me why gdb jumps from line 12 to line
4 - and not to line 10 (or even line 3).

Do you see something else which looks wrong?


essai_1 ()
[debug.f90 : 12] {
  real(kind=4) x;

  [debug.f90 : 3] x = 1.0e+0;
  [debug.f90 : 4] {
struct __st_parameter_dt dt_parm.0;

[debug.f90 : 4] dt_parm.0.common.filename = &"debug.f90"
[debug.f90 : 4] dt_parm.0.common.line = 4;
[debug.f90 : 4] dt_parm.0.common.flags = 128;
[debug.f90 : 4] dt_parm.0.common.unit = 6;
_gfortran_st_write ([debug.f90 : 4] &dt_parm.0);
[debug.f90 : 4] _gfortran_transfer_character_write (&dt_parm.0,  &"x =");
[debug.f90 : 4] _gfortran_transfer_real_write (&dt_parm.0, &x, 4);
[debug.f90 : 4] _gfortran_st_write_done (&dt_parm.0);
  }
  [debug.f90 : 6] x = 2.5e+0;
...
  [debug.f90 : 10] _gfortran_st_write_done ([debug.f90 : 10] &dt_parm.2);
  }
}

main (integer(kind=4) argc, character(kind=1) * * argv)
[debug.f90 : 12] {
  static integer(kind=4) options.3[7] = {68, 1023, 0, 0, 1, 1, 0};

  [debug.f90 : 12] _gfortran_set_args (argc, argv);
  [debug.f90 : 12] _gfortran_set_options (7, [debug.f90 : 12] &[debug.f90 : 12]
options.3[0]);
  [debug.f90 : 12] essai_1 ();
  [debug.f90 : 12] return 0;
}

[Bug fortran/54406] random_number() sometimes returns duplicate values when called from parallel threads

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2012-08-29 
13:16:36 UTC ---
How about replacing
  !$OMP parallel do schedule(dynamic)
by
  !$OMP parallel do schedule(dynamic) private(r)

[Bug target/54407] New: FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

 Bug #: 54407
   Summary: FAIL: 30_threads/condition_variable/54185.cc execution
test  program timed out on powerpc-apple-darwin9 and
x86_64-apple-darwin10
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: howa...@bromo.med.uc.edu, ia...@gcc.gnu.org,
r...@gcc.gnu.org
  Host: powerpc-apple-darwin9 x86_64-apple-darwin10
Target: powerpc-apple-darwin9 x86_64-apple-darwin10
 Build: powerpc-apple-darwin9 x86_64-apple-darwin10


On powerpc-apple-darwin9 and x86_64-apple-darwin10, the test
30_threads/condition_variable/54185.cc is timed out (from
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02572.html this does seem to
occur on x86_64-apple-darwin12.2.0). Sampling the run after ~40 minutes gives:

Sampling process 47649 for 3 seconds with 1 millisecond of run time between
samples
Sampling completed, processing symbols...
Analysis of sampling a.out (pid 47649) every 1 millisecond
Process: a.out [47649]
Path:/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out
Load Address:0x1
Identifier:  a.out
Version: ??? (???)
Code Type:   X86-64 (Native)
Parent Process:  tcsh [418]

Date/Time:   2012-08-26 22:04:25.062 +0200
OS Version:  Mac OS X 10.6.8 (10K549)
Report Version:  6

Call graph:
2130 Thread_27669825   DispatchQueue_1: com.apple.main-thread  (serial)
  2130 start
2130 main
  2130 std::thread::join()
2130 pthread_join
  2130 __semwait_signal
2130 Thread_27669827
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669828
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669829
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669830
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669831
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669832
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669833
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock
2130 Thread_27669834
  2130 thread_start
2130 std::condition_variable::wait(std::unique_lock&)
  2130 __spin_lock

Total number in stack (recursive counted multiple, when >=5):
8   __spin_lock
8   std::condition_variable::wait(std::unique_lock&)
8   thread_start

Sort by top of stack, same collapsed (when >= 5):
__spin_lock17040
__semwait_signal2130

Binary Images:
   0x1 -0x11ff7 +a.out ??? (???)
<1BA5F363-960B-6D52-5641-2CE7E1635197>
/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out
   0x17000 -0x1000abfe7 +libstdc++.6.dylib 7.17.0
(compatibility 7.0.0) <58262B92-ECCD-BD30-9402-ED87BC90A8EB>
/opt/gcc/gcc4.8w/lib/libstdc++.6.dylib
   0x100138000 -0x10014cfef +libgcc_s.1.dylib ??? (???)
<91DF981B-4585-E9BF-8747-487D8A834B9D> /opt/gcc/gcc4.8w/lib/libgcc_s.1.dylib
0x7fff5fc0 - 0x7fff5fc3bdef  dyld 132.1 (???)
 /usr/lib/dyld
0x7fff80d89000 - 0x7fff80f4afef  libSystem.B.dylib 125.2.11
(compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69>
/usr/lib/libSystem.B.dylib
0x7fff892a9000 - 0x7fff893a1ff7  libiconv.2.dylib 7.0.0 (compatibility
7.0.0) <7E4ADB5A-CC77-DCFD-3E54-2F35A2C8D95A> /usr/lib/libiconv.2.dylib
0x7fff89728000 - 0x7fff8972cff7  libmathCommon.A.dylib 315.0.0
(compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5>
/usr/lib/system/libmathCommon.A.dylib
0x7fe0 - 0x7fe01fff  libSystem.B.dylib ??? (???)
<9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
Sample analysis of process 47649 written to file /dev/stdout

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  2012-08-29 
13:39:38 UTC ---
Adding Paolo for his comments, since he seems to be the author of the vstring
code.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  2012-08-29 
13:43:16 UTC ---
Created attachment 28100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28100
Trunk version of the vstring patch

Here's a trunk version of Adhemerval's vstring patch.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-08-29 
13:53:23 UTC ---
No, I'm sorry, we are not going to do that for vstring. Remember that vstring
is just a preview of the new std::string implementation for when we break the
ABI. We are not going to add symbols and make things more complex for it. The
core issue is trivial, of course, when vstring will be "promoted" to main
string implementation will get the optimizations and everything else.

[Bug fortran/54406] random_number() sometimes returns duplicate values when called from parallel threads

[bugzilla.tmschr at wronghead dot com]

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

--- Comment #3 from bugzilla.tmschr at wronghead dot com 2012-08-29 13:55:46 
UTC ---
Sorry for this report!!!1!!eleven! You're right, that fixes it. The fault is
clearly not with the random_number instrinsic.

I've been searching for a bug in a large program for days now and obviously was
a bit too desperate to find an easy explanation. I'm getting more and more
confident the bug is in myself... :(

[Bug other/54408] New: sqrt for vector types

[glisse at gcc dot gnu.org]

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

 Bug #: 54408
   Summary: sqrt for vector types
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


Hello,

it would be nice to add sqrt to the gcc vector extensions. There are already
target specific builtins, but a generic one would fit better (and get lowered
to elementwise sqrt when the target doesn't support vector sqrt). I don't know
if __builtin_sqrt should be extended, or maybe a different __builtin_vec_sqrt.

Component "other" because fixing this might involve front, middle and
back-ends.

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-08-29 
14:15:58 UTC ---
Jon, didn't we somehow discuss this issue already, in a slightly different form
(the issue of course was less evident pre that fix)? Thus, if I remember
correctly what I was thinking at that time, a good general and safe fix would
be tweaking a bit _M_disjunct, making it more careful so to speak, thus
considering the address of the source as overlapping also if it corresponds to
the '\0' at the end of destination. The philosophy in other terms is
"preserving" the whole internal buffer, thus '\0' included. Matter of adding a
+ 1 somewhere, in other terms ;) If my analysis is correct, the fix would work
as a special case for the test here involving empty reps, and I think it's the
safe fix we want for the current std::string implementation at this stage.

[Bug fortran/54406] random_number() sometimes returns duplicate values when called from parallel threads

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Tobias Burnus  2012-08-29 
14:19:49 UTC ---
Close as INVALID.

Good luck finding the issue with your big program!

[Bug c/54409] New: internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jim at meyering dot net]

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

 Bug #: 54409
   Summary: internal compiler error: in remap_predicate, at
ipa-inline-analysis.c:2710
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net


I happened to have the latest gcc in my shell's search path
when testing a linux kernel change, and fs/cifs/connect.c provoked
this internal error:

the exact version of GCC: gcc version 4.8.0 20120829 (experimental) (GCC)
the system type: x86_64 (Fedora 17)
the options given when GCC was configured/built:
CC=/usr/bin/gcc $srcdir/configure --prefix=$prefix --disable-multilib \
   --disable-libmudflap --disable-nls --enable-languages='c go'
make bootstrap

the complete command line that triggers the bug:
$ gcc -Iarch/x86/include -Iarch/x86/include/generated -Iinclude \
-include include/linux/kconfig.h -D__KERNEL__ -Os -c -o fs/cifs/connect.o \
fs/cifs/connect.c

the compiler output (error messages, warnings, etc.):
fs/cifs/connect.c:4302:1: internal compiler error: in remap_predicate, at
ipa-inline-analysis.c:2710
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

the preprocessed file (*.i*): Attached.

[Bug c/54409] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jim at meyering dot net]

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

--- Comment #1 from jim at meyering dot net 2012-08-29 14:40:35 UTC ---
Created attachment 28101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28101
connect.i from heavily pared-down connect.c

[Bug c/54409] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jim at meyering dot net]

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

jim at meyering dot net changed:

   What|Removed |Added

Version|unknown |4.8.0

--- Comment #2 from jim at meyering dot net 2012-08-29 14:41:52 UTC ---
note that this affects latest from git: 4.8.0

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-08-29 
14:47:28 UTC ---
Nope, I checked and _M_disjunct seems already Ok. The issue is actually with
the logic in assign when _M_disjunct is false: it assumes we are simply
overwriting things and no memory allocation needed.

[Bug c++/54277] Template class member referred to with implicit this inside lambda is incorrectly const-qualified

[leo at yuriev dot ru]

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

Leo Yuriev  changed:

   What|Removed |Added

 CC||leo at yuriev dot ru

--- Comment #2 from Leo Yuriev  2012-08-29 14:54:15 UTC 
---
+1, just confirm

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2012-08-29 
15:13:57 UTC ---
Thus, I guess the right thing to do is sort-of the other way around of what I
was thinking: change _M_disjunct in such a way that when the destination is the
empty rep it always returns true, thus we first allocate memory for the
destination and then copy the '\0' to it and everything is fine (nothing bad
can happen to the source in this special case because the empty rep source
isn't in dynamically allocated memory, thus isn't deallocated, it stays in
memory forever).

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[michael.haubenwallner at salomon dot at]

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

--- Comment #8 from Michael Haubenwallner  2012-08-29 15:20:50 UTC ---
Actually, valgrind does show an "Invalid write of size 1" for this testcase,
unrelated to the default string at all:

{
  std::string s1 = "a";
  s1.assign(s1.c_str(), 2);
}

So I'm proposing this fix here:

--- basic_string.tcc.orig   2012-08-29 17:12:53.349220855 +0200
+++ basic_string.tcc2012-08-29 17:13:37.021326394 +0200
@@ -262,7 +262,7 @@
 {
   __glibcxx_requires_string_len(__s, __n);
   _M_check_length(this->size(), __n, "basic_string::assign");
-  if (_M_disjunct(__s) || _M_rep()->_M_is_shared())
+  if (_M_disjunct(__s) || _M_rep()->_M_is_shared() || this->size() < __n)
return _M_replace_safe(size_type(0), this->size(), __s, __n);
   else
{

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #7 from Peter Bergner  2012-08-29 
15:23:45 UTC ---
Ok, I knew that vstring was going to be used for the next std::string, so if
this will be fixed trivially once we make the switch, then that is good enough
for us.  I just wanted to make sure it would be fixed once we make the change. 
Thanks.

[Bug debug/54410] New: doubled DW_TAG_template_type_param

[tromey at gcc dot gnu.org]

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

 Bug #: 54410
   Summary: doubled DW_TAG_template_type_param
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org


I'm using a relatively recent git gcc:

commit d789d72be457df9811328179702cab8ac5830465
Author: walt 
Date:   Mon Aug 27 17:27:04 2012 +


I compiled this program, derived from a libstdc++ test case:

#include 
#include 

typedef std::unordered_set Set;
Set m;

int main()
{
}


The DWARF shows duplicate template arguments for unordered_set.
I think each parameter name should appear just a single time:

 <3><38a8>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38a9>   DW_AT_name: (indirect string, offset: 0x6e7): _Value
<38ad>   DW_AT_type: <0x1d44>
 <3><38b1>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38b2>   DW_AT_name: (indirect string, offset: 0x6f29): _Hash
<38b6>   DW_AT_type: <0x379c>
 <3><38ba>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38bb>   DW_AT_name: (indirect string, offset: 0x9ebb): _Pred
<38bf>   DW_AT_type: <0x3934>
 <3><38c3>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38c4>   DW_AT_name: (indirect string, offset: 0x7826): _Alloc
<38c8>   DW_AT_type: <0x453a>
 <3><38cc>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38cd>   DW_AT_name: (indirect string, offset: 0x6e7): _Value
<38d1>   DW_AT_type: <0x1d44>
 <3><38d5>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38d6>   DW_AT_name: (indirect string, offset: 0x6f29): _Hash
<38da>   DW_AT_type: <0x379c>
 <3><38de>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38df>   DW_AT_name: (indirect string, offset: 0x9ebb): _Pred
<38e3>   DW_AT_type: <0x3934>
 <3><38e7>: Abbrev Number: 46 (DW_TAG_template_type_param)
<38e8>   DW_AT_name: (indirect string, offset: 0x7826): _Alloc
<38ec>   DW_AT_type: <0x453a>

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2012-08-29 
15:28:45 UTC ---
Ok, I see. The problem is that when the source is inside the destination, we
may be copying one more char, the final '\0', than the current size and
overflow the allocated memory. We need reallocation in this case too. But we
can't just follow the path of _M_replace_safe, because it deallocates the
source! This case is harder to fix than the empty rep special case.

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2012-08-29 
15:32:29 UTC ---
Note that the last snippet definitely caused problems even before the recent
changes. Can't be a regression. Given the current status of the implementation
I'm not sure if is worth fixing right now.

[Bug c/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-29
 CC||mjambor at suse dot cz
   Target Milestone|--- |4.8.0
Summary|internal compiler error: in |[4.8 Regression] internal
   |remap_predicate, at |compiler error: in
   |ipa-inline-analysis.c:2710  |remap_predicate, at
   ||ipa-inline-analysis.c:2710
 Ever Confirmed|0   |1

--- Comment #3 from H.J. Lu  2012-08-29 15:42:48 
UTC ---
Need -Os to reproduce.  It is caused by revision 190313:

http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00290.html

[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|fatigue2 -flto run time |[4.8 Regression] fatigue2
   |regression  |-flto run time regression

--- Comment #1 from Dominique d'Humieres  2012-08-29 
15:46:58 UTC ---
I see something similar on x86_64-apple-darwin10, but with -fwhole-program and
not with -flto:
i.e., with -Ofast before or after r190346 the run time is ~150s and does not
change with -flto.
At r190345 and before, the run time with -fwhole-program is ~100s (and ~56s
with --param max-inline-insns-auto=98 -funroll-loops), while it is ~142s at
r190346 and after.

[Bug c/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #4 from Markus Trippelsdorf  
2012-08-29 16:05:50 UTC ---
Somewhat reduced:

struct list_head
{
struct list_head *prev;
};
struct sockaddr_in6
{
int sin6_addr;
}
;
struct __kernel_sockaddr_storage
{
}
;
struct TCP_Server_Info
{
struct list_head tcp_ses_list;
struct __kernel_sockaddr_storage srcaddr;
};
int b;
_Bool
fn1 (int *p1)
{
long *a = (long *) p1;
return a[1];
}

static _Bool
fn2 (int *p1)
{
switch (b)
case 0:
{
struct sockaddr_in6 *c = (struct sockaddr_in6 *) &p1;
return fn1 (&c->sin6_addr);
}
}

_Bool
fn3 (struct TCP_Server_Info * p1)
{
if (fn2 ((int *) &p1->srcaddr))
return 0;
}

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2012-08-29 
16:20:43 UTC ---
I'm sorry, you are right - it's been a while since the last time I looked into
this code - going that way of the conditional is Ok, because the memory
corresponding to the source (which coincide with that of the destination
string) is deallocated only after all the chars are copied. Good. Thus it means
that in general, we want, again to change _M_disjoint not to check that the
destination is the empty rep, but precisely for this more general case, that
is, the source begin is the same as the this->begin() beginning, and the size
is this->size() + 1 and return true. We have to add an overload, because the
current one doesn't take the size of the source. I think this is it.

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2012-08-29 
16:53:02 UTC ---
Nope, unfortunately I remembered correctly: if we call _M_replace_safe for
these cases the new chars are copied at the very end. At that point, the
destination string is already reallocated but in these cases it's also the
source string and __s doesn't point anymore to it. _M_replace_safe is exactly
for when __s remains a valid address for the source chars from beginning to end
of the whole operation.

[Bug c/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[polacek at redhat dot com]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||polacek at redhat dot com

--- Comment #5 from Marek Polacek  2012-08-29 
17:07:04 UTC ---
More reduced.  Reproducible with -Os and -O1.

int b;

struct S
{
  char *p; 
  struct {
  } s;
  int a;
};

static _Bool
fn2 (int *p1)
{
  if (b) 
{   
  struct S *c = (struct S *) &p1;
  return c->a;
}   
}

_Bool
fn3 (struct S *p1)
{
  if (fn2 ((int *) &p1->s))
return 0;
}

[Bug other/54411] New: libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[fw at gcc dot gnu.org]

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

 Bug #: 54411
   Summary: libiberty: objalloc_alloc integer overflows
(CVE-2012-3509)
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: f...@gcc.gnu.org
ReportedBy: f...@gcc.gnu.org


Sang Kil Cha discovered that _objalloc_alloc does not guard the addition of
CHUNK_HEADER_SIZE to the length against overflow.  This can cause
_objalloc_alloc to return a pointer to a memory region which is smaller than
expected.

The pointer alignment arithmetic in the objalloc_alloc macro misses an overflow
check as well, with similar consequences.

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-29
 Ever Confirmed|0   |1

--- Comment #1 from Florian Weimer  2012-08-29 17:12:02 
UTC ---
I'll come up with a patch for both issues (I don't think there is one yet).

[Bug c/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Jambor  2012-08-29 
18:26:32 UTC ---
Confirmed and mine.  Thanks for the simple testcase.

[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-08/msg01991.htm
   ||l
   Last reconfirmed||2012-08-29
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Martin Jambor  2012-08-29 
18:28:41 UTC ---
I have posted a fix to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01991.html

You can try whether it fixes your regression too.

[Bug libmudflap/24420] mudflap doesnt work with DSOs?

[roucaries.bastien+bugs at gmail dot com]

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

Bastien ROUCARIES  changed:

   What|Removed |Added

 CC||roucaries.bastien+bugs at
   ||gmail dot com

--- Comment #5 from Bastien ROUCARIES  
2012-08-29 18:46:35 UTC ---
Bug is still here... Care to fix ?

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[olegendo at gcc dot gnu.org]

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

--- Comment #34 from Oleg Endo  2012-08-29 
19:05:35 UTC ---
Christian, regarding your message on the patches list:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01861.html

I ended up 'fixing' the issue by folding the patterns with iterators. 
Committed with other foldings as rev. 190781.
There are now 3 patterns: "*movsi_index_disp_load", "*movhi_index_disp_load",
"*mov_index_disp_store".

On a related matter... I've been thinking about PR 50749 (auto-inc-dec
opportunities) and PR 53911 (displacement addressing base address selection).
As far as I understand it, the proper way of fixing those would be implementing
something like General Offset Assignment (GOA) or Address Register Assignment
(ARA).  Just to see how it could be done, I've replaced the auto-inc-dec pass
with my own very early prototype implementation for optimizing address mode
selection (currently only with SH addr modes in mind, but could be extended to
apply to other targets, too).
I'm not sure whether I will be able to get it into shape for 4.8, but early
results show that it conflicts with the combine patterns introduced in the
fixes for this PR, as it would try to turn the scaled index + displacement
addresses into post-inc addresses or normal displacement addresses.  The
problem here is that SH officially does not support scaled index + displacement
addressing, and address mode selection / auto-inc-dec is done before combine.

Anyway, until the proper way has been figured out the combine patterns should
do as a temporary fix.  BTW, DImode and SFmode/DFmode for SH2A are still
missing ...

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2012-08-29 19:09:55 UTC ---
You do realise that pretty much nothing in the toolchain checks for 
overflows in calculating allocation sizes?  If you want to fix such 
issues more systematically, the macros in libiberty.h such as XNEWVEC 
would be a good starting point in which to insert overflow checks, but 
there will be loads of other places affected as well.

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  2012-08-29 19:18:58 
UTC ---
(In reply to comment #2)
> You do realise that pretty much nothing in the toolchain checks for 
> overflows in calculating allocation sizes?

bfd_alloc2 (bfd's XNEWVEC variant) contains an overflow check, and this bug
defeats it.

Your point about XNEWVEC is appreciated, but this is a different bug. 8-)

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2012-08-29 21:29:12 UTC ---
On Wed, 29 Aug 2012, fw at gcc dot gnu.org wrote:

> > You do realise that pretty much nothing in the toolchain checks for 
> > overflows in calculating allocation sizes?
> 
> bfd_alloc2 (bfd's XNEWVEC variant) contains an overflow check, and this bug
> defeats it.
> 
> Your point about XNEWVEC is appreciated, but this is a different bug. 8-)

My point is that there are probably hundreds of such bugs in the toolchain 
sources (and lots more bugs where BFD and GDB fail to handle invalid 
input); XNEWVEC is just an example of one that's comparatively easy to 
find and fix (but I'm sure plenty more are easy to find for anyone going 
looking for them).

[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-08-29 
21:30:45 UTC ---
> You can try whether it fixes your regression too.

Yes, it does. Thanks.

Did you check if you get the same run time with -flto and -fwhole-program? If
yes, it would probably mean that -flto is not working as it should on darwin.
How could I check that?

[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-29
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-08-29 
22:42:54 UTC ---
delete_related_insns isn't supposed to do incorrect things though, so the issue
must really be analyzed first.

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2012-08-29 
23:21:25 UTC ---
In fact, considering this issue a regression seems a bit of an over stretch to
me: the empty rep case used to work essentially be chance, it's just a very
special case (... of a very special case, which nobody bothered to report about
in some 10 years). If you ask me, I would not handle this for std::string and
fix it instead in vstring (where, by the way, a fix is straightforward and
localized to _M_replace, I'll take care of that ASAP)

[Bug bootstrap/43328] multilib bootstrap broken.

[jmesmon at gmail dot com]

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

--- Comment #22 from Cody Schafer  2012-08-29 
23:47:24 UTC ---
Created attachment 28102
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28102
gcc-fix-multib-hostargs.patch

This patch fixes the bug by only adding --*-multilib options to baseargs and
not tbaseargs.

[Bug bootstrap/43328] multilib bootstrap broken.

[jmesmon at gmail dot com]

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

Cody Schafer  changed:

   What|Removed |Added

 CC||jmesmon at gmail dot com

--- Comment #23 from Cody Schafer  2012-08-29 
23:49:04 UTC ---
Sorry, I inverted my previous comment, should be:

> This patch fixes the bug by only adding --*-multilib options to tbaseargs and 
> not baseargs.

ie, "tbaseargs" & "baseargs" were swapped

[Bug testsuite/54397] [regression] gfortran.dg/guality/pr41558.f90

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2012-08-30 00:14:36 UTC ---
On Tue, Aug 28, 2012 at 11:58:34PM +, kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54397
> 
> Reading symbols from
> /usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/pr41558.exe...done.
> Breakpoint 1 at 0x400b04: file
> /home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/guality/pr41558.f90, line 7.
> 
> Breakpoint 1, 0x00400b04 in f_ ()
> $1 = (, inf, -inf, -inf, -inf, )
> $2 = 'foo'
> A debugging session is active.
> 
> Inferior 1 [process 7463] will be killed.
> 
> Quit anyway? (y or n) [answered Y; input not from terminal]
> (, inf, -inf, -inf, -inf, ) != 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -O0  line 7 s == 'foo'
> 

The above failure is cause by 


r190543 | mark | 2012-08-20 13:27:46 -0700 (Mon, 20 Aug 2012) | 16 lines

dwarf2out.c: For DWARF 4+, output DW_AT_high_pc as constant offset.

* dwarf2out.h (enum dw_val_class): Add dw_val_class_high_pc.
* dwarf2out.c (dw_val_equal_p): Handle dw_val_class_high_pc.
(add_AT_low_high_pc): New function.
(AT_lbl): Handle dw_val_class_high_pc.
(print_die): Likewise.
(attr_checksum): Likewise.
(attr_checksum_ordered): Likewise.
(same_dw_val_p): Likewise.
(size_of_die): Likewise.
(value_format): Likewise.
(output_die): Likewise.
(gen_subprogram_die): Use add_AT_low_high_pc.
(add_high_low_attributes): Likewise.
(dwarf2out_finish): Likewise.

[Bug target/54412] New: Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

 Bug #: 54412
   Summary: Request for 32-byte stack alignment with -mavx on
Windows
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rcop...@gmail.com


Created attachment 28103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28103
Self-contained C source, with AVX alignment bug on Windows

Code generated by GCC 4.7.1 for the Windows x86_64-w64-mingw32 target, with
"-mavx", can segfault due to alignment errors when the 32-byte ymm registers
are spilled onto the stack. May I please submit a feature request for 32-byte
stack alignment on this target where necessary?

Compiled for Windows with "gcc -O0 -m64 -mavx bug.c" using GCC 4.7.1 with the
MingGW W64 toolchain, the attached program segfaults. Specifically, it uses
vmovapd to copy the value of %ymm0 to a location on the stack before calling
f(), but doesn't align the location to 32 bytes as required by that
instruction. In contrast, the generated code for Linux (using GCC 4.6.3 from
Ubuntu) does explicitly align the stack to 32 bytes.

The lack of stack alignment on Windows has been noted before; see for
example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001 and
http://stackoverflow.com/questions/5983389.

[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue

[foom at fuhm dot net]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #3 from James Y Knight  2012-08-30 02:39:31 
UTC ---
Ping; this seems like a serious regression in 4.7 with a patch.

I guess fixing it is blocked on Thiago posting the patch to gcc-patches?

[Bug testsuite/54397] [regression] gfortran.dg/guality/pr41558.f90

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #4 from Jakub Jelinek  2012-08-30 
06:07:00 UTC ---
You need a recent GDB, or at least a patch from it backported, to debug GCC 4.8
generated code.

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

[Bug debug/53671] [4.8 Regression] Many guality test failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  2012-08-30 
06:07:00 UTC ---
*** Bug 54397 has been marked as a duplicate of this bug. ***

[Bug testsuite/54397] [regression] gfortran.dg/guality/pr41558.f90

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  
2012-08-30 06:17:48 UTC ---
On Thu, Aug 30, 2012 at 06:07:00AM +, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54397
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  CC||jakub at gcc dot gnu.org
>  Resolution||DUPLICATE
> 
> --- Comment #4 from Jakub Jelinek  2012-08-30 
> 06:07:00 UTC ---
> You need a recent GDB, or at least a patch from it backported, to debug GCC 
> 4.8
> generated code.
> 

I have gdb 7.4.1 in /usr/local/bin and FreeBSD system gdb 
in /usr/bin is 6.1.1.   /usr/local/bin appears first in
my search path.  Do I need a version newer than 7.4.1?

Given that FreeBSD base system is gdb 6.1.1, it may 
be appropriate to either skip this test or XFAIL it.