[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[xinliangli at gmail dot com]

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

--- Comment #6 from davidxl  2012-04-13 05:01:56 
UTC ---
I think you indirectly proved my point (see below) :)

(In reply to comment #5)
> Maintainers (those who decide) are too few and they either do not care or do
> not have time to fix these things. Existing or new contributors that are paid
> to do something specific don't care about anything else as long as it doesn't
> interfere with their job (if it does, whatever improvement it may be, then 
> they
> are against it). I don't think there is any GCC contributor that is paid to
> improve GCC's diagnostics (am I wrong?).

Right, but partially because it is a hard thing to do improve and the ROI is
low.

> This is very different from Clang,
> where Chris obviously cares a great deal about Clang's diagnostics, and it
> seems to be supported by a team in Apple (and in Google?).

Yes, and in Google, but do you know why? Because it is easy to improve their
diagnostics and benefit can be quickly seen.

> 
> Contributors to GCC that care about these things, either unpaid or in their
> free time, are very few and completely overworked. It is true that the GCC 
> code
> base has a huge technical debt, but diagnostic fixes tend to be easy to fix, 
> if
> you have a little of experience. 

But Clang is even easier to hack on. Any person without any compiler background
can build tools on top of it. In other words, the bar of working on compiler
becomes very low -- and this is really exciting and attractive for developers
who used to think it as untouchable area to work on.

> However, there are a lot of them, and getting
> patches reviewed and accepted requires herculean amounts of perseverance. But
> probably you can share with me more about your (or Googlers) thoughts on the
> latter, since you have the experience of submitting the same project to both
> LLVM and GCC.

Infrastructure makes a big difference here -- see more about this below.

> 
> New contributors to GCC are almost non-existent (except those that are paid to
> work on very specific stuff, like a new port, but these new contributors also
> don't care about GCC in general, as long as it doesn't interfere with their
> job). The reasons why GCC fails to attract new contributors are very
> well-known: the copyright assignment is a major hurdle for casual/unpaid
> contributors, patches from new contributors are routinely ignored and the 
> patch
> review process is hostile to new contributors (in reality, much less than in
> the Linux kernel, but they have enough developers to afford being hostile).

I am aware of this.

> Interacting for the first time with GCC developers can easily discourage a lot
> of people (there is a whole page just on the subject!
> http://gcc.gnu.org/wiki/GCC_Research). In Clang for example, small obvious
> fixes proposed by new contributors without any changelog or even without a
> patch are often committed immediately. I have never seen this in +6 years
> contributing to GCC, on the contrary, the contributor will be asked to
> bootstrap, regtest, provide a Changelog, fix the Changelog, provide a patch,
> read the code style, fix the code style, some bikeshedding, and between each
> step, there may be weeks of no feedback at all.

The root cause is still GCC's older infrastructure. Lack of modern design 
leads to weird interactions between various components, lots of hidden
assumptions, lack of good verification etc -- all these lead to the problem you
mention -- GCC patches from new contributors are bound to be buggy or to
trigger other latent bugs here and there, which means the heavy weight process
in GCC is required. Being an expert in GCC requires years of knowledge
accumulation and hostility is bound to happen (and ironically really required
to ensure quality) because qualified reviewers are so few and it just does not
scale. 

Clang can afford to lower the bar for contributors because its infrastructure.

> 
> GCC also has a huge marketing problem, no overall vision, no clear leadership
> (it is easy to get contradictory answers by the people who decide), and GCC
> developers show both a lack of enthusiasm (just compare presentations by
> Clang/LLVM developers, full of amazing features, awesome graphics,
> never-seen-before numbers and LLVM webpages are full of how good their 
> compiler
> is, how much better than anything else, etc.) and a sense of superiority 

I think part of the reasons is that contributors in that community are much
younger on average (the requirement on contributor experience is lower). Young
kids tend to be very enthusiastic.

>("we
> don't want to be like Clang/LLVM! It produces slower code by 0.0001%! 

I will assure you the performance difference is much more than that.

>It
> doesn't support mmix-knuth-mmixware"). These kind of things are essential to
> attract new contributors, however, they do not seem to provide any advantage 
> to
> existing developers, and they are seen as pointless ex

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  2012-04-13 
03:29:25 UTC ---
(In reply to comment #2)
> One more thing regarding movco/movli ... do you think it's OK to use them also
> to do atomics on types < SImode?  As far as I can see it should be safe to do
> e.g. read SImode, modify QImode subreg, write-back SImode.

Yes, it'll make false-positive cases but would be safe.

[Bug c++/24985] caret diagnostics

[paolo.carlini at oracle dot com]

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

--- Comment #33 from Paolo Carlini  2012-04-13 
02:25:48 UTC ---
Thanks Manu for the reminder, I have a couple of pending things in my TODO and
then I will resurrect it for the great 'caret times' ;)

[Bug c/52946] Unable to define a Block variable

[lunfis at gmx dot de]

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

--- Comment #3 from Lund  2012-04-13 01:08:12 UTC ---
OK, my mistake. I did not realize Apple's gcc was that different.

In case, anyone else comes across this issue, I was able to work around it by
installing clang/LLVM and get the 'blocks' library from here:
https://github.com/mackyle/blocksruntime.

[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-13 
01:03:28 UTC ---
Maintainers (those who decide) are too few and they either do not care or do
not have time to fix these things. Existing or new contributors that are paid
to do something specific don't care about anything else as long as it doesn't
interfere with their job (if it does, whatever improvement it may be, then they
are against it). I don't think there is any GCC contributor that is paid to
improve GCC's diagnostics (am I wrong?). This is very different from Clang,
where Chris obviously cares a great deal about Clang's diagnostics, and it
seems to be supported by a team in Apple (and in Google?).

Contributors to GCC that care about these things, either unpaid or in their
free time, are very few and completely overworked. It is true that the GCC code
base has a huge technical debt, but diagnostic fixes tend to be easy to fix, if
you have a little of experience. However, there are a lot of them, and getting
patches reviewed and accepted requires herculean amounts of perseverance. But
probably you can share with me more about your (or Googlers) thoughts on the
latter, since you have the experience of submitting the same project to both
LLVM and GCC.

New contributors to GCC are almost non-existent (except those that are paid to
work on very specific stuff, like a new port, but these new contributors also
don't care about GCC in general, as long as it doesn't interfere with their
job). The reasons why GCC fails to attract new contributors are very
well-known: the copyright assignment is a major hurdle for casual/unpaid
contributors, patches from new contributors are routinely ignored and the patch
review process is hostile to new contributors (in reality, much less than in
the Linux kernel, but they have enough developers to afford being hostile).
Interacting for the first time with GCC developers can easily discourage a lot
of people (there is a whole page just on the subject!
http://gcc.gnu.org/wiki/GCC_Research). In Clang for example, small obvious
fixes proposed by new contributors without any changelog or even without a
patch are often committed immediately. I have never seen this in +6 years
contributing to GCC, on the contrary, the contributor will be asked to
bootstrap, regtest, provide a Changelog, fix the Changelog, provide a patch,
read the code style, fix the code style, some bikeshedding, and between each
step, there may be weeks of no feedback at all.

GCC also has a huge marketing problem, no overall vision, no clear leadership
(it is easy to get contradictory answers by the people who decide), and GCC
developers show both a lack of enthusiasm (just compare presentations by
Clang/LLVM developers, full of amazing features, awesome graphics,
never-seen-before numbers and LLVM webpages are full of how good their compiler
is, how much better than anything else, etc.) and a sense of superiority ("we
don't want to be like Clang/LLVM! It produces slower code by 0.0001%! It
doesn't support mmix-knuth-mmixware"). These kind of things are essential to
attract new contributors, however, they do not seem to provide any advantage to
existing developers, and they are seen as pointless extra work better done by,
wait for it, new contributors.

Nothing of the above gets fixed by switching to C++ or by having a clearly
defined AST...

[Bug fortran/52968] New: Call to type-bound procedure produces wrongly rejected

[reubendb at gmail dot com]

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

 Bug #: 52968
   Summary: Call to type-bound procedure produces wrongly rejected
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reube...@gmail.com


The following code illustrate the problem. Compiled with gcc 4.8.0 20120408, I
got this error message:

$> gfortran -c solvermod.f90 
solvermod.f90:21.31:

   call S % Equation % Evaluate ()
   1
Error: 'evaluate' at (1) is not a member of the 'equationtemplate' structure

The error dissapear when EquationTemplate is defined before SolverType in the
code below. 

--
module SolverModule

 type :: SolverType
   class ( EquationTemplate ), pointer :: Equation
 end type

 type :: EquationTemplate
 contains
   procedure :: Evaluate
 end type

contains

  subroutine Evaluate ( ET )
class ( EquationTemplate ) :: ET
  end subroutine

 subroutine Solve
   type ( SolverType ) :: S
   call S % Equation % Evaluate ()
 end subroutine

end module

[Bug c++/52967] Segmentation fault on std::vector destruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  2012-04-13 
00:15:05 UTC ---
I don't know if this is not undefined code.
>v[0].a = run();

Is this:
double &a = v[0].a;
a = run();
Or:
double tmp = run();
v[0].a = tmp;

I think both are correct because of the way the C++ standard defines =.

[Bug c++/52955] Missing warning on wrong sizeof usage

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-13 
00:09:12 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00158.html

[Bug libstdc++/52967] New: Segmentation fault on std::vector destruction

[karlicoss at gmail dot com]

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

 Bug #: 52967
   Summary: Segmentation fault on std::vector destruction
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: karlic...@gmail.com


GCC version:
4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 

Environment:
Ubuntu 11.10 amd64

I've also reproduced it at:
Ubuntu 11.10 amd64, gcc version 4.4.6
Windows 7 x64, mingw version 4.6.2. 
Gentoo x86, gcc-4.5.3-r2
Arch Linux x64, gcc version 4.7.0 


How to repeat:
main.cpp:
#include 

struct Foo
{
double a, b, c, d;
};

std::vector v;
int steps = 3;

double run()
{
if (steps == 0)
return 1.0;

steps--;
v.push_back(Foo());

v[0].a = run();

//double tmp = run();
//nodes[0].a = tmp;

return 1.0;
}

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


$ g++ main.cpp -o main && ./main
results in segmentation fault. The backtrace shows the problem is in vector
destructor.


This one is very weird, for example:
1)
replacing 
nodes[0].a = run()
with
double tmp = run();
nodes[0].a = tmp;
does not give segfault anymore.

2)
Reducing the Foo structure size (for example, using only three doubles instead
of four or using two doubles and two ints) does not give segfault.

3)
Decreasing the steps variable does not result in segfault.

4)
Returning 0.0 in the run function does not result in segfault (any non-zero
value still does).

5)
Setting the initial size for v sometimes results in segfault, sometime does.

[Bug c++/52966] New: ill-formed template constexpr functions are accepted?

[drwowe at yahoo dot com]

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

 Bug #: 52966
   Summary: ill-formed template constexpr functions are accepted?
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com


The following code successfully compiles on g++ 4.7.0 with -std=c++11.  I'm not
a language lawyer, but it seems like it shouldn't since the A::two() function
breaks the constexpr rules, either at template definition or template
instantiation time.

--
template
struct A {
  static int two_nonconst() { return 2; }
  static constexpr int two() { return two_nonconst(); }
}

constexpr int two() {
  return A::two();
}
--

There is no error message until you actually try to use the two() function in
an appropriate context, which could be very confusing.

--
int x[two()];
--
error: size of array 'x' is not an integral constant-expression

[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[xinliangli at gmail dot com]

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

--- Comment #4 from davidxl  2012-04-12 23:28:38 
UTC ---
(In reply to comment #3)
> Yep, a dup.
> 
> I am sorry David, but many of these deficiencies are well-known. What GCC
> sorely needs is people working on fixing them, and that is an issue that has 
> no
> easy fix and it is only going to get worse. :-(
> 
> *** This bug has been marked as a duplicate of bug 29280 ***

This brings up the issue of programmer productivity where Clang can claim that
their C++ based code base and clearly defined AST can make fixing things like
this easier .. 

David

[Bug c++/52964] No warning on negative array size in template instantatiation

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-12 
23:25:36 UTC ---
(In reply to comment #4)
> (In reply to comment #3) 
> > With -fsyntax-only, the warning is not emitted -- any reason for that?
> 
> Yes because -fsyntax-only does not do template instantatiations at all IIRC.

And is there a reason for that?

[Bug c++/52964] No warning on negative array size in template instantatiation

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-04-12 
23:23:31 UTC ---
(In reply to comment #3) 
> With -fsyntax-only, the warning is not emitted -- any reason for that?

Yes because -fsyntax-only does not do template instantatiations at all IIRC.

[Bug c++/52961] Missing warning on empty if

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  2012-04-12 
23:23:00 UTC ---
I think that particular warning should be default (not -Wempty-body, but the
warning about the if();).

@Jason, Gabriel, do you agree?

[Bug c++/52964] No warning on negative array size in template instantatiation

[xinliangli at gmail dot com]

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

--- Comment #3 from davidxl  2012-04-12 23:19:33 
UTC ---
(In reply to comment #2)
> And with trunk we print:
> 
> pr52964.cc: In instantiation of ‘struct S1<4>’:
> pr52964.cc:2:49:   required from ‘struct S2’
> pr52964.cc:3:45:   required from ‘void foo(T) [with T = int]’
> pr52964.cc:4:21:   required from here
> pr52964.cc:1:43: error: size of array is negative
>  template  struct S1 { int arr[N - 5]; };
>^
> 
> We could easily print the caret for each line. And the locations could be much
> better.
> 
> I also like more the order of Clang and the extra info about what each thing
> is, but we would have to convince Gabriel and/or Jason.
> 
> David, what else do you see that could be improved?

With -fsyntax-only, the warning is not emitted -- any reason for that?

David

[Bug c++/52962] Column number incorrect in error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2012-04-12 
23:19:17 UTC ---
manuel@gcc12:~$ ~/trunk/186353M/build/gcc/cc1plus -ftrack-macro-expansion
pr52962.cc 
pr52962.cc:1:23: error: ‘b’ was not declared in this scope
 #define M1(x, y, z) y();
   ^
pr52962.cc:1:23: note: in expansion of macro 'M1'
 #define M1(x, y, z) y();
   ^
pr52962.cc:2:21: note: expanded from here
 #define M2(x, y, z) M1(x, y, z)
 ^
pr52962.cc:2:21: note: in expansion of macro 'M2'
 #define M2(x, y, z) M1(x, y, z)
 ^
pr52962.cc:4:3: note: expanded from here
   M2(a, b, c);
   ^

OK, it needs a bit of fine-tuning, but it is much closer. Nice, eh? ;-)

[Bug c/52958] Missing warning on missed parehthesis

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2012-04-12
  Component|c++ |c
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  2012-04-12 
23:16:51 UTC ---
Confirmed, I thought I saw a bug about this before but I cannot find it.

[Bug c++/52964] No warning on negative array size in template instantatiation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2012-04-12 
23:16:35 UTC ---
And with trunk we print:

pr52964.cc: In instantiation of ‘struct S1<4>’:
pr52964.cc:2:49:   required from ‘struct S2’
pr52964.cc:3:45:   required from ‘void foo(T) [with T = int]’
pr52964.cc:4:21:   required from here
pr52964.cc:1:43: error: size of array is negative
 template  struct S1 { int arr[N - 5]; };
   ^

We could easily print the caret for each line. And the locations could be much
better.

I also like more the order of Clang and the extra info about what each thing
is, but we would have to convince Gabriel and/or Jason.

David, what else do you see that could be improved?

[Bug c++/52961] Missing warning on empty if

[xinliangli at gmail dot com]

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

--- Comment #3 from davidxl  2012-04-12 23:11:10 
UTC ---
(In reply to comment #2)
> Yes, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478 .

thanks. I tried -Wempty-body, gcc gives warning as expected:


emptyif.cpp: In function 'int test(int)':
emptyif.cpp:2:15: warning: suggest braces around empty body in an 'if'
statement [-Wempty-body]
if (i > 42);

[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  2012-04-12 
23:07:44 UTC ---
Yep, a dup.

I am sorry David, but many of these deficiencies are well-known. What GCC
sorely needs is people working on fixing them, and that is an issue that has no
easy fix and it is only going to get worse. :-(

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

[Bug c/29280] misleading warning for assignment used as truth construct

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #4 from Manuel López-Ibáñez  2012-04-12 
23:07:44 UTC ---
*** Bug 52957 has been marked as a duplicate of this bug. ***

[Bug libstdc++/52938] std::string::reserve request is not maintained if object is used in other object copy ctor

[abdul.tohmaz at emc dot com]

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

--- Comment #12 from Abdul Tohmaz  2012-04-12 
23:07:32 UTC ---
(In reply to comment #11)

> The benefits and problems of reference-counted strings are well known and it's
> not going to be changed now, std::string is stable and effectively frozen
> except for serious bugs.  This isn't a bug, it's behaviour allowed by the C++
> 2003 standard, even if it's not the behavior you expect or want.

Now I understand the reason for choosing not to fix.  But I can't agree with
the statement saying this is not a bug.  Here is why.

The user could care less if we use copy-on-write in the string implementation. 
The standard doesn't force that (21.3.6).  

We are violating what the standard says about reserve (20.3.10/20.3.11).  Here
it is:
"Effects: after reserve(), capacity() is greater or equal to the argument of
reserve".

That is it.  if I call reserve(1024) on a string, from that point on, capacity 
should return at least 1024. 

As a user (with access to the standards), I don't see where it says that it is
ok to violate 21.3.10/20.3.11.  If you find it, please let me know.

[Bug c++/52962] Column number incorrect in error

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-12 
23:06:20 UTC ---
That requires tracking of macros.

[Bug c++/52964] No warning on negative array size in template instantatiation

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-12 
23:04:05 UTC ---
pinskia@server:~$ ~/treecombine-gcc/bin/gcc t.cc
t.cc: In instantiation of ‘struct S1<4>’:
t.cc:4:49:   required from ‘struct S2’
t.cc:5:45:   required from ‘void foo(T) [with T = int]’
t.cc:6:21:   required from here
t.cc:3:43: error: size of array is negative

[Bug c++/52959] Missing typo suggestions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2012-04-12 
23:02:47 UTC ---
(In reply to comment #1)
> I think this is the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277 
> .

No, this is a bit more complex than a simple spell-checker.

(Although the bang::foobar is probably easy to implement).

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
 Ever Confirmed|0   |1

--- Comment #13 from Paolo Carlini  2012-04-12 
23:02:02 UTC ---
I suppose so, yes. We could test the fix in mainline for a while and then maybe
also consider having it for 4.7.1 or 4.7.2. Care to write down a short
ChangeLog entry for it?

[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-04-12 
22:59:55 UTC ---
If it is about how clear suggestion the warning gives, then it is a dup of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280 .

[Bug c++/52965] c++11 - subclass is private, but g++ ignores access modifier when using auto

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-04-12 
22:56:05 UTC ---
I don't think it's a bug.

G++ doesn't ignore access checking, you never use the name PVT so there's no
violation.  The type exists, you just can't access the name PVT.

But you can give it a new name e.g.

template
void f(T t)
{
  typedef T type;
}

f(c.p());

Or, closer to the auto case:

decltype(c.p()) p = c.p();

[Bug c++/52957] Missing suggestions on '=' and '==' confusion

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-12 
22:54:23 UTC ---
Works for me:
pinskia@server:~$ ~/treecombine-gcc/bin/gcc t.c -W  -S -Wall
t.c: In function ‘test’:
t.c:5:2: warning: suggest parentheses around assignment used as truth value
[-Wparentheses]

[Bug c++/52959] Missing typo suggestions

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-12 
22:51:47 UTC ---
I think this is the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277 .

[Bug c++/52961] Missing warning on empty if

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-04-12 
22:49:24 UTC ---
Yes, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478 .

[Bug c++/52965] New: c++11 - subclass is private, but g++ ignores access modifier when using auto

[jwcacces at yahoo dot com]

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

 Bug #: 52965
   Summary: c++11 - subclass is private, but g++ ignores access
modifier when using auto
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwcac...@yahoo.com


/*
   Is this a bug, that g++ ignores the private access modifier when using "auto
type deduction"?
   Compile with g++ -std=c++0x private_access.cpp
 vs g++ -std=c++0x private_access.cpp -DUSE_AUTO

   This seems similar to bug 52816
*/

class C
{
private:
   class PVT { };
public:
   PVT p() { return PVT(); };
};

int main(int, char*[])
{
   C c;
#ifdef USE_AUTO
   auto p = c.p();  // why does this work (in c++11)
#else
   C::PVT p = c.p();// but this reports that C::PVT is private?
#endif
   return 0;
};

[Bug c++/52961] Missing warning on empty if

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-12 
22:47:23 UTC ---
I think we had this warning and then removed it.  Let me find the history which
I think is in bugzilla already.

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Jeffrey Yasskin  2012-04-12 
22:30:13 UTC ---
Fixed for 4.6.4, 4.7.1 and 4.8.
Sorry for the delay.

[Bug target/52828] powerpc -m32 -Os writes register saves below stack

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra  2012-04-12 22:26:28 
UTC ---
Author: amodra
Date: Thu Apr 12 22:26:24 2012
New Revision: 186397

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186397
Log:
PR target/52828
* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Rewrite with
tie regs on destination of sets.  Delete forward declaration.
(rs6000_emit_stack_reset): Update rs6000_emit_stack_tie calls.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Likewise.  Use in place of gen_frame_tie
and gen_stack_tie.
(is_mem_ref): Use tie_operand to recognise stack ties.
* config/rs6000/predicates.md (tie_operand): New.
* config/rs6000/rs6000.md (restore_stack_block): Generate new
stack tie rtl.
(restore_stack_nonlocal): Likewise.
(stack_tie): Update.
(frame_tie): Delete.


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

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[jyasskin at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey Yasskin  2012-04-12 
22:26:08 UTC ---
Author: jyasskin
Date: Thu Apr 12 22:26:02 2012
New Revision: 186396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186396
Log:
Fix PR52822 by explicitly checking for object identity before
move-assigning.  This is a simpler fix than was committed to 4.7 and
4.8.

2012-04-12   Jeffrey Yasskin  

PR libstdc++/52822
* include/bits/stl_algo.h (__stable_partition_adaptive): Avoid
move-assigning an object to itself by explicitly testing for
identity.
* testsuite/25_algorithms/stable_partition/pr52822.cc: Test
vectors, which have a destructive self-move-assignment.
* testsuite/25_algorithms/stable_partition/moveable.cc (test02):
Test with rvalstruct, which explicitly checks
self-move-assignment.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_algo.h
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc

[Bug c++/52964] New: No warning on negative array size in template instantatiation

[xinliangli at gmail dot com]

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

 Bug #: 52964
   Summary: No warning on negative array size in template
instantatiation
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


template  struct S1 { int arr[N - 5]; };
template  struct S2 { S1 s1; };
template  void foo(T x) { S2 s2; }
void test() { foo(42); }

/* From Clang:
templates1.cpp:1:38: error: 'arr' declared as an array with a negative
size
template  struct S1 { int arr[N - 5]; };
^
templates1.cpp:2:49: note: in instantiation of template class 'S1<4>'
requested here
template  struct S2 { S1 s1; };
   ^
templates1.cpp:3:45: note: in instantiation of template class 'S2'
requested here
template  void foo(T x) { S2 s2; }
   ^
templates1.cpp:4:15: note: in instantiation of function template
specialization 'foo' requested here
void test() { foo(42); }
== */

[Bug c++/52963] New: Missing error on pack expansion

[xinliangli at gmail dot com]

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

 Bug #: 52963
   Summary: Missing error on pack expansion
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


template  struct S {};
  template  void f(Ts...);

  template  struct X {
template  void g() {
  f(S()...);
}
  };

 void test(X x) {
   x.g();
 }


/*

oscar-wilde.cpp:6:18: error: pack expansion contains parameter packs 'Ts'
and 'Us' that have different lengths (2 vs. 3)
f(S()...);
~~  ~~   ^
oscar-wilde.cpp:11:5: note: in instantiation of function template
specialization 'X::g' requested here
  x.g();
^
1 error generated.

*/

[Bug c++/52962] New: Column number incorrect in error

[xinliangli at gmail dot com]

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

 Bug #: 52962
   Summary: Column number incorrect in error
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


#define M1(x, y, z) y();
#define M2(x, y, z) M1(x, y, z)
void test() {
  M2(a, b, c);
}

/* = Clang

macros1.cpp:4:9: error: use of undeclared identifier 'b'
 M2(a, b, c);
   ^
macros1.cpp:2:27: note: expanded from macro 'M2'
#define M2(x, y, z) M1(x, y, z)
 ^
macros1.cpp:1:21: note: expanded from macro 'M1'
#define M1(x, y, z) y();
   ^
1 error generated.

 */

[Bug c++/52961] New: Missing warning on empty if

[xinliangli at gmail dot com]

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

 Bug #: 52961
   Summary: Missing warning on empty if
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


int test(int i) {
  if (i > 42);
return 42;
  return i;
 }

 /*

 emptyif.cpp:2:14: warning: if statement has empty body [-Wempty-body]
 if (i > 42);
^
1 warning generated.

*/

[Bug c++/52960] New: Missing warnings on ambiguous source : function decl vs local var decl

[xinliangli at gmail dot com]

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

 Bug #: 52960
   Summary: Missing warnings on ambiguous source : function decl
vs local var decl
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


struct S { int n; };
 S bar();
 S test() {
  S foo,
  bar();
  // ...
 return foo;
 }

/*

conversions.cppreturn.cpvexing.cpp
vexing.cpp:5:6: warning: empty parentheses interpreted as a function
declaration [-Wvexing-parse]
 bar();
^~
vexing.cpp:4:8: note: change this ',' to a ';' to call 'bar'
 S foo,
  ^
  ;
vexing.cpp:5:6: note: replace parentheses with an initializer to declare
a variable
 bar();
^~
{}
1 warning generated.

*/

[Bug c++/52915] [C++11] Deleted default-constructor of anonymous unions not honored

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-12
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/52959] New: Missing typo suggestions

[xinliangli at gmail dot com]

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

 Bug #: 52959
   Summary: Missing typo suggestions
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


struct BaseType {};
struct DerivedType : public BaseType {
 static int base_type;
 DerivedType() : basetype() {}
};


/*

typo1.cpp:4:19: error: initializer 'basetype' does not name a non-static
data member or base class; did you mean the base class 'BaseType'?
 DerivedType() : basetype() {}
 ^~~~
 BaseType
typo1.cpp:2:22: note: base class 'BaseType' specified here
struct DerivedType : public BaseType {
^~~
1 error generated.

*/


namespace fiz { namespace bang {
  int foobar();
 } }
 int test() {
  return bang::Foobar();
 }

/*

typo2.cpp:5:10: error: use of undeclared identifier 'bang'; did you mean
'fiz::bang'?
 return bang::Foobar();
^~~~
fiz::bang
typo2.cpp:1:27: note: 'fiz::bang' declared here
namespace fiz { namespace bang {
 ^
typo2.cpp:5:16: error: no member named 'Foobar' in namespace 'fiz::bang';
did you mean 'foobar'?
 return bang::Foobar();
~~^~
  foobar
typo2.cpp:2:7: note: 'foobar' declared here
 int foobar();
 ^
2 errors generated.

*/

[Bug c++/52958] New: Missing warning on missed parehthesis

[xinliangli at gmail dot com]

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

 Bug #: 52958
   Summary: Missing warning on missed parehthesis
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


int test(bool b, int x, int y) {
  return 42 + b ? x : y;
 }

/*

parentheses4.cpp:2:17: warning: operator '?:' has lower precedence than
'+'; '+' will be evaluated first [-Wparentheses]
 return 42 + b ? x : y;
~~ ^
parentheses4.cpp:2:17: note: place parentheses around the '+' expression
to silence this warning
 return 42 + b ? x : y;
   ^
( )
parentheses4.cpp:2:17: note: place parentheses around the '?:' expression
to evaluate it first
 return 42 + b ? x : y;
   ^
 ()
1 warning generated.

*/

[Bug c++/52957] New: Missing suggestions on '=' and '==' confusion

[xinliangli at gmail dot com]

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

 Bug #: 52957
   Summary: Missing suggestions on '=' and '==' confusion
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


void foo();
 void bar();
 void test(int i) {
  // ...
 if (i = 42) foo();
  else bar();
 }

 /*

 parentheses1.cpp:5:9: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 if (i = 42) foo();
 ~~^~~~
parentheses1.cpp:5:9: note: place parentheses around the assignment to
silence this warning
 if (i = 42) foo();
   ^
 ( )
parentheses1.cpp:5:9: note: use '==' to turn this assignment into an
equality comparison
 if (i = 42) foo();
   ^
   ==
1 warning generated.

*/

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu.org]

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

--- Comment #32 from Manuel López-Ibáñez  2012-04-12 
21:58:59 UTC ---
(In reply to comment #31)
> The effect of this patch on overload resolution diagnostics is problematic:
> wa2.C: In function ‘int main()’:
> wa2.C:6:6: error: no matching function for call to ‘f(int)’
>f(1);
>   ^
> wa2.C:6:6: note: candidates are:
>f(1);
>   ^
> wa2.C:1:6: note: void f()
>  void f();
>   ^
> wa2.C:1:6: note:   candidate expects 0 arguments, 1 provided
>  void f();
>   ^
> wa2.C:2:6: note: void f(int, int)
>  void f(int,int);
>   ^
> wa2.C:2:6: note:   candidate expects 2 arguments, 1 provided
>  void f(int,int);
>   ^
> 
> When there are multiple diagnostics at the same input location, we should only
> print the source/caret information once.

True. Actually, in this case, perhaps we should print:

 wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
   ^
note: candidates are:
 wa2.C:1:6: note:   candidate expects 0 arguments, 1 provided
  void f();
   ^
 wa2.C:2:6: note:   candidate expects 2 arguments, 1 provided
  void f(int,int);
   ^

no? Any other suggestions?

We could also print the %qD in the same line as:

 wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
   ^
note: candidates are:
 wa2.C:1:6: note:   candidate 'void f()' expects 0 arguments, 1 provided
  void f();
   ^
 wa2.C:2:6: note:   candidate 'void f(int, int)' expects 2 arguments, 1
provided
  void f(int,int);
   ^

What do you think?

[Bug c++/52956] New: Missing overflow warning

[xinliangli at gmail dot com]

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

 Bug #: 52956
   Summary: Missing overflow warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


static const long long
  DiskCacheSize = 8 << 30; // 8 Gigs

/*

overflow.cpp:1:42: warning: signed shift result (0x2) requires 35
bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
static const long long DiskCacheSize = 8 << 30; // 8 Gigs
  ~ ^  ~~
1 warning generated.

*/

[Bug c++/52955] New: Missing warning on wrong sizeof usage

[xinliangli at gmail dot com]

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

 Bug #: 52955
   Summary: Missing warning on wrong sizeof usage
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


Example:


 #include 
 struct S { int a, b, c; float vec[16]; };
 void test(S *s) {
  // ...
  memset(s, 0, sizeof(s));
  // ...
 }

 /*

memset.cpp:5:23: warning: argument to 'sizeof' in 'memset' call is the
same expression as the destination; did you mean to dereference it? [-
Wsizeof-pointer-memaccess]
 memset(s, 0, sizeof(s));
~^
1 warning generated.

*/

[Bug c++/52954] Missing bounds check warning

[xinliangli at gmail dot com]

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

--- Comment #1 from davidxl  2012-04-12 21:56:07 
UTC ---
Another example:

constexpr int arr_size = 42;
 constexpr int N = 44;
 void f(int);
 int test() {
   int arr[arr_size];
  // ...
   f(arr[N]);
   // ...
  if (N < arr_size) return arr[N];
  return 0;
 }

/*

deadcode.cpp:7:5: warning: array index 44 is past the end of the array
(which contains 42 elements) [-Warray-bounds]
 f(arr[N]);
   ^   ~
deadcode.cpp:5:3: note: array 'arr' declared here
 int arr[arr_size];
 ^
1 warning generated.

*/

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[laurent.alfonsi at st dot com]

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

--- Comment #12 from Laurent Aflonsi  2012-04-12 
21:55:42 UTC ---
Thanks very much Paolo. It works fine on SH4 also.
Is that enough to push the patch ?
Laurent

[Bug c++/52954] New: Missing bounds check warning

[xinliangli at gmail dot com]

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

 Bug #: 52954
   Summary: Missing bounds check warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


int foo() {
  int arr[100];
  // ...
 return arr[100];
 }

 /*  From clang:

 array.cpp:4:10: warning: array index 100 is past the end of the array
(which contains 100 elements) [-Warray-bounds]
 return arr[100];
^   ~~~
array.cpp:2:3: note: array 'arr' declared here
 int arr[100];
 ^
1 warning generated.

*/

[Bug c++/52953] g++-4.7.0 fails to detect function parameter name redeclarations.

[meng at g dot clemson.edu]

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

--- Comment #1 from meng at g dot clemson.edu 2012-04-12 21:53:36 UTC ---
another example showing violation of c++11 3.3.3/4
 BEGIN ---
int main ()
{
 if (int a = 1)
 {
  void a (); // 1
 }
 else
 {
  void a (); // 2
 }

 while (int a = 0)
 {
  void a (); // 3
 }

 for (int a = 0;;)
 {
  void a (); // 4
  break;
 }
 for (; int a = 0;)
 {
  void a (); // 5
 }

 return 0;
}
  END  ---

According to my understanding, all numbered cases are illegal based on c++11
3.3.3/4.g++-4.7.0 correctly caught case 3 and 5 as compiler errors, the rest
are accepted.

[Bug c++/24985] caret diagnostics

[jason at gcc dot gnu.org]

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

--- Comment #31 from Jason Merrill  2012-04-12 
21:44:23 UTC ---
The effect of this patch on overload resolution diagnostics is problematic:

-
void f();
void f(int,int);

int main()
{
  f(1);
}
-

wa2.C: In function ‘int main()’:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
   f(1);
  ^
wa2.C:6:6: note: candidates are:
   f(1);
  ^
wa2.C:1:6: note: void f()
 void f();
  ^
wa2.C:1:6: note:   candidate expects 0 arguments, 1 provided
 void f();
  ^
wa2.C:2:6: note: void f(int, int)
 void f(int,int);
  ^
wa2.C:2:6: note:   candidate expects 2 arguments, 1 provided
 void f(int,int);
  ^

When there are multiple diagnostics at the same input location, we should only
print the source/caret information once.

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[jyasskin at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey Yasskin  2012-04-12 
21:42:00 UTC ---
Author: jyasskin
Date: Thu Apr 12 21:41:55 2012
New Revision: 186394

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186394
Log:
Fix PR52822 (stable_partition move-assigns object to itself) by
scanning for the first value that doesn't match the predicate before
starting to rearrange values.

2012-04-03   Jeffrey Yasskin  

PR libstdc++/52822
* include/bits/stl_algo.h (__find_if_not): Expose in
C++98 mode.
(__find_if_not_n): Like __find_if_not, but works on and updates a
counted range instead of a bounded range.
(stable_partition): Guarantee !__pred(*__first) in call to
__stable_partition_adaptive() or __inplace_stable_partition().
(__stable_partition_adaptive): Use new precondition to avoid
moving/copying objects onto themselves.  Guarantee new
precondition to recursive calls.
(__inplace_stable_partition): Use new precondition to simplify
base case, remove __last parameter.  Guarantee new precondition to
recursive calls.
* testsuite/25_algorithms/stable_partition/moveable.cc (test02):
Test a sequence that starts with a value matching the predicate.
* testsuite/25_algorithms/stable_partition/pr52822.cc:
Test vectors, which have a destructive self-move-assignment.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
  - copied unchanged from r186391,
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
Modified:
branches/gcc-4_7-branch/   (props changed)
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algo.h
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc

Propchange: branches/gcc-4_7-branch/
('svn:mergeinfo' added)

[Bug c++/44811] non controllable bogus warning: right/left shift count is negative

[drwowe at yahoo dot com]

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

D W  changed:

   What|Removed |Added

 CC||drwowe at yahoo dot com

--- Comment #3 from D W  2012-04-12 21:36:14 UTC ---
I'm also getting a different but similar warning.

Trivial example:

int shiftifbig(int x) {
  if (sizeof(x) > 4) {
return x>>32;
  } else {
return x;
  }
}

produces the following spurious warning:

warning: right shift count >= width of type [enabled by default]


Please gate this warning on something like -Wshift so that the corresponding
-Wno-shift could be used.
Even better, suppress the warning automatically from dead code like in the
above example.

[Bug c++/52953] New: g++-4.7.0 fails to detect function parameter name redeclarations.

[meng at g dot clemson.edu]

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

 Bug #: 52953
   Summary: g++-4.7.0 fails to detect function parameter name
redeclarations.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@g.clemson.edu


source code demonstrating the problem.
--- BEGIN 
void f (int i) try
{
 void i (); // 1
}
catch (...)
{
 void i (); // 2
}

int main ()
{
 return 0;
}
---  END  

compiled with :
$HOME/gcc/4.7.0/bin/c++ -std=c++0x -Wall -O3 tt.cc

compiler output : 
nothing

g++-4.7.0 accepts the code as it is, issuing no warnings and no errors. I think
this is wrong. According to c++11 3.3.3/2 
"A parameter name shall not be redeclared in the outermost block of the
function definition nor in the outermost block of any handler associated with a
function-try-block."

In the above example, i is the name of the parameter of function f. The name i,
therefore, cannot be redeclared in the outermost block of the function
definition (case 1) nor can it be redeclared in the outermost block of any
associated handler (case 2). But my g++ accepts both cases while they should be
rejected.

[Bug c++/52951] internal compiler error with c++11 initializer lists and C arrays

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-12
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jason Merrill  2012-04-12 
21:32:00 UTC ---
This seems to be fixed already for 4.7.1.  Now the compiler says,

.../libstdc++-v3/include/bits/stl_pair.h:132:45: error: array used as
initializer

when the pair constructor tries to initialize one array from another.

[Bug c++/31754] Improve column number accuracy in error messages

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #23 from Manuel López-Ibáñez  2012-04-12 
21:23:51 UTC ---
Please open new PRs for each issue that you find. Closing this one as fixed.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
 Ever Confirmed|0   |1

[Bug c/52952] New: Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

 Bug #: 52952
   Summary: Wformat location info is bad (wrong column number)
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


#include 
void f() {
   printf("%.*d");
}

$ gcc-4.8 -fsyntax-only  -Wformat format-strings.c
format-strings.c: In function 'f':
format-strings.c:3:4: warning: field precision specifier '.*' expects a
matching 'int' argument [-Wformat]
printf("%.*d");
^
format-strings.c:3:4: warning: format '%d' expects a matching 'int' argument
[-Wformat]
printf("%.*d");
^

$ clang-3.1 -fsyntax-only format-strings.c
format-strings.c:3:14: warning: '.*' specified field precision is missing a
matching 'int' argument
   printf("%.*d");
   ~~^~

[Bug target/52775] Change default for using FCFID instruction

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2012-04-12 
21:00:17 UTC ---
Author: meissner
Date: Thu Apr 12 21:00:07 2012
New Revision: 186392

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186392
Log:
[gcc]
2012-04-12  Michael Meissner  

Backport from mainline
2012-04-12  Michael Meissner  

PR target/52775
* config/rs6000/rs6000.h (TARGET_FCFID): Add TARGET_PPC_GPOPT to
the list of options to enable the FCFID instruction.
(TARGET_EXTRA_BUILTINS): Adjust comment.

[gcc/testsuite]
012-04-12  Michael Meissner  

Backport from mainline
2012-04-12  Michael Meissner  

PR target/52775
* gcc.target/powerpc/pr52775.c: New file.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr52775.c
  - copied unchanged from r186389,
trunk/gcc/testsuite/gcc.target/powerpc/pr52775.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[jyasskin at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey Yasskin  2012-04-12 
20:59:14 UTC ---
Author: jyasskin
Date: Thu Apr 12 20:59:09 2012
New Revision: 186391

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186391
Log:
Fix PR52822 (stable_partition move-assigns object to itself) by
scanning for the first value that doesn't match the predicate before
starting to rearrange values.

2012-04-03   Jeffrey Yasskin  

PR libstdc++/52822
* include/bits/stl_algo.h (__find_if_not): Expose in
C++98 mode.
(__find_if_not_n): Like __find_if_not, but works on and updates a
counted range instead of a bounded range.
(stable_partition): Guarantee !__pred(*__first) in call to
__stable_partition_adaptive() or __inplace_stable_partition().
(__stable_partition_adaptive): Use new precondition to avoid
moving/copying objects onto themselves.  Guarantee new
precondition to recursive calls.
(__inplace_stable_partition): Use new precondition to simplify
base case, remove __last parameter.  Guarantee new precondition to
recursive calls.
* testsuite/25_algorithms/stable_partition/moveable.cc (test02):
Test a sequence that starts with a value matching the predicate.
* testsuite/25_algorithms/stable_partition/pr52822.cc:
Test vectors, which have a destructive self-move-assignment.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
  - copied, changed from r186389,
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-04-12 
20:54:35 UTC ---
Indeed, removing the lines

 TODO_dump_func/* todo_flags_finish */

fixes the PR (I don't have write permissions).

[Bug c++/52951] New: internal compiler error with c++11 initializer lists and C arrays

[drwowe at yahoo dot com]

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

 Bug #: 52951
   Summary: internal compiler error with c++11 initializer lists
and C arrays
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com


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

The following trivial snippet produces "internal compiler error: Segmentation
fault".  Tested with 4.7.0 and 4.6.3 on two different architectures.

g++-4.7 -c -std=c++11 test.cc

 test.cc:
#include 
std::pair foo = {1, {2} };




g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.7
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug c++/46400] g++ Segmentation Fault on heavily templated project.

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  2012-04-12 
19:16:16 UTC ---
Created attachment 27145
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27145
Test case from EMAN2

Here's yet another test case that fails (on powerpc64-linux) and is fixed on
mainline with Jakub's patch.  However, we encountered this using GCC 4.6. 
Jakub, is it possible to backport your patch to FSF 4.6?

I looked at backporting the patch myself, but I'm not really sure what all that
GC magic macro stuff is doing to feel confident in backporting it myself.


bergner@bns:~/gcc/BUGS>
/home/bergner/gcc/install/gcc-fsf-mainline-r175389/bin/g++ -m64 -mcpu=power7
-O0 -ffast-math -fPIC -S libpyEMData2.ii 
bergner@bns:~/gcc/BUGS> echo $?
0
bergner@bns:~/gcc/BUGS>
/home/bergner/gcc/install/gcc-fsf-mainline-r175388/bin/g++ -m64 -mcpu=power7
-O0 -ffast-math -fPIC -S libpyEMData2.ii 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/52946] Unable to define a Block variable

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  2012-04-12 
18:39:56 UTC ---
Which means that this is a proprietary non-portable extension by Apple. It
doesn't work with other compilers except Apple's. You should really not use it.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2012-04-12 18:37:47 UTC ---
Author: uros
Date: Thu Apr 12 18:37:42 2012
New Revision: 186388

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186388
Log:
PR target/52932
* config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second
argument type to __m256i.  Update call to __builtin_ia32_permvarsf256.
* config/i386/sse.md (UNSPEC_VPERMVAR): New.
(UNSPEC_VPERMSI, UNSPEC_VPERMSF): Remove.
(avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2.
(avx2_permvar): Macroize insn from avx2_permvarv8sf and
avx2_permvarv8si using VI4F_256 mode iterator.
* config/i386/i386.c (bdesc_args) <__builtin_ia32_permvarsf256>:
Update builtin type to V8SF_FTYPE_V8SF_V8SI.
(ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and
gen_avx2_permvarv8sf.
(expand_vec_perm_pshufb): Ditto.

testsuite/ChangeLog:

PR target/52932
* gcc.target/i386/avx2-vpermps-1.c (avx2_test): Use __m256i type for
second function argument.
* gcc.target/i386/avx2-vpermps-2.c (init_permps): Update declaration.
(calc_permps): Update declaration.  Calculate result correctly.
(avx2_test): Change src2 type to union256i_d.
* gcc.target/i386/avx2-vpermd-2.c (calc_permd): Calculate result
correctly.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx2intrin.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermd-2.c
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-2.c

[Bug target/52775] Change default for using FCFID instruction

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2012-04-12 
17:10:38 UTC ---
Author: meissner
Date: Thu Apr 12 17:10:27 2012
New Revision: 186387

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186387
Log:
[gcc]
2012-04-11  Michael Meissner  

PR target/52775
* config/rs6000/rs6000.h (TARGET_FCFID): Add TARGET_PPC_GPOPT to
the list of options to enable the FCFID instruction.
(TARGET_EXTRA_BUILTINS): Adjust comment.

[gcc/testsuite]
2012-04-11  Michael Meissner  

PR target/52775
* gcc.target/powerpc/pr52775.c: New file.



Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr52775.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/testsuite/ChangeLog

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak  2012-04-12 17:10:31 
UTC ---
(In reply to comment #5)

> Uros, I've slightly updated your patch: idx and vector were intermixed.

The same cure should be applied to vpermd insn. Fortunately, this allowed us to
vectorize vpermps and vpermd patterns.

Please also note that avx2-vpermd-2.c test also had switched operands to
_mm256_permutevar8x32_epi32.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-04-12 17:07:56 
UTC ---
Created attachment 27144
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27144
Even more updated patch

Patch that also fixes vpermd insn.

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2012-04-12 
17:05:01 UTC ---
Created attachment 27143
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27143
Simple testcase

This should be a simpler testcase.  What happens is that we are
attempting to devirtualize call to a virtual method introduced in a
descendant but with an ancestor which does not have it.  I suppose
this is OK if the call is never executed in run-time.

Dealing with this situation in gimple_get_virt_method_for_binfo would
be easy, but perhaps we want fold_ctor_reference to return NULL is it
is requested to fold an expression from beyond the provided
constructor?

[Bug libstdc++/52950] New: --enable-symvers=gnu-versioned-namespace exports symbol twice.

[pluto at agmk dot net]

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

 Bug #: 52950
   Summary: --enable-symvers=gnu-versioned-namespace exports
symbol twice.
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


for the cross gcc build, the libstdc++.so.7 export symbols twice.
with and without versioning, e.g.:

$ readelf -sW (cross).../libstdc++.so.7 |grep Znwm
   922: 00075610   144 FUNCGLOBAL DEFAULT   12 _Znwm@@GLIBCXX_7.0
  2742: 000756a0   120 FUNCGLOBAL DEFAULT   12
_ZnwmRKSt9nothrow_t@@GLIBCXX_7.0
  1170: 000756a0   120 FUNCGLOBAL DEFAULT   12 _ZnwmRKSt9nothrow_t
  1171: 00075610   144 FUNCGLOBAL DEFAULT   12 _Znwm

the native gcc build exports symbols correctly.

$ readelf -sW /usr/lib64/libstdc++.so.7.0.0|grep Znwm
   332: 00069820   120 FUNCGLOBAL DEFAULT   12
_ZnwmRKSt9nothrow_t@@GLIBCXX_7.0
  3124: 00069790   144 FUNCGLOBAL DEFAULT   12 _Znwm@@GLIBCXX_7.0


$ (cross) x86_64-gnu-linux-g++ -v

Using built-in specs.
COLLECT_GCC=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++
COLLECT_LTO_WRAPPER=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64/gcc/x86_64-gnu-linux/4.7.1/lto-wrapper
Target: x86_64-gnu-linux
Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64
--prefix=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux
--with-sysroot=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux
--libdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--libexecdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--with-slibdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--with-gmp-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-gmp-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpfr-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpfr-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpc-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpc-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--disable-multilib --enable-nls --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libquadmath --disable-libitm --enable-tls
--enable-libstdcxx-allocator=new --enable-extern-template
--enable-libstdcxx-time=rt --enable-libstdcxx-threads --disable-libstdcxx-pch
--disable-lto --disable-plugin --enable-c99 --enable-long-long
--enable-linux-futex --enable-threads=posix --enable-shared --with-pic
--enable-gold --enable-__cxa_atexit --enable-languages=c,c++
--enable-checking=release --enable-symvers=gnu-versioned-namespace
--with-long-double-128 --disable-cld --disable-bootstrap
Thread model: posix
gcc version 4.7.1 20120406 (prerelease) (GCC)

[Bug inline-asm/49611] Inline asm should support input/output of flags

[scovich at gmail dot com]

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

--- Comment #3 from Ryan Johnson  2012-04-12 16:39:32 
UTC ---
FYI: based on a discussion from quite some time ago [1], it seems that the
Linux kernel folks would be "tickled pink" to have this feature, and discussed
several potential ways to implement it.

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0111.2/0256.html

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

Daniel Richard G.  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #36 from Daniel Richard G.  2012-04-12 
16:28:36 UTC ---
My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and
this has made the linker issues go away. The minimal test case now passes, and
I can compile and link programs again without any workarounds. This is true
both for GCC 4.5.1 (same build as in the original report), and the older GCC
2.9 bundled with the system.

I'll provide the same patch-level information as Paul Pryor did earlier:

$ oslevel -s
5300-12-05-1140

$ ls -l /usr/bin/ld
lrwxrwxrwx1 bin  bin  15 Dec 02 2004  /usr/bin/ld ->
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x1 bin  bin   38942 Aug 09 2011  /usr/ccs/bin/ld

$ lslpp -h bos.rte.bind_cmds
  Fileset Level Action   Status   Date Time
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
  5.3.0.0   COMMIT   COMPLETE 12/02/04 17:04:24
  5.3.0.1   COMMIT   COMPLETE 12/06/04 11:52:51
 5.3.0.30   COMMIT   COMPLETE 09/30/10 10:04:35
 5.3.0.40   COMMIT   COMPLETE 10/01/10 11:02:18
 5.3.0.53   COMMIT   COMPLETE 10/01/10 14:15:17
 5.3.0.65   COMMIT   COMPLETE 10/05/10 09:48:48
  5.3.7.5   COMMIT   COMPLETE 10/06/10 10:04:03
  5.3.8.6   COMMIT   COMPLETE 10/07/10 08:13:13
  5.3.9.7   COMMIT   COMPLETE 10/08/10 08:33:35
 5.3.10.4   COMMIT   COMPLETE 10/14/10 10:35:13
 5.3.11.4   COMMIT   COMPLETE 10/15/10 23:31:34
 5.3.12.1   COMMIT   COMPLETE 10/16/10 00:05:56
 5.3.12.4   COMMIT   COMPLETE 04/03/12 12:34:21

$ lslpp -i bos.rte.bind_cmds
Vendor
  Fileset   CodeProduct Id  Feature Id  Package Name
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds 5.3.0.0
5765-E6200  bos


I will be happy to provide additional details about the configuration of this
system if anyone needs it.

There does not appear to be anything left to do here as far as GCC is
concerned, so I'm marking this bug as invalid. If anyone feels differently,
feel free to change it back.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2012-04-12 
16:29:32 UTC ---
In mainline, for x86_64-linux, the below patchlet indeed avoids the valgrind
errors and passes make check, make check-performance.

Index: src/c++98/mt_allocator.cc
===
--- src/c++98/mt_allocator.cc(revision 186374)
+++ src/c++98/mt_allocator.cc(working copy)
@@ -48,6 +48,7 @@
 {
   __gthread_key_delete(_M_key);
   ::operator delete(static_cast(_M_thread_freelist_array));
+  _M_thread_freelist = 0;
 }
 }
   };

[Bug tree-optimization/52734] [4.7/4.8 Regression] Incorrect optimization of uClibc sbrk()

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org 2012-04-12 16:25:28 UTC ---
Created attachment 27142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27142
pr52734.2.patch

Another tentative patch. Also not precise, but a simpler approach.

Now testing.

[Bug c/52946] Unable to define a Block variable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |enhancement

--- Comment #1 from Andrew Pinski  2012-04-12 
16:19:35 UTC ---
Blocks are not part of GNU GCC at all.
The support for them was not submitted upstream by Apple or reimplemented by
anyone else.

[Bug tree-optimization/18589] could optimize FP multiplies better

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from William J. Schmidt  
2012-04-12 16:16:50 UTC ---
Fixed.

[Bug tree-optimization/18589] could optimize FP multiplies better

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from William J. Schmidt  2012-04-12 
16:15:24 UTC ---
Author: wschmidt
Date: Thu Apr 12 16:15:13 2012
New Revision: 186384

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186384
Log:
gcc:

2012-04-12  Bill Schmidt  

PR tree-optimization/18589
* tree-ssa-reassoc.c (reassociate_stats): Add two fields.
(operand_entry): Add count field.
(add_repeat_to_ops_vec): New function.
(completely_remove_stmt): Likewise.
(remove_def_if_absorbed_call): Likewise.
(remove_visited_stmt_chain): Remove feeding builtin pow/powi calls.
(acceptable_pow_call): New function.
(linearize_expr_tree): Look for builtin pow/powi calls and add operand
entries with repeat counts when found.
(repeat_factor_d): New struct and associated typedefs.
(repeat_factor_vec): New static vector variable.
(compare_repeat_factors): New function.
(get_reassoc_pow_ssa_name): Likewise.
(attempt_builtin_powi): Likewise.
(reassociate_bb): Call attempt_builtin_powi.
(fini_reassoc): Two new calls to statistics_counter_event.

gcc/testsuite:

2012-04-12  Bill Schmidt  

PR tree-optimization/18589
* gcc.dg/tree-ssa/pr18589-1.c: New test.
* gcc.dg/tree-ssa/pr18589-2.c: Likewise.
* gcc.dg/tree-ssa/pr18589-3.c: Likewise.
* gcc.dg/tree-ssa/pr18589-4.c: Likewise.
* gcc.dg/tree-ssa/pr18589-5.c: Likewise.
* gcc.dg/tree-ssa/pr18589-6.c: Likewise.
* gcc.dg/tree-ssa/pr18589-7.c: Likewise.
* gcc.dg/tree-ssa/pr18589-8.c: Likewise.
* gcc.dg/tree-ssa/pr18589-9.c: Likewise.
* gcc.dg/tree-ssa/pr18589-10.c: Likewise.



Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-10.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug c++/52949] decltype too sensitive to order of declarations?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-04-12 
16:12:15 UTC ---
this is no different to;

struct Vector
{
  static const int i = sizeof(member_);   // error
  int member_;
  static const int j = sizeof(member_);   // ok
};

[Bug c++/52949] decltype too sensitive to order of declarations?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2012-04-12 
15:59:51 UTC ---
The name member_ isn't in scope until it's declared, this is nothing to do with
decltype.

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[vapier at gentoo dot org]

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

--- Comment #4 from Mike Frysinger  2012-04-12 
15:42:49 UTC ---
(In reply to comment #3)

wouldn't it though ?  there's still a top level union there surrounding all the
members.  so flattening it, i'd get three choices:
 - th_block; th_data
 - th_code; th_data
 - th_stuff

the problem before was that it was a union followed by th_data

testing locally with gcc-4.6.2, i get the object sizes of:
 - -O0: th_data:-1 th_stuff:-1
 - -O[s123]: th_data:96 th_stuff:98

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  2012-04-12 
15:36:52 UTC ---
Ok, thanks. Please let us know how it goes.

[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition

[rai...@emrich-ebersheim.de]

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

--- Comment #2 from Rainer Emrich  2012-04-12 
15:36:11 UTC ---
(In reply to comment #1)
> I remember Kai did surgery in this place.  Did you identify a patch that 
> caused
> this regression?  My bet would be
> 
> 2011-03-25  Kai Tietz  
> 
> * collect2.c (write_c_file_stat): Handle backslash
> as right-hand directory separator.
> (resolve_lib_name): Use IS_DIR_SEPARATOR instead of
> checking just for slash.
> * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
> instead of checking for trailing slash.
> * gcc.c (record_temp_file): Use filename_cmp instead
> of strcmp.
> (do_spec_1): Likewise.
> ...

To be honest, I don't know. I tried native bootstrapping on x86_64-w64-mingw32
at the beginning of last year but gave up due to the issues found. Lately I
managed to bootstrap the 4.6 series with some manual intervention even ada
included.
There are still issues, one of them is really fundamental, but that's a
different story.

Btw. the PATH composition for --with-local-prefix is messed up the same way.

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-12 
15:28:10 UTC ---
(In reply to comment #2)
> if you look at the tftp example, you'd see that your proposed struct does not
> work.  the protocol needs two flexible array members at different starting
> points.

Ah, indeed.  Now when inspecting your description closer.

---
with tftp, the packet is described by:
struct tftphdr {
short opcode;
union {
unsigned short tu_block;
short tu_code;
char tu_stuff[0];
};
char th_data[];
};

when opcode is 1, the rest of the packet is a C string.  i.e. the buffer:
char x[] = { 1, 0, 'f', 'i', 'l', 'e', '\0', };
opcode = 1, tu_stuff = "file"

when opcode is 3 though, the tu_block field will be a number, and the rest of
the data will be in th_data.  i.e. the buffer:
char x[] = { 2, 0, 3, 0, <8KiB>, };
opcode = 2, tu_block = 3, th_data = 8KiB
---

So

struct tftphdr {
short opcode;
union {
struct opcode_3 {
   unsigned short tu_block;
   char th_data[];
} opcode3;
short tu_code;
char tu_stuff[0];
};
};

would work.  At least

struct stct {
int i;
union {
struct {
short k;
char tail[];
} x;
char buf[0];
};
};
char buf[100];
main()
{
  struct stct *foo = (void *)buf;
  printf("%i\n", __builtin_object_size(foo->buf, 1));
  printf("%i\n", __builtin_object_size(foo->x.tail, 1));
}

produces the expected 96, 94 values?

> the 96 isn't conservative in this case, it's correct.  i declared a buffer of
> 100 bytes, so buf[0] can cover 96 bytes (as the leading integer is 32bits).  
> is
> there a "simplish" patch that could be backported to the 4.5/4.6 branches for
> that ?

No, and it's only because optimization triggers and we get to see buf[] here.
Otherwise you'd get still zero.

> thinking a bit more, the requirements can probably be pulled off with more
> anonymous unions/structs like so:
> 
> struct tftphdr {
> short opcode;
> union {
> struct {
> union {
> unsigned short tu_block;
> short tu_code;
> };
> char tu_data[0];
> };
> char tu_stuff[0];
> } __attribute__ ((__packed__));
> } __attribute__ ((__packed__));

I don't see how this would avoid the issue for __builtin_object_size
(foo->...tu_data) though.

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
   Target Milestone|--- |4.8.0
Summary|UNRESOLVED: selfassign.c in |[4.8 Regression]
   |gcc/g++, one_time_plugin.c  |UNRESOLVED: selfassign.c in
   |in gcc, and dumb_plugin.c   |gcc/g++, one_time_plugin.c
   |in g++  |in gcc, and dumb_plugin.c
   ||in g++
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-04-12 
15:21:19 UTC ---
Confirmed.

[Bug c++/52949] New: decltype too sensitive to order of declarations?

[akim.demaille at gmail dot com]

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

 Bug #: 52949
   Summary: decltype too sensitive to order of declarations?
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com


Created attachment 27141
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27141
Test case

I am not sure of myself on this one.  I have read a preversion of the standard
(and I checked n2343 too), and I did not find anything very clear about this. 
I do understand that the "rich" version might require some dependency
resolution in full generality, but then again, I have not found the restriction
spelled out in the standard.  The only restriction I spotted is the case of
overloaded functions.  I apologize if this is the expected behavior.

In the following example, the first use of decltype fails because it does not
see the member_ definition, which is right after it.  The second decltype
passes.


$ g++-mp-4.7 --version
g++-mp-4.7 (GCC) 4.7.0
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.
$ g++-mp-4.7 -std=c++11 foo.cc
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc: In function 'int main()':
foo.cc:12:5: error: 'struct Vector' has no member named 'val1'

$ g++-mp-4.8 --version
g++-mp-4.8 (GCC) 4.8.0 20120408 (experimental)
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.
$ g++-mp-4.8 -std=c++11 foo.cc
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc: In function 'int main()':
foo.cc:12:5: error: 'struct Vector' has no member named 'val1'

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[vapier at gentoo dot org]

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

Mike Frysinger  changed:

   What|Removed |Added

  Known to work||4.4.7
  Known to fail||4.5.3, 4.6.3

--- Comment #2 from Mike Frysinger  2012-04-12 
15:13:25 UTC ---
if you look at the tftp example, you'd see that your proposed struct does not
work.  the protocol needs two flexible array members at different starting
points.

the 96 isn't conservative in this case, it's correct.  i declared a buffer of
100 bytes, so buf[0] can cover 96 bytes (as the leading integer is 32bits).  is
there a "simplish" patch that could be backported to the 4.5/4.6 branches for
that ?

thinking a bit more, the requirements can probably be pulled off with more
anonymous unions/structs like so:

struct tftphdr {
short opcode;
union {
struct {
union {
unsigned short tu_block;
short tu_code;
};
char tu_data[0];
};
char tu_stuff[0];
} __attribute__ ((__packed__));
} __attribute__ ((__packed__));

[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  2012-04-12 
15:10:50 UTC ---
Well, what happens is that the target of devirtualization which is
loaded from the VMT is:


constant 0>

I'll investigate why.

[Bug other/52937] [4.8 Regression] ICE in several cpu2006 benchmarks with -fprofile-use (assert in get_loop_body)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from William J. Schmidt  2012-04-12 
15:06:23 UTC ---
My apologies.  This is occurring in some instrumentation code I added for
testing, and doesn't occur with the unmodified trunk compiler.  I should have
checked that first, but was misled because it looked like similar problems
we've seen recently from the loop changes.

So, take the day off. ;)

[Bug c/52549] [4.8 Regression] ice in pointer_diff

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2012-04-12 
15:06:10 UTC ---
Mine.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[laurent.alfonsi at st dot com]

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

--- Comment #9 from Laurent Aflonsi  2012-04-12 
15:05:25 UTC ---
Paolo,

I ve discovered that the encoding of M_key is encoded differently for each
thread-implementation. On pthread implementation M_key is an integer, whereas
on others it is pointers. So, in pthread 0 is a legal thread key: So zeroing
M_key and testing if(M_key) is simply wrong.

The M_thread_freelist zeroing seems legal and is enough to avoid the above
valgrind error. I am now testing with this fix only:

--- libstdc++-v3/src/mt_allocator.cc   
+++ libstdc++-v3/src/mt_allocator.cc   
@@ -47,7 +47,8 @@
   if (_M_thread_freelist_array)
 {
   __gthread_key_delete(_M_key);
   ::operator delete(static_cast(_M_thread_freelist_array));
+  _M_thread_freelist = NULL;
 }
 }
   };


It seems to be on each thread-implementation to handle deleted keys and it is
well handled on pthread.

Laurent.

[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-12 
15:00:25 UTC ---
I'm testing

Index: convert.c
===
--- convert.c   (revision 186373)
+++ convert.c   (working copy)
@@ -44,11 +44,6 @@ convert_to_pointer (tree type, tree expr
   if (TREE_TYPE (expr) == type)
 return expr;

-  /* Propagate overflow to the NULL pointer.  */
-  if (integer_zerop (expr))
-return force_fit_type_double (type, double_int_zero, 0,
- TREE_OVERFLOW (expr));
-
   switch (TREE_CODE (TREE_TYPE (expr)))
 {
 case POINTER_TYPE:

at least I don't see why 0 is special - for example why we should allow
conversion of a COMPLEX_CST or VECTOR_CST to a pointer.

[Bug c++/30431] failure to check for visible declaration of friend function to template class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Jonathan Wakely  2012-04-12 
14:55:08 UTC ---
(In reply to comment #4)
> Something is wrong with the friend lookup after a member of the same name is
> encountered. After seeing the class member f (either data member or member
> function), gcc forgets that the template function f is in the current
> namespace. 

Nothing is wrong, it just finds 'f' in the class scope so doesn't look in the
enclosing namespace.  That's how name lookup works in classes.


> Bug 17122 is a duplicate, but did not see any activity in 1 year.

Yes, and like PR 17122  the code is invalid and G++ is right to reject it, but
the diagnostic could be improved.

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

[Bug c++/17122] Unable to compile friend operator within template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tkapela at poczta dot fm

--- Comment #16 from Jonathan Wakely  2012-04-12 
14:55:08 UTC ---
*** Bug 30431 has been marked as a duplicate of this bug. ***

[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc

[rhabarber1848 at web dot de]

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

rhabarber1848 at web dot de changed:

   What|Removed |Added

 CC||rhabarber1848 at web dot de

--- Comment #10 from rhabarber1848 at web dot de 2012-04-12 14:42:55 UTC ---
This bug is still present in 4.7.0.

[Bug testsuite/52948] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|UNRESOLVED: |UNRESOLVED: selfassign.c in
   |selfassign.c|dumb_plugin.c) |gcc/g++, one_time_plugin.c
   |in gcc/g++, |in gcc, and dumb_plugin.c
   |one_time_plugin.c in gcc,   |in g++
   |and dumb_plugin.c in g++|

--- Comment #1 from Dominique d'Humieres  2012-04-12 
14:27:10 UTC ---
Cleaned the summary.

[Bug testsuite/52945] FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O* -flto *

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-04-12 
14:26:04 UTC ---
> Indeed, it should be tested only when weak aliases are supposed. There is some
> dg trick for that...

Which one between '/* { dg-require-alias "" } */' and '/* { dg-require-weak ""
} */'?
Note also that I don't have any write access.

[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #6 from Richard Earnshaw  2012-04-12 
14:16:43 UTC ---
Fixed in 4.5.4, 4.6.4 4.7 and trunk