[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|Wrong result with   |Deep copy missing for array
   |constructor of derived  |constructors of DT w/
   |types w/ allocatable|allocatable components
   |components  |

--- Comment #4 from Tobias Burnus  2011-06-09 
07:26:41 UTC ---
Paul: As you (with Erik) have implemented alloc components: Do you know the
purpose of the "if (r_is_var)"? (See bottom of this comment.) I wouldn't mind
if you could work on this PR as I would like to concentrate on other gfortran
and in particular urgent non-gfortran issues...

 * * *

The cause of the failure is not really surprising; the issue is related to the
missing deep copy of the arguments:

   D.1604 = (struct t[0:] * restrict) z.data;
   (*(struct t[2] * restrict) atmp.8.data)[0] = x;
   (*(struct t[2] * restrict) atmp.8.data)[1] = y;
   (*D.1604)[(S.11 + D.1613) + D.1605]
 = (*(struct t[2] * restrict) atmp.8.data)[S.11];

The code is OK if there are no allocatable components. However, with
allocatable components, one cannot simply assign the structure, but one needs
to deep copy the (allocatable) components. For ALLOCATE (..., SOURCE=...) and
for intrinsic assignment, a similar issue exists (and is mostly solved, except
for polymorphic variables, cf. PR46174).


If one looks at gfc_trans_scalar_assign, which is called in
gfc_trans_assignment_1, one finds:

5308 else if (ts.type == BT_DERIVED && ts.u.derived->attr.alloc_comp)
...
5341   /* Do a deep copy if the rhs is a variable, if it is not the
5342  same as the lhs.  */
5343   if (r_is_var)
5344 {
5345   tmp = gfc_copy_alloc_comp (ts.u.derived, rse->expr, lse->expr, 0);
5346   tmp = build3_v (COND_EXPR, cond, build_empty_stmt (input_location),
5347   tmp);
5348   gfc_add_expr_to_block (&block, tmp);
5349 }

The "r_is_var" is given by (cf. trans-expr.c:6156):
  expr_is_variable (expr2) || scalar_to_array
and as expr2 is an EXPR_ARRAY and not a variable ...

(For non-variables, the check "Are the rhs and the lhs the same?" does not make
sense, cf. trans-expr.c:5312-5319.)

[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-06-09 
07:46:32 UTC ---
Author: jakub
Date: Thu Jun  9 07:46:28 2011
New Revision: 174839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174839
Log:
PR middle-end/49308
* dce.c (reset_unmarked_insns_debug_uses): Avoid shadowing insn
variable.  After resetting and rescanning insn continue with previous
statement.

* gfortran.dg/pr49308.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr49308.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Jakub Jelinek  2011-06-09 
07:48:45 UTC ---
Fixed.

[Bug c/48062] `shadowed declaration is here' should be a note

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2011-06-09 
07:55:37 UTC ---
(In reply to comment #2)
> Produces no warning. So for me it is a bit confusing, since the warning 
> setting
> refers to pieces of code and not to variables.

You are right and it is a bug. The reason is that each warning message (the
second should be note) is produced by different calls to warning(). These calls
are conditional on Wshadow but the #pragmas only disable Wshadow for a certain
location. The fix is to make "shadowed declaration is here" a call to inform()
(that is, a note) conditional on the first warning being emitted, which one can
test by checking the return value of warning(). Patches welcome.

[Bug c++/49338] New: wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

   Summary: wrong code with -O2 and -O3
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hsme...@arcor.de


Created attachment 24472
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24472
code that leads to wrong compiler output

test.cpp (attached) is code that has been heavily stripped from our
application.
When trying to further strip it, I also stripped the problem.
Compiled with g++ 4.5.x and without -O2 or -O3 it works as expected. 
Compiled with g++ 4.4.6 or 4.6.0 and with -O2 or -O3 it works as expected.
Compiled with g++ 4.5.x and with -O2 or -O3 it doesn't work as expected.

>/usr/local/gcc-4.5.3/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.5.3/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5.3/libexec/gcc/i686-pc-linux-gnu/4.5.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5.3/configure --prefix=/usr/local/gcc-4.5.3
Thread model: posix
gcc version 4.5.3 (GCC)
>
>
>/usr/local/gcc-4.5.3/bin/g++ test.cpp -o test
>./test
configuring window #3 to check whether value #1 is in [-3.5..3.5]
setting value #1 to 111
preparations done ...
checking whether value #1 (111) is in window #3 [-3.5..3.5] .. out of window
>
>
>/usr/local/gcc-4.5.3/bin/g++ -O2 test.cpp -o test
>./test
configuring window #3 to check whether value #1 is in [-3.5..3.5]
setting value #1 to 111
preparations done ...
checking whether value #0 (1) is in window #3 [1..1] .. in window
>

("out of window" is the correct answer, we are checking value #1 = 111 which is
not in window #3 having a range of [-3.5..3.5])

Obviously some of the m_pp...[i] pointers or the objects behind get mixed.
Moving line 59 
"unsigned Select = m_ppSelect[i]->get();" 
into the following if scope makes the problem disappear.
While stripping I had a situation where -O3 -fPIC produced the problem and -O3
did not. Unfortunately I can't reconstruct this code any more.

[Bug c++/49338] wrong code with -O2 and -O3

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-06-09 
08:10:06 UTC ---
What happens if you add -fno-strict-aliasing to the command line?

[Bug fortran/49331] Accepts invalid specification expressions

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-06-09 
08:17:30 UTC ---
The examples of the IR 11-101 do not work for me as the examples do not involve
constant expressions when defining the kind value (unless I am seriously
mistaken).

Better/shorter example:

module m
  type t
integer :: i
  end type t

  interface LEN
module procedure my_len
  end interface LEN

contains

  function one(x)
type(t),intent(in) :: x
character(len=LEN(x)) :: one
one = ''
  end function one

  integer pure function my_len(x)
type(t), intent(in) :: x
my_len  = x%i
  end function my_len
end module m


The suggested wording for specification expressions - but also for constant
expressions (cf. 11-101 for the latter) is:

  Replace F08/7.1.11p9 [10-007:151:13-15] by

  "A generic entity referenced in a specification expression in the
of a scoping unit shall have no specific
   procedures defined in that scoping unit, or its host scoping unit,
   subsequent to the specification expression."

Thus, the example would also be invalid if instead of
  LEN(x)   ! Calls specific which is later defined
one had used
  LEN(x%i) ! Call intrinsic LEN
(and, indeed, crayftn also rejects that example).


I wonder whether there is a better method than:

  if (generic_sym->ns == current_ns->parent && !generic_sym->attr.use_assoc)
{
LOOP through all specific_sym:
  if (current_ns->parent == specific_sym->ns->parent)
  && LOCATION_LINE (current_loc->location)
 < LOCATION_LINE (specific_sym->declared_at->location))
gfc_error (...)
}

(In case the specific function is referenced for a specific function which is
an internal function, gfortran already prints: "Error: Generic function 'len'
at (1) is not consistent with a specific intrinsic interface".)


 * * *

Example for a constant expression:

module m
  type t
integer :: i
  end type t
  interface LEN
module procedure my_len
  end interface LEN
contains
  function one(x)
type(t),intent(in) :: x
character(kind=kind(LEN())) :: one
one = ''
  end function one
  integer pure function my_len()
my_len  = 1
  end function my_len
end module m

[Bug c++/49339] New: [C++0x][lambda][unused-parameter]g++ reports unused parameter even it's referenced in function

[lene13 at gmail dot com]

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

   Summary: [C++0x][lambda][unused-parameter]g++ reports unused
parameter even it's referenced in function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: len...@gmail.com


I'm using ArchLinux with GCC 4.6.0 (20110603).
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.6-20110603/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--disable-multilib --disable-libstdcxx-pch --enable-checking=release
Thread model: posix
gcc version 4.6.0 20110603 (prerelease) (GCC)

When compiling following codes

#include 
#include 
#include 
#include 

template 
void append(std::vector<_RawType>& former, std::vector<_RawType>&& latter)
{
std::for_each(latter.begin()
, latter.end()
, [&](_RawType& x)
  {
  former.push_back(std::move(x));
  });
}

int main(void)
{
std::vector aa;
append(aa, std::vector());
return 0;
}

with

g++ % -Wunused-parameter -std=c++0x

g++ prints

unused-param.cpp: In instantiation of ‘append(std::vector<_RealType>&,
std::vector<_RealType>&&) [with _RawType = int]::’:
unused-param.cpp:9:5:   instantiated from ‘void append(std::vector<_RealType>&,
std::vector<_RealType>&&) [with _RawType = int]’
unused-param.cpp:20:34:   instantiated from here
unused-param.cpp:11:34: warning: unused parameter ‘x’ [-Wunused-parameter]

but `x` is referenced in line 13 ("former.push_back(std::move(x));").

[Bug c++/49338] wrong code with -O2 and -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2011-06-09 
08:22:18 UTC ---
double get() const
{
U64 rv=m_Value.m_U64 & ~((U64)1);
const double* pRv=(double*)(&rv);
return *pRv;
}
is an obvious aliasing violation.

[Bug c++/49338] wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

--- Comment #3 from Hans Meier  2011-06-09 08:24:07 
UTC ---
(In reply to comment #1)
> What happens if you add -fno-strict-aliasing to the command line?

Problem disappears (tested all 4.5.x both with -O2 and -O3). 
Thanks! We can probbly live with that.

[Bug c++/49338] wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

--- Comment #4 from Hans Meier  2011-06-09 08:42:31 
UTC ---
(In reply to comment #2)
> is an obvious aliasing violation.

yes, but why does this lead to read from other objects than it is intended? -
The "[1..1]" comes from m_ppSelect[i] when reading m_ppUpperLimit[i] and
m_ppLowerLimit[i], if we change Select to 0 the range also changes to [0..0]
etc.  
btw: this code sequence in our software is called about 10 million times per
second from more than 1000 occurrences in 100 classes and only in this singe
constellation it doesn't work. Considering these figures it is THE hotspot for
performance optimization and this is the fastest implementation I could find
within weeks of experimenting.

[Bug c++/49338] wrong code with -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-09 
08:47:44 UTC ---
You should read the standard or at least
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Optimize-Options.html#index-fstrict_002daliasing-824

[Bug c++/49338] wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

--- Comment #6 from Hans Meier  2011-06-09 08:59:11 
UTC ---
(In reply to comment #2)
> is an obvious aliasing violation.
... and if so, shouldn't -Wstrict-aliasing emit a warning? None of the
mentioned compilers (4.4.6 - 4.6.0) does it.

[Bug c++/49338] wrong code with -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-06-09 
09:08:51 UTC ---
Try -Wstrict-aliasing=2 or -Wstrict-aliasing=1 if -Wstrict-aliasing doesn't
report anything.  Anyway, why are you fighting so hard to avoid fixing your
buggy code?  It isn't hard to rewrite it using an union:
  union { U64 i; double d; } u;
  u.i = m_Value.m_U64 & ~((U64)1);
  return u.d;

[Bug ada/49337] Improve Gnatmake to work without static libraries.

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-06-09 
09:23:49 UTC ---
Please post patches to gcc-patc...@gcc.gnu.org.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.09 09:36:46
 CC||ebotcazou at gcc dot
   ||gnu.org
  Component|c   |rtl-optimization
 Ever Confirmed|0   |1
  Known to fail||4.3.5, 4.4.5, 4.5.3, 4.6.0,
   ||4.7.0

--- Comment #2 from Richard Guenther  2011-06-09 
09:36:46 UTC ---
I can confirm the original testcase with r173419 (not the one from comment#1).
The tree level optimizers handle this ok and we expand from

:
  px_1 = (uintptr_t) &x;
  py_2 = (uintptr_t) &y;
  d.0_3 = px_1 - py_2;
  d ={v} d.0_3;
  d.1_4 ={v} d;
  p_5 = d.1_4 + py_2;
  x = 1;
  # PT = { x y } (glob)
  p.2_6 = (int *) p_5;
  *p.2_6 = 2;
  D.2722_7 = x;
  return D.2722_7;

where you can also see that we correctly assume that p.2_6 may point either
x or y.

CSE1 optimizes the load from x to 1.

[Bug c++/29003] operator name accepted in typedef

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #4 from Paolo Carlini  2011-06-09 
09:39:18 UTC ---
Looking into it.

[Bug c++/49338] wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

--- Comment #8 from Hans Meier  2011-06-09 09:44:28 
UTC ---
(In reply to comment #7)
> It isn't hard to rewrite it using an union:

a similar solution with a union was one of my earlier attempts to
performance-optimize our code. unfortunately this lead to a horrible
performance
degrade - the critical realtime thread of our application was 60% slower then.
analysis showed that things were not kept in registers but instead we had a fp
push and pop in the assembly (with 4.5.1). the code looked like this:

union{double d;U8 uc[8];} rv;
rv.d=m_Value.Value;
rv.uc[0]=rv.uc[0] & ~((U8)1);
return rv.d;

maybe your version with U64 instead of double at the input to the union doesn't
suffer this performance penalty, so i will try it and if it performs good i
certainly will switch to this solution.

otherwise yes, -Wstrict-aliasing=1 and -Wstrict-aliasing=2 both warn, I just
thought -Wstrict-aliasing which in fact is described as being equivalent to
-Wstrict-aliasing=3 and thus included in -Wall would detect more than =1 or =2

so far and most important, thanks a lot for the immediate help!

[Bug c++/49339] [C++0x][lambda][unused-parameter]g++ reports unused parameter even it's referenced in function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.09 09:47:10
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-06-09 
09:47:10 UTC ---
I can confirm the warning.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-06-09 
10:04:28 UTC ---
Ugh.
base_alias_check for
(symbol_ref:DI ("x") )
and
(plus:DI (reg:DI 62 [ d.1 ])
(symbol_ref:DI ("y") ))
returns 0.  I'm afraid dropping the base_alias_check call would significantly
penalize generated code, after all we still sometimes have MEM accesses without
MEM_EXPR.  Perhaps we could rely on REG_POINTER bits, extend them to SYMBOL_REF
too and only do return NULL from find_base_term if SYMBOL_REF doesn't have
SYMBOL_REF_POINTER bit set.  During CSE etc., when replacing a pseudo with its
definition REG_POINTER/SYMBOL_REF_POINTER would be kept only if it is set on
the pseudo being optimized away as well.  Thus, any casts from pointers to
correspondingly sized integers and back would be seen in the RTL.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  
2011-06-09 10:08:55 UTC ---
On Thu, 9 Jun 2011, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #3 from Jakub Jelinek  2011-06-09 
> 10:04:28 UTC ---
> Ugh.
> base_alias_check for
> (symbol_ref:DI ("x") )
> and
> (plus:DI (reg:DI 62 [ d.1 ])
> (symbol_ref:DI ("y") ))
> returns 0.  I'm afraid dropping the base_alias_check call would significantly
> penalize generated code, after all we still sometimes have MEM accesses 
> without
> MEM_EXPR.  Perhaps we could rely on REG_POINTER bits, extend them to 
> SYMBOL_REF
> too and only do return NULL from find_base_term if SYMBOL_REF doesn't have
> SYMBOL_REF_POINTER bit set.  During CSE etc., when replacing a pseudo with its
> definition REG_POINTER/SYMBOL_REF_POINTER would be kept only if it is set on
> the pseudo being optimized away as well.  Thus, any casts from pointers to
> correspondingly sized integers and back would be seen in the RTL.

Maybe restrict the base_alias_check to var-decls that do not have
their address taken?  Points-to analysis should conver them.

Richard.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-06-09 
10:22:57 UTC ---
The testcase also fails similarly without the volatile qualification of d
when compiling with -O -fno-tree-fre -fno-tree-forwprop -fno-tree-reassoc

[Bug target/49335] [4.6 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.5.3
   Keywords||wrong-code
   Last reconfirmed||2011.06.09 10:23:41
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|ARM: Invalid assembler  |[4.6 Regression] ARM:
   |generated while compiling   |Invalid assembler generated
   |C++ code from 'codeblocks'  |while compiling C++ code
   ||from 'codeblocks'
  Known to fail||4.6.0, 4.7.0

--- Comment #2 from Ramana Radhakrishnan  2011-06-09 
10:23:41 UTC ---
The problem is that *arith_shiftsi allows *all* shiftable operators to have the
stack pointer as Rn . 

In Thumb2 only the add and sub instructions are allowed to have the stack
pointer in this form and all other instructions are UNPREDICTABLE. This has
come as a result of merging the 2 patterns from ARM and Thumb2 into a single
pattern and considering the same for both. 

Affects only 4.6 branch and FSF trunk.

cheers
Ramana

[Bug target/49335] [4.6 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  2011-06-09 
10:25:15 UTC ---
(In reply to comment #2)
> The problem is that *arith_shiftsi allows *all* shiftable operators to have 
> the
> stack pointer as Rn . 
> 
> In Thumb2 only the add and sub instructions are allowed to have the stack
> pointer in this form and all other instructions are UNPREDICTABLE. 

This is for operations of the form :

 rd, rn, rm lsl 2

cheers
Ramana

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-06-09 
10:38:37 UTC ---
find_base_value/find_base_term seem to be overly optimistic, prefer to return
something over being conservative.  E.g. if both operands of PLUS or MINUS
return non-NULL find_base_term, we just return the first one, etc.
It doesn't differentiate between "certainly not based on something" - e.g.
CONST_INT, regs only initialized by them and only incremented by constant etc.
would be such and unknown.  While the overly optimistic implementation might be
useful in some cases, at least for base_alias_check it is inappropriate.

[Bug c++/49338] wrong code with -O2 and -O3

[hsmeier at arcor dot de]

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

--- Comment #9 from Hans Meier  2011-06-09 10:38:45 
UTC ---
final note: code from comment 7 performs well in contrast to the old code shown
in comment 8, so this problem is solved for us. thanks again!

[Bug target/48429] ARM __attribute__((interrupt("FIQ"))) not optimizing register allocation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.09 10:39:47
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.4.5, 4.5.2, 4.6.0

--- Comment #1 from Ramana Radhakrishnan  2011-06-09 
10:39:47 UTC ---
Confirmed.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[Kira.Backes at NRWsoft dot de]

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

Kira Backes  changed:

   What|Removed |Added

 CC||Kira.Backes at NRWsoft dot
   ||de

--- Comment #15 from Kira Backes  2011-06-09 
11:22:35 UTC ---
Half a year since the last comment has passed but I still can't use emplace and
this means I can't use unique_ptr in a map (or can I?).

Is it really so hard to code emplace methods? Can we somehow help?



rgds, Kira

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #16 from Paolo Carlini  2011-06-09 
11:30:42 UTC ---
I don't see what the emplace members have to do with unique_ptr. Anyway, I'm
working on something else at the moment, contributions are always welcome, just
file a Copyright Assignment and send over patches, thanks in advance!

[Bug c++/49329] Static method with std::string parameter gets messed up with non-static method with bool parameter

[swante2 at web dot de]

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

Swante  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Swante  2011-06-09 11:36:45 UTC ---
>(In reply to comment #2)
> you might want to rethink that
> 
> cc::xx is a qualified name lookup, so can find both overloads of cc::xx
> 
> The implicit pointer-to-bool conversion is a better conversion sequence than
> the user-defined conversion char*-to-std::string so it is selected, but 
> calling
> a member function without an an object is obviously ill-formed

Thanks for the quick replies.
I wasn't aware that the pointer-to-bool conversion is considered by gcc to be
better than a char*-to-std::string conversion.
I also thought, that the first thing the compiler would do, is to
rule out any non-static methods when a static method is inquired;
but apparently I was wrong.

I'll mark the issue as resolved then.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini  2011-06-09 
11:46:12 UTC ---
Eg, this works perfectly well already, since I added the insert members:

  set> s;
  unique_ptr up;
  s.insert(std::move(up));

[Bug gcov-profile/49340] New: read_couts_file() not called for -fbranch-probabilities

[Martin.vGagern at gmx dot net]

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

   Summary: read_couts_file() not called for
-fbranch-probabilities
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martin.vgag...@gmx.net


$ cat test.c
#include 

int main(int argc, char** argv) {
  int i;
  for (i = 0; i < argc; ++i) {
printf("argv[%d] = \"%s\"\n", i, argv[i]);
  }
  return 0;
}

$ rm -f test.gcda
$ gcc -o prof -fprofile-arcs test.c
$ ./prof
argv[0] = "./prof"
$ test -f test.gcda && gcc -o final -fbranch-probabilities test.c
test.c: In function ‘main’:   test.c:9:1: note: file $PWD/test.gcda not found,
execution counts assumed to be zero

Identified the relevant command via strace and ran it through gdb:
$ gdb --args /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.2/cc1 -quiet test.c \
  -D_FORTIFY_SOURCE=2 -quiet -dumpbase test.c -mtune=generic -march=x86-64 \
  -auxbase test -fbranch-probabilities -o test.s
It appears that coverage_init does not call read_counts_file because
flag_profile_use is zero. So cc1 doesn't even attempt to read the file for
which it claims it wasn't found.

It appears that this is a problem introduced by gcc 4.4.0 in this commit:
http://gcc.gnu.org/viewcvs/trunk/gcc/coverage.c?r1=133773&r2=133774

GCC version is "gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2", my system is
x86_64-pc-linux-gnu. The Gentoo build was configured using USE=vanilla, so
there should be no Gentoo-specific patches involved. If you have any trouble
reproducing the issue, let me know and I'll see what other details I can
provide.

[Bug c++/49329] Static method with std::string parameter gets messed up with non-static method with bool parameter

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-06-09 
11:48:40 UTC ---
(In reply to comment #3)
> I wasn't aware that the pointer-to-bool conversion is considered by gcc to be
> better than a char*-to-std::string conversion.

A standard conversion sequence (i.e. one built-in to the language) is better
than a user-defined conversion sequence (i.e. one using class constructors or
conversion operators)

The C++ standard defines those rules, not gcc.

> I also thought, that the first thing the compiler would do, is to
> rule out any non-static methods when a static method is inquired;
> but apparently I was wrong.

C++ has no concept of "when a static method is inquired" - you call a function
by name, so it is looked up by name, then overload resolution selects which
function is being called. xx::cc refers to the name cc in the scope xx, it
doesn't refer only to a static function.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  2011-06-09 
11:51:34 UTC ---
(In reply to comment #15)
> Is it really so hard to code emplace methods? Can we somehow help?

It's not so hard, but we have limited resources and other priorities.

Patches welcome, see
http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[Kira.Backes at NRWsoft dot de]

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

--- Comment #19 from Kira Backes  2011-06-09 
11:59:29 UTC ---
Because the usual add functions would have to copy the unique_ptr and that
doesn't work. As I see it in a map there are only insert functions for pairs.
So if this works I'd have to create a pair and then use the created pair to
insert it into the map, I'm gonna test it. But it would double the code size.

As I understand it the emplace is just like an alias that forwards the 2
parameters into a pair constructor and inserts it afterwards.



rgds, Kira

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini  2011-06-09 
12:08:01 UTC ---
For sure the rationale behind emplace isn't inserting a pair of unique_ptrs in
a map: maybe it can be a little more convenient in terms of lines of user code,
but isn't the reason emplace exists.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[Kira.Backes at NRWsoft dot de]

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

--- Comment #21 from Kira Backes  2011-06-09 
12:21:07 UTC ---
Hi,



I don't mean a pair of unique_ptr, just any combination with a unique_ptr.

I for example very often need:

std::map> instancesByIds_;


Now if I want to insert a User, with a shared_ptr I'd have to do:

instancesByIds_[id] = user;


Now with a unique_ptr I'd like to do the same:


instancesByIds_[id] = user;
instancesByIds_[id] = std::move(user);

Both doesnt work. Emplace is the practical solution (please correct me if
there's a better way):


instancesByIds_.emplace(id, std::move(user));



rgds, Kira

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  2011-06-09 
12:25:15 UTC ---
(In reply to comment #21)
> Now with a unique_ptr I'd like to do the same:
> 
> 
> instancesByIds_[id] = user;
> instancesByIds_[id] = std::move(user);
> 
> Both doesnt work.

Nonsense. The second one works fine.

This works too:

instancesByIds_.insert(make_pair(id, std::move(user)));

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[Kira.Backes at NRWsoft dot de]

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

--- Comment #23 from Kira Backes  2011-06-09 
12:27:31 UTC ---
(In reply to comment #22)
> Nonsense. The second one works fine.

Nope, it really doesn't! Or was this fixed in GCC 4.6.0 (I'm on 4.5.0 and this
bug report is tagged to 4.5.0)

Do you just claim this to work or did you actually test this?



rgds, Kira

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  2011-06-09 
12:35:15 UTC ---
I tested it. It works.


Just because the PR was reported against 4.5 doesn't mean it'll be fixed in
that release series. Note there's no Target Milestone set for this PR.  I can
assure you the emplace member are not going to be added to GCC 4.5 so even when
this is resolved you'll need to upgrade to use them.

If you want to use the experimental C++0x support you really need to use an
up-to-date release, complaining about lack of features in old releases is a
waste of time, the 4.5 branch is only open for fixing regressions and updating
documentation:
http://gcc.gnu.org/ml/gcc/2011-04/msg00412.html

[Bug middle-end/49341] New: [4.7 Regression] FAIL: gcc.dg/20051207-3.c and gcc.dg/tls/section-1.c

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL: gcc.dg/20051207-3.c and
gcc.dg/tls/section-1.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 174836 gave

FAIL: gcc.dg/20051207-3.c (test for excess errors)
FAIL: gcc.dg/tls/section-1.c (test for excess errors)

Revision 174833 is OK.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[Kira.Backes at NRWsoft dot de]

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

--- Comment #25 from Kira Backes  2011-06-09 
12:41:42 UTC ---
I'm sorry, don't misunderstand me, I'm willing to upgrade. I'm right now
upgrading to 4.6

When I googled for this problem a year ago I've read that the second line
doesn't work by *specification* and that you *have* to use emplace. I apologize
for believing that crap (or maybe it was correct back then and the
specification has been improved).


Thanks for your help! :-)



rgds, Kira

[Bug other/49342] New: asm goto documentation error in code snippet

[benjamin.poirier at gmail dot com]

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

   Summary: asm goto documentation error in code snippet
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: benjamin.poir...@gmail.com


Created attachment 24473
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24473
patch that fixes said documentation error

in gcc/doc/extend.texi or http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

The third example for asm goto usage has a bug:
 #define TRACE1(NUM) \
   do {  \
 asm goto ("0: nop;" \
   ".pushsection trace_table;"   \
   ".long 0b, %l0;"  \
   ".popsection" \
   : : : : trace#NUM);   \
 if (0) { trace#NUM: trace(); }  \
   } while (0)
 #define TRACE  TRACE1(__COUNTER__)

trace#NUM should be trace##NUM (in both places), we're trying to generate
unique label names. Compiling the example as-is fails.

[Bug testsuite/49341] [4.7 Regression] FAIL: gcc.dg/20051207-3.c and gcc.dg/tls/section-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org
  Component|middle-end  |testsuite
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-06-09 13:00:03 
UTC ---
It is caused by revision 174836:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00325.html

[Bug tree-optimization/49343] New: [4.7 regression] ICE on field with variable offset

[ebotcazou at gcc dot gnu.org]

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

   Summary: [4.7 regression] ICE on field with variable offset
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org


This is a problem recently exposed on the mainline.  SRA (early variant)
decides to scalarize a record containing a field with variable offset and
aborts:

+===GNAT BUG DETECTED==+
| 4.7.0 20110608 (experimental) [trunk revision 174799] (i586-suse-linux-gnu)
GCC error:|
| in tree_low_cst, at tree.c:6441  |
| Error detected around discr31.adb:12:1

#0  internal_error (gmsgid=0x92e69cf "in %s, at %s:%d")
at /home/eric/svn/gcc/gcc/diagnostic.c:837
#1  0x0909efc2 in fancy_abort (file=0x91b9220 "/home/eric/svn/gcc/gcc/tree.c",
line=6441, function=0x91bb8ce "tree_low_cst")
at /home/eric/svn/gcc/gcc/diagnostic.c:893
#2  0x08aa8c07 in tree_low_cst (t=0xf7d9cf50, pos=0)
at /home/eric/svn/gcc/gcc/tree.c:6441
#3  0x08a86f60 in int_bit_position (field=0xf7cd4c38)
at /home/eric/svn/gcc/gcc/tree.c:2364
#4  0x0896be08 in build_ref_for_model (loc=41221, base=0xf7d92ea0, offset=32,
model=0x9a99d50, gsi=0xcd34, insert_after=0 '\000')
at /home/eric/svn/gcc/gcc/tree-sra.c:1425
#5  0x0896f6a1 in generate_subtree_copies (access=0x9a99d50, agg=0xf7d92ea0,
top_offset=0, start_offset=0, chunk_size=0, gsi=0xcd34,
write=0 '\000', insert_after=0 '\000', loc=41221)
at /home/eric/svn/gcc/gcc/tree-sra.c:2297
#6  0x0897155b in sra_modify_assign (stmt=0xcd30, gsi=0xcd34)
at /home/eric/svn/gcc/gcc/tree-sra.c:2823
#7  0x08971c07 in sra_modify_function_body ()
at /home/eric/svn/gcc/gcc/tree-sra.c:2942
#8  0x08972185 in perform_intra_sra ()
#9  0x08972280 in early_intra_sra () at /home/eric/svn/gcc/gcc/tree-sra.c:3079

Testcase suitable for the gnat.dg testsuite to be attached, run 'gnatchop' on
it and compile at -O the .adb file.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[hyounes at google dot com]

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

--- Comment #26 from Haakan Younes  2011-06-09 
13:03:19 UTC ---
(In reply to comment #18)
> (In reply to comment #15)
> > Is it really so hard to code emplace methods? Can we somehow help?
> 
> It's not so hard, but we have limited resources and other priorities.
> 
> Patches welcome, see
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

I started looking into it about a year ago, before you added insert(&&).  It
seems easy enough to add emplace for map, but what about set?

For map, the first argument to emplace is going to be the key (I believe).  We
can therefore determine if the key is already present in the map before we
construct the value object from the remaining arguments to emplace.

For set, the key is the value, so I don't see a way to avoid constructing the
value object from the arguments to emplace before you know if it should be
inserted.

Am I thinking about it the wrong way?

BTW, I have been happily using insert(&&) for maps for at least 6 months (GCC
built from trunk).  I strongly suspect it is available with GCC 4.6.  You
definitely do not need emplace to store unique_ptr values in a map.

[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  2011-06-09 
13:03:28 UTC ---
Created attachment 24474
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24474
Concatenated testcase

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely  2011-06-09 
13:13:36 UTC ---
(In reply to comment #25)
> When I googled for this problem a year ago I've read that the second line
> doesn't work by *specification* and that you *have* to use emplace.

No, that's never been true.

The type of instancesByIds_[id] is a reference to the mapped_type, i.e.
unique_ptr& and you have always been able to move assign to a unique_ptr
from an rvalue, by design.

You would have to use emplace for a container of objects which were not
copyable *or* movable, but unique_ptr is movable.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  2011-06-09 
13:27:56 UTC ---
(In reply to comment #26)
> For map, the first argument to emplace is going to be the key (I believe).  We
> can therefore determine if the key is already present in the map before we
> construct the value object from the remaining arguments to emplace.

Not necessarily:

std::map m;
m.emplace(piecewise_construct_t, make_tuple(1), make_tuple(2));

[Bug bootstrap/49344] New: ICE in tree-flow-inline.h:745 while bootstrap

[revital.eres at linaro dot org]

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

   Summary: ICE in tree-flow-inline.h:745 while bootstrap
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: revital.e...@linaro.org
Target: ppc64-redhat-linux


I get the following error while bootstrap -r174840 on ppc64-redhat-linux with
the config file and -O2 flag:

 ../gcc/configure --prefix=/home/eres/mainline/build --enable-checking
--enable-bootstrap --enable-languages=java

libtool: compile:  /home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/ -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include -m32 -fPIC
-mstrict-align -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc/libjava/classpath/native/fdlibm -I../../include
-fexceptions -fasynchronous-unwind-tables -g -O2 -m32 -fPIC -mstrict-align -MT
w_asin.lo -MD -MP -MF .deps/w_asin.Tpo -c
../../../../../../../gcc/libjava/classpath/native/fdlibm/w_asin.c  -fPIC -DPIC
-o .libs/w_asin.o
libtool: compile:  /home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/ -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include -m32 -fPIC
-mstrict-align -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc/libjava/classpath/native/fdlibm -I../../include
-fexceptions -fasynchronous-unwind-tables -g -O2 -m32 -fPIC -mstrict-align -MT
w_acos.lo -MD -MP -MF .deps/w_acos.Tpo -c
../../../../../../../gcc/libjava/classpath/native/fdlibm/w_acos.c  -fPIC -DPIC
-o .libs/w_acos.o
libtool: compile:  /home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/ -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include -isystem
/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include -m32 -fPIC
-mstrict-align -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc/libjava/classpath/native/fdlibm -I../../include
-fexceptions -fasynchronous-unwind-tables -g -O2 -m32 -fPIC -mstrict-align -MT
w_atan2.lo -MD -MP -MF .deps/w_atan2.Tpo -c
../../../../../../../gcc/libjava/classpath/native/fdlibm/w_atan2.c  -fPIC -DPIC
-o .libs/w_atan2.o
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c: In function
ג_Jv_strtod_rג:
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c:106:1:
internal compiler error: in op_iter_init, at tree-flow-inline.h:745
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [strtod.lo] Error 1

[Bug target/48673] [4.7 Regression] GCC generates WAW and RAW conflicts on IA64.

[bernds at gcc dot gnu.org]

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

--- Comment #8 from Bernd Schmidt  2011-06-09 
13:55:44 UTC ---
Author: bernds
Date: Thu Jun  9 13:55:41 2011
New Revision: 174844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174844
Log:
PR target/48673
* config/ia64/ia64.c (ia64_reorg): Clear BB_DISABLE_SCHEDULE flag
in all basic blocks.

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

[Bug target/48673] [4.7 Regression] GCC generates WAW and RAW conflicts on IA64.

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Bernd Schmidt  2011-06-09 
13:56:05 UTC ---
Fixed.

[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

Anitha Boyapati  changed:

   What|Removed |Added

 CC||anitha.boyapati at atmel
   ||dot com

--- Comment #3 from Anitha Boyapati  
2011-06-09 14:01:22 UTC ---
(In reply to comment #1)
> Increased the importance from P3 to P3 because this makes avr-gcc+dwarf-2
> completely unusable. 
> 
> Configuring as --target=avr --with-dwarf2 fails to build cross compiler.

It fails with the message:

configure:3055: /home/anitha/comp/gcc-4.6.0/objdir/./gcc/xgcc
-B/home/anitha/comp/gcc-4.6.0/objdir/./gcc/ -B/home/anitha/install/avr/bin/
-B/home/anitha/install/avr/lib/ -isystem /home/anitha/install/avr/include
-isystem /home/anitha/install/avr/sys-include-o conftest -O2 -g  
conftest.c  >&5
conftest.c:1:0: internal compiler error: in dwarf2out_frame_init, at
dwarf2out.c:4260


Further analysis shows that the changes introduced in revision 164701 (Found in
Tag: gcc_4_6_0_release) cause ICE.

http://gcc.gnu.org/viewcvs/tags/gcc_4_6_0_release/gcc/dwarf2out.c?r1=164670&r2=164701&diff_format=h

The macros DWARF2_UNWIND_INFO is undefined for AVR Target and hence the
initial_return_save() is neither defined nor called in 4.5.* versions. However
in 4.6.0 these macros are replaced with 'targetm' hooks, which return UI_DWARF2
and hence the function initial_return_save() gets called. Since
INCOMING_RETURN_ADDR_RTX is not defined, it results in ICE. (I have given the
preprocessed output from dwarf2out_frame_init() function).


- if (DWARF2_UNWIND_INFO || DWARF2_FRAME_INFO)
- initial_return_save (INCOMING_RETURN_ADDR_RTX);

+ if (targetm.debug_unwind_info () == UI_DWARF2
+ || targetm.except_unwind_info (&global_options) == UI_DWARF2)
+initial_return_save (((fancy_abort ("../../gcc/dwarf2out.c", 4260,
__FUNCTION__)), (rtx) 0));


Replacing DWARF2_UNWIND_INFO with targetm.debug_unwind_info() is either
incorrect or is incomplete for AVR Target. This remains to be analysed. 

This is a blocker for bug #17994

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-06-09 
14:17:45 UTC ---
Created attachment 24475
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24475
patch

Here's an untested patch.  Does this fix the problem for you?  Naturally you'll
want to revert it once dwarf2 unwind info is supported.

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|ppc64-redhat-linux  |ppc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.09 14:41:57
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-06-09 
14:41:57 UTC ---
Confirmed on powerpc-apple-darwin* (see
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip).
I'll attach the preprocessed file strtod.i. The backtrace of

/opt/gcc/darwin_buildw/gcc/cc1 -O2 -g strtod.i

(-m32 default) is

#0  fancy_abort (file=0x9a4664 "../../work/gcc/tree-flow-inline.h", line=745,
function=0xb886e4 "op_iter_init") at ../../work/gcc/diagnostic.c:893
#1  0x007a4570 in op_iter_init () at tree-flow-inline.h:743
#2  0x007ac974 in convert_mult_to_fma (mul_stmt=0xcf08bc, op1=0xd12e70,
op2=0x41fa8bd0) at ../../work/gcc/tree-ssa-math-opts.c:2132
#3  0x007acd4c in execute_optimize_widening_mul () at
../../work/gcc/tree-ssa-math-opts.c:2319
#4  0x005b3d24 in execute_one_pass (pass=0xbbefd4) at
../../work/gcc/passes.c:1899
#5  0x005b40b8 in execute_pass_list (pass=0xc0) at
../../work/gcc/passes.c:1953
#6  execute_pass_list (pass=0xbbe850) at ../../work/gcc/passes.c:1955
#7  0x00703088 in tree_rest_of_compilation (fndecl=0x41fc5480) at
../../work/gcc/tree-optimize.c:417
#8  0x0029dde0 in cgraph_expand_function (node=0x41fab1f8) at
../../work/gcc/cgraphunit.c:1635
#9  0x0029fe08 in cgraph_optimize () at ../../work/gcc/cgraphunit.c:1694
#10 0x002a052c in cgraph_finalize_compilation_unit () at
../../work/gcc/cgraphunit.c:1131
#11 0x000200ec in c_write_global_declarations () at
../../work/gcc/c-decl.c:9844
#12 0x0067ae54 in toplev_main (argc=3, argv=0x0) at ../../work/gcc/toplev.c:586
#13 0x1ca0 in start ()

According http://gcc.gnu.org/ml/gcc-regression/2011-06/msg00099.html, the
failure occurred between revisions 174833 and 174836.

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-06-09 
14:42:37 UTC ---
Created attachment 24476
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24476
preprocessed file strtod.i

[Bug c++/29003] operator name accepted in typedef

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  
2011-06-09 15:07:05 UTC ---
Author: paolo
Date: Thu Jun  9 15:06:59 2011
New Revision: 174846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174846
Log:
/cp
2011-06-09  Paolo Carlini  

PR c++/29003
* decl.c (grokdeclarator): Reject operator names in typedefs.

/testsuite
2011-06-09  Paolo Carlini  

PR c++/29003
* g++.dg/parse/error38.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/error38.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/29003] operator name accepted in typedef

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  2011-06-09 
15:07:57 UTC ---
Done.

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-06-09 
15:13:18 UTC ---
Sounds a bit strange.  It must be (my tree doesn't match the lines exactly):

  /* Make sure the negate statement becomes dead with this
 single transformation.  */
  if (!single_imm_use (gimple_assign_lhs (use_stmt),
   &use_p, &neguse_stmt))
return false;

  /* Make sure the multiplication isn't also used on that stmt.  */
  FOR_EACH_SSA_TREE_OPERAND (use, neguse_stmt, iter, SSA_OP_USE)
if (use == mul_result)
  return false;

"guessed patch":

Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 174845)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -2174,7 +2174,7 @@ convert_mult_to_fma (gimple mul_stmt, tr
   if (use_code == NEGATE_EXPR)
{
  ssa_op_iter iter;
- tree use;
+ use_operand_p usep;

  result = gimple_assign_lhs (use_stmt);

@@ -2185,8 +2185,8 @@ convert_mult_to_fma (gimple mul_stmt, tr
return false;

  /* Make sure the multiplication isn't also used on that stmt.  */
- FOR_EACH_SSA_TREE_OPERAND (use, neguse_stmt, iter, SSA_OP_USE)
-   if (use == mul_result)
+ FOR_EACH_PHI_OR_STMT_USE (usep, neguse_stmt, iter, SSA_OP_USE)
+   if (USE_FROM_PTR (usep) == mul_result)
  return false;

  /* Re-validate.  */

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org

--- Comment #4 from Dominique d'Humieres  2011-06-09 
15:15:00 UTC ---
CCed Andi Kleen (BTW Andi could you update your email address in MAINTAINERS?
TIA).

[Bug target/49257] -mfpmath=sse generates x87 instructions on 32 bits OS

[rth at gcc dot gnu.org]

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

--- Comment #17 from Richard Henderson  2011-06-09 
15:39:33 UTC ---
The Problem here is that using the 387 for these conversions is
normally a Good Thing.  Even when we're not mixing 387 and SSE math,
the 387 can do the conversion in 1 insn.  Add a couple more for 
pushing the data between functional units and we've *still* got code
that's significantly smaller and faster than any pure SSE alternative.

Ignoring SSE and -mfpmath=sse for a moment, we've said that you
simply can't use FP math in a region that's using MMX operations
because that must needs use the FPU in 387 mode.  I'm not sure
that this stance should be altered just because -mfpmath=sse is
in effect.

Is there some Really Good Reason you're using MMX at all?  I mean,
you've explicitly said via compiler flags that the target cpu is
SSE enabled.  What can MMX do that SSE2 cannot?

We could do something with the code written in this thread in the
context of -mno-80387 -msse, but I'm not really sure it's worth it.
How often would it really be used, honestly?

I'm inclined to mark this bug as either INVALID or WONTFIX.

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen  2011-06-09 
16:06:34 UTC ---
Hmm, it's hard to see how my patch could have caused this.
It doesn't really change any RTL.

Does the test case even use global registers?

I don't see any in native/fdlibm/strtod.c

The only thing that could possibly have a side effect is storing
the decl in a global array, but even that should be benign.

Are you sure you bisected right?

[Bug c++/38646] [4.3/4.4 regression] ICE with invalid specialization of variadic template

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2011-06-09 
16:14:50 UTC ---
Likewise, close as fixed in 4.5+?

[Bug c++/38089] [4.3/4.4 Regression] g++ crash on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #9 from Paolo Carlini  2011-06-09 
16:14:14 UTC ---
Shall we close this as fixed in 4.5+?

[Bug c++/43081] [4.3/4.4 regression] ICE with invalid in-class initializer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #8 from Paolo Carlini  2011-06-09 
16:16:12 UTC ---
And this one, fixed in 4.5+?

[Bug c++/34491] [4.3/4.4/4.5 regression] ICE invalid template specialization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||FIXED
   Target Milestone|4.6.1   |4.6.0

--- Comment #9 from Paolo Carlini  2011-06-09 
16:18:18 UTC ---
Fixed for 4.6.0.

[Bug c++/30298] [4.3/4.4/4.5 regression] ICE with duplicate broken inheritance

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.6.1   |4.6.0

--- Comment #15 from Paolo Carlini  2011-06-09 
16:17:37 UTC ---
Fixed.

[Bug c++/34756] [4.3/4.4/4.5 regression] ICE with broken specialization of variadic template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.6   |4.6.0

--- Comment #9 from Paolo Carlini  2011-06-09 
16:19:01 UTC ---
Fixed for 4.6.0.

[Bug c++/42054] [4.3/4.4 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-06-09 
16:15:29 UTC ---
Fixed in 4.5+?

[Bug c++/35112] [4.3/4.4 regression] ICE and broken diagnostic with ambiguous class name

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #13 from Paolo Carlini  2011-06-09 
16:19:44 UTC ---
Fixed for 4.5.0.

[Bug testsuite/49341] [4.7 Regression] FAIL: gcc.dg/20051207-3.c and gcc.dg/tls/section-1.c

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-06-09 
16:18:07 UTC ---
For gcc.dg/20051207-3.c the excess error on x86_64-apple-darwin10 is

/opt/gcc/work/gcc/testsuite/gcc.dg/20051207-3.c:6:5: note: 'a' was declared
here

gcc.dg/tls/section-1.c is not supported on x86_64-apple-darwin10.

[Bug c++/45043] [4.4/4.5 Regression] ICE: tree check: expected identifier_node, have bit_not_expr in grokdeclarator, at cp/decl.c:8113 on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||
 Resolution||FIXED
   Target Milestone|4.4.7   |4.6.0
  Known to fail||

--- Comment #7 from Paolo Carlini  2011-06-09 
16:25:59 UTC ---
Fixed.

[Bug c++/43630] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid template specialization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.6.1   |4.6.0

--- Comment #5 from Paolo Carlini  2011-06-09 
16:26:51 UTC ---
Fixed.

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-06-09 
16:32:47 UTC ---
> Are you sure you bisected right?

I should have looked at
http://gcc.gnu.org/ml/gcc-regression/2011-06/msg00092.html where the range is
given by

> With your recent patch, GCC HEAD revision 174833 had problems on:
> native: build (NEW build failure)
> Attached is build output for those targets.
> The previous build was of revision 174812.

Sorry about that.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #5 from Anitha Boyapati  
2011-06-09 16:54:11 UTC ---
(In reply to comment #4)
> Created attachment 24475 [details]
> patch
> 
> Here's an untested patch.  Does this fix the problem for you?  Naturally 
> you'll
> want to revert it once dwarf2 unwind info is supported.

I don't think this is a proper fix. Current GCC trunk already has support for
DWARF2 CFI emission. But as per internals, emitting CFI can be optional. So
unless DWARF2_UNWIND_INFO or INCOMING_RETURN_ADDR_RTX is defined, the function
initial_return_save() should not be invoked.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #6 from Anitha Boyapati  
2011-06-09 17:00:20 UTC ---
(In reply to comment #4)
> Created attachment 24475 [details]
> patch
> 
> Here's an untested patch.  Does this fix the problem for you?

I'll try and let you know.

>  Naturally you'll
> want to revert it once dwarf2 unwind info is supported.

I think my other comment (#5) is somewhat ambiguous and incomplete. I am
referring to TARGET_DEBUG_UNWIND_INFO being defined in avr.c. In previous
versions it is optional but now it seems mandatory to avoid ICE.

[Bug c++/46003] cond5.C fails for ARM EABI tests.

[yufeng at gcc dot gnu.org]

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

Yufeng Zhang  changed:

   What|Removed |Added

 CC|yufeng.zhang at arm dot com |

--- Comment #8 from Yufeng Zhang  2011-06-09 
17:15:14 UTC ---
(In reply to comment #6)
> Shouldn't this be fixed by the commit of  PR c++/49134 ?

(In reply to comment #7)
> Test g++.dg/template/cond5.C starts passing for arm-none-linux-gnueabi with
> r174682, the fix for PR49134 mentioned in comment 6.

Thanks for pointing out the related bug fix. The test case
g++.dg/template/cond5.C indeed starts 'passing' now, as the fix for PR
c++/49134 has essentially loosened the same checking where assertion had blown
up. I'll spend some more time looking into the underlying issue and put more
information here later. If it turns out to be necessary, I'll close this
bugzilla and open a new one for it.

[Bug libgomp/49345] New: Proper casting needed when assigning '-1' to unsigned variables.

[shreyasp at ti dot com]

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

   Summary: Proper casting needed when assigning '-1' to unsigned
variables.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shrey...@ti.com


The TI compiler throws warnings when compiling the following code in ordered.c:

  /* We're no longer the owner.  */
  ws->ordered_owner = -1;

This should be changed to:

  /* We're no longer the owner.  */
  ws->ordered_owner = (unsigned)-1;

since 'ordered_owner' is an unsigned integer.

There are three occurrences of this in ordered.c. 

Thanks,
Shreyas

[Bug ada/49346] New: GNAT fails to compile combination of c23006e and c32107a ACATS tests

[tero.koskinen at iki dot fi]

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

   Summary: GNAT fails to compile combination of c23006e and
c32107a ACATS tests
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tero.koski...@iki.fi


GNAT gives following error when I try to compile ACATS tests c23006e and
c32107a together:
$ gnatmake test2
gcc -c test2.adb
c32107a.adb:316:28: invalid prefix in selected component "P1"
c32107a.adb:316:40: expected private type "PRIV" defined at line 292
c32107a.adb:316:40: found procedure name instead of function
gnatmake: "test2.adb" compilation error
$
$ cat -n test2.adb
 1with c23006e;
 2with c32107a;
 3procedure test2 is
 4begin
 5   null;
 6end;
$

Commenting out either line 1 or line 2 allows compilation to succeed.

Testcase:
#!/bin/sh

wget -c http://www.ada-auth.org/acats-files/3.0/acats_30.tar.Z
tar zxf acats_30.tar.Z

cp support/{repbody.ada,repspec.ada} .
cp ./c3/c32107a.ada ./c2/c23006e.ada .
gnatchop *.ada

cat > test2.adb<

[Bug libgomp/49345] ordered.c: Proper casting needed when assigning '-1' to unsigned variables.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-06-09 
17:47:05 UTC ---
Hmm, -1 is really two tokens - and 1.

[Bug libgomp/49345] ordered.c: Proper casting needed when assigning '-1' to unsigned variables.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2011-06-09 
18:04:44 UTC ---
That code is perfectly valid as is.

[Bug c++/49347] New: G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict

[edwintorok at gmail dot com]

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

   Summary: G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to
__restrict
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: edwinto...@gmail.com
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10


Created attachment 24477
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24477
x.i

G++ 4.6 shows this error, G++ 4.3.3 doesn't:
/usr/include/spawn.h:42:14: error: expected ',' or '...' before 'argv'
/usr/include/spawn.h:50:14: error: expected ',' or '...' before 'argv'

Solaris defines posix_spawn like this:
extern int posix_spawn(
pid_t *_RESTRICT_KYWD pid,
const char *_RESTRICT_KYWD path,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *_RESTRICT_KYWD attrp,
char *const argv[_RESTRICT_KYWD],
char *const envp[_RESTRICT_KYWD]);

With GCC 4.6 I see this in preprocessed file:
# 358
"/usr/local/lib/gcc/i386-pc-solaris2.10/4.6.0/include-fixed/sys/feature_tests.h"
3 4
...
#if (defined(__STDC__) && defined(_STDC_C99))
#ifdef __cplusplus
#define _RESTRICT_KYWD  __restrict
#else
#define _RESTRICT_KYWD  restrict
#endif
#else
#define _RESTRICT_KYWD
#endif

With 4.3.3 I see this:
#if (defined(__STDC__) && defined(_STDC_C99))
#define _RESTRICT_KYWD  restrict
#else
#define _RESTRICT_KYWD
#endif

The system header is:
/usr/include/sys/feature_tests.h:
#if (defined(__STDC__) && defined(_STDC_C99))
#define _RESTRICT_KYWD  restrict
#else
#define _RESTRICT_KYWD
#endif

Don't know where the #define to __restrict on __cplusplus comes from, but it is
wrong.

GCC 4.6 is:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /home/chris/apps/compiler/gcc-4.6.0/configure
--enable-languages=c,c++ --disable-libgcj --with-as=/usr/local/bin/as
--with-gnu-as --with-ld=/usr/local/bin/ld --with-gnu-ld --disable-nls
Thread model: posix
gcc version 4.6.0 (GCC) 

GCC 4.3.3 is:
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4
--exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw
--with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp
--enable-objc-gc --enable-threads=posix --enable-stage1-languages=c
--enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)

To reproduce bug just do this:
$ echo "#include " >x.cpp
$ g++-4.6 x.cpp
In file included from x.cpp:1:0:
/usr/include/spawn.h:42:14: error: expected ',' or '...' before 'argv'
/usr/include/spawn.h:50:14: error: expected ',' or '...' before 'argv'

Preprocessed x.i attached.

Originally reported for ClamAV:
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2921

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Attachment #24475|0   |1
is obsolete||

--- Comment #7 from Jason Merrill  2011-06-09 
18:08:33 UTC ---
Created attachment 24478
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24478
alternate patch

This patch is probably better.

[Bug c++/49347] G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.09 18:24:01
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-06-09 
18:24:01 UTC ---
(In reply to comment #0)
> 
> Don't know where the #define to __restrict on __cplusplus comes from, but it 
> is
> wrong.

No, it's correct, see
http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html


The bug is that G++ can't parse __restrict in an array parameter:

extern int f( char *const envp[__restrict] );

The C front end accepts this, but not the C++ one.

[Bug c++/49347] G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict

[edwintorok at gmail dot com]

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

--- Comment #2 from Török Edwin  2011-06-09 
18:29:22 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > 
> > Don't know where the #define to __restrict on __cplusplus comes from, but 
> > it is
> > wrong.
> 
> No, it's correct, see
> http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
> 
> 
> The bug is that G++ can't parse __restrict in an array parameter:
> 
> extern int f( char *const envp[__restrict] );
> 
> The C front end accepts this, but not the C++ one.

Is that planned to be fixed for the next release?
If not then as a workaround that fix-includes header could #define
_RESTRICY_KYWD to empty.

[Bug c++/49347] G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-06-09 
18:35:15 UTC ---
you only reported the bug a few minutes ago, so no, nothing's planned yet!

reduced:

int f( int envp[__restrict] );

p.cc:1:17: error: expected primary-expression before '__restrict'
p.cc:1:17: error: expected ']' before '__restrict'
p.cc:1:17: error: expected ')' before '__restrict'
p.cc:1:27: error: expected initializer before ']' token

The summary should really be adjusted, although this caused a problem on
Solaris the G++ bug isn't Solaris-specific

[Bug debug/49348] New: DW_TAG_template_* DIEs missing from template specializations

[dodji at gcc dot gnu.org]

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

   Summary: DW_TAG_template_* DIEs missing from template
specializations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: do...@gcc.gnu.org


In the test below from gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C, the DIE
sub-tree of the type foo<1> doesn't have any DW_TAG_template_* DIE:

template 
struct foo
{
public:
typedef
 unsigned char type;
};

template<>
struct foo<1>
{
typedef enum { e0, e1 } type;
};

int
main()
{
foo<1> f;
foo<1>::type t = foo<1>::e1;
return t;
}

[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.09 18:38:21
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  2011-06-09 
18:44:29 UTC ---
Four cpu2000 benchmarks (eon,fma3d,sixtrack,apsi) also fail to build with the
same ICE starting with the following revision.


r174815 | aoliva | 2011-06-08 14:39:12 -0500 (Wed, 08 Jun 2011) | 4 lines

* tree-flow-inline.h (op_iter_init): Reject GIMPLE_PHI stmts.
(num_ssa_operands): Likewise.
(op_iter_init_phiuse): Forward-declare.
(delink_stmt_imm_use): Iterate with FOR_EACH_PHI_OR_STMT_USE.

[Bug target/49349] New: gfortran.dg/char_result_3.f90 fails with -O3

[sje at cup dot hp.com]

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

   Summary: gfortran.dg/char_result_3.f90 fails with -O3
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: t...@codesourcery.com
Target: ia64-hp-hpux11*


Compiling gfortran.dg/char_result_3.f90 on IA64 HP-UX with the -O3 option
results in:

$ obj_gcc/gcc/f951 -O3 -quiet char_result_3.f90
char_result_3.f90: In function 'f4':
char_result_3.f90:71:0: internal compiler error: in bundling, at
config/ia64/ia6
4.c:8845

The failure started with r173853.

2011-05-18  Tom de Vries  

PR target/45098
* tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost

This only happens in 32 bit mode so I can't reproduce it on IA64 Linux.

If I turn off selective scheduling (-fno-selective-scheduling or
-fno-selective-scheduling2) it goes away.  I don't know if the bug is in the
scheduling or in this fix to PR 45098.

[Bug c++/49350] New: [4.7 Regression] Many C++ testsuite failures

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] Many C++ testsuite failures
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 174849 gave

FAIL: g++.dg/abi/covariant2.C (internal compiler error)
FAIL: g++.dg/abi/covariant2.C (test for excess errors)
FAIL: g++.dg/abi/covariant3.C (internal compiler error)
FAIL: g++.dg/abi/covariant3.C (test for excess errors)
FAIL: g++.dg/abi/covariant4.C (internal compiler error)
FAIL: g++.dg/abi/covariant4.C (test for excess errors)
FAIL: g++.dg/abi/covariant5.C (internal compiler error)
FAIL: g++.dg/abi/covariant5.C (test for excess errors)
FAIL: g++.dg/abi/covariant6.C (internal compiler error)
FAIL: g++.dg/abi/covariant6.C (test for excess errors)
FAIL: g++.dg/inherit/covariant1.C (internal compiler error)
FAIL: g++.dg/inherit/covariant1.C (test for excess errors)
FAIL: g++.dg/inherit/covariant10.C (internal compiler error)
FAIL: g++.dg/inherit/covariant10.C (test for excess errors)
FAIL: g++.dg/inherit/covariant11.C (internal compiler error)
FAIL: g++.dg/inherit/covariant11.C (test for excess errors)
FAIL: g++.dg/inherit/covariant17.C (internal compiler error)
FAIL: g++.dg/inherit/covariant17.C (test for excess errors)
FAIL: g++.dg/inherit/covariant18.C (internal compiler error)
FAIL: g++.dg/inherit/covariant18.C (test for excess errors)
FAIL: g++.dg/inherit/covariant2.C (internal compiler error)
FAIL: g++.dg/inherit/covariant2.C (test for excess errors)
FAIL: g++.dg/inherit/covariant3.C (internal compiler error)
FAIL: g++.dg/inherit/covariant3.C (test for excess errors)
FAIL: g++.dg/inherit/covariant4.C (internal compiler error)
FAIL: g++.dg/inherit/covariant4.C (test for excess errors)
FAIL: g++.dg/inherit/covariant5.C (internal compiler error)
FAIL: g++.dg/inherit/covariant5.C (test for excess errors)
FAIL: g++.dg/inherit/covariant6.C (internal compiler error)
FAIL: g++.dg/inherit/covariant6.C (test for excess errors)
FAIL: g++.dg/inherit/covariant8.C (internal compiler error)
FAIL: g++.dg/inherit/covariant8.C (test for excess errors)
FAIL: g++.dg/inherit/covariant9.C (internal compiler error)
FAIL: g++.dg/inherit/covariant9.C (test for excess errors)
FAIL: g++.dg/inherit/thunk9.C (internal compiler error)
FAIL: g++.dg/inherit/thunk9.C (test for excess errors)
FAIL: g++.dg/opt/covariant1.C (internal compiler error)
FAIL: g++.dg/opt/covariant1.C (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O0  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O0  (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O1  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O1  (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O2  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O2  (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O2 -flto  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O2 -flto  (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O2 -flto -flto-partition=none  (test for
excess errors)
FAIL: g++.dg/torture/covariant-1.C  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: g++.dg/torture/covariant-1.C  -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/covariant-1.C  -Os  (internal compiler error)
FAIL: g++.dg/torture/covariant-1.C  -Os  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -O0  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -O0  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -O1  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -O1  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -O2  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -O2  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -O2 -flto  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -O2 -flto  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/torture/pr43068.C  -O2 -flto -flto-partition=none  (test for
excess errors)
FAIL: g++.dg/torture/pr43068.C  -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: g++.dg/torture/pr43068.C  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: g++.dg/torture/pr43068.C  -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr43068.C  -Os  (internal compiler error)
FAIL: g++.dg/torture/pr43068.C  -Os  (test for excess errors)
FAIL: g++.dg/torture/pr47714.C  -O0  (internal compiler error)
FAIL: g++.dg/torture/pr47714.C  -O0  (

[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.09 21:44:30
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Martin Jambor  2011-06-09 
21:44:30 UTC ---
OK, I can reproduce this and am looking into it.

[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli  2011-06-09 
21:46:17 UTC ---
Created attachment 24479
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24479
Candidate patch

For a given template instantiation, the dwarf backends emits debug
info that describes its template parameters and arguments if
generic_type_p returns TRUE on the the instantiation.  For that,
primary_template_instantiation_p must be also return TRUE.

The problem in this PR is that primary_template_instantiation_p
doesn't return TRUE for explicit specializations.  This patch makes it
return true for explicit specializations and instantiations of a
primary template.

Stricto sensu I think I should rename the function
primary_template_instantiation_p into
primary_template_specialization_p, as [temp.spec]/4 reads

A specialization is a class, function, or class member that is
either instantiated or explicitly specialized

[Bug debug/41736] missing DW_TAG_template_*_ in some cases

[dodji at gcc dot gnu.org]

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

--- Comment #7 from Dodji Seketeli  2011-06-09 
21:50:01 UTC ---
Another instance of bug that resembles this one is PR debug/49348

[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations

[dodji at gcc dot gnu.org]

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

--- Comment #2 from Dodji Seketeli  2011-06-09 
21:50:21 UTC ---
This bug resembles PR debug/41736

[Bug debug/41736] missing DW_TAG_template_*_ in some cases

[dodji at gcc dot gnu.org]

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

--- Comment #8 from Dodji Seketeli  2011-06-09 
21:53:22 UTC ---
Note that I am going to re-submit the fix to this bug now that I am about to
remove template arguments from DW_AT_name for template specializations (PR
debug/49312)

[Bug c++/49350] [4.7 Regression] Many C++ testsuite failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||davidxl at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-06-09 22:01:09 
UTC ---
It is caused by revision 174848:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00337.html

[Bug c++/48660] ARM ICE in expand_expr_real_1

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson  2011-06-09 
22:03:23 UTC ---
It's caused or triggered by r154736:

Author: hubicka
Date: Sun Nov 29 10:32:08 2009
New Revision: 154736

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

* cgraph.c (same_body_alias_1): Break out of
(same_body_alias): ... here; remove comdat check; it is handled
in cp already.
(cgraph_add_thunk): New.
(dump_cgraph_node): Dump aliases and thunks.
* cgraph.h (cgraph_thunk_info): New structure.
(struct cgraph_node): Add thunk info.
(cgraph_add_thunk): New.
...

One strange thing about that commit is that it added calls to record_loop_exits
in ira.c, but the ChangeLog entry doesn't mention ira.c, and nothing else in
the commit seems related to loops or ira.  A local hack that got accidentally
committed?

[Bug target/49307] [4.5/4.6/4.7 Regression] ICE in spill_failure, at reload1.c:2113

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  2011-06-09 
22:19:23 UTC ---
Author: kkojima
Date: Thu Jun  9 22:19:20 2011
New Revision: 174861

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174861
Log:
PR target/49307
* config/sh/sh.md (UNSPEC_CHKADD): New.
(chk_guard_add): New define_insn_and_split.
(symGOT_load): Use chk_guard_add instead of blockage.
* gcc.dg/pr49307.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/pr49307.c
Modified:
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog