[Bug target/44202] Missing compare after add

[hp at gcc dot gnu dot org]

--- Comment #10 from hp at gcc dot gnu dot org  2010-05-20 07:02 ---
Fixed, see also .


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[irar at il dot ibm dot com]

--- Comment #1 from irar at il dot ibm dot com  2010-05-20 07:13 ---
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but the
problem is in extract_even?

Other than doing something in the backend, we can reduce the number of vector
iterations in cases that may access elements outside array bounds for specific
targets...


-- 


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

[Bug fortran/43851] Add _gfortran_error_stop_numeric

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-05-20 07:40 ---
TODO: Constraint checks are missing and partially incorrect,
cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00225.html


-- 


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

[Bug fortran/44207] New: ICE on ALLOCATE statement

[boschmann at tp1 dot physik dot uni-siegen dot de]

program ice_prog

type::ice_type
  integer,dimension(:),allocatable::list
end type ice_type

type(ice_type)::this
integer::dim,i
allocate(this%list(dim),source=[(i,i=1,dim)])

end program ice_prog


Compiling this with GNU Fortran (GCC) 4.6.0 20100518 (experimental) will cause
a segmentation violation at compile time.

Thanks to Janus for helping me.


-- 
   Summary: ICE on ALLOCATE statement
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug middle-end/44203] [4.6 regression] New prefetch test failures

[borntraeger at de dot ibm dot com]

--- Comment #1 from borntraeger at de dot ibm dot com  2010-05-20 08:29 
---

Indeed. I think I found a typo when handling array prefetches.
a potential fix might be:

--- gcc/tree-ssa-loop-prefetch.c(Revision 159557)
+++ gcc/tree-ssa-loop-prefetch.c(Arbeitskopie)
@@ -440,7 +440,7 @@

   *ar_data->step = fold_build2 (MULT_EXPR, sizetype,
fold_convert (sizetype, *ar_data->step),
-   fold_convert (sizetype, step));
+   fold_convert (sizetype, stepsize));
   idelta *= imult;
 }



-- 


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-05-20 08:50 ---
(In reply to comment #1)
> Do you mean that extract_even implementation does something illegal with this
> last element? Misaligned load also accesses elements outside the array, but 
> the
> problem is in extract_even?

Vectorizer generates

vect_var_.12_25 = M*vect_pb.7_23{misalignment: 32};
vect_var_.13_27 = M*vect_pb.7_26{misalignment: 32};

Those may read beyond the end of array. Vectorizer
should check that vect_pb.7_23/vect_pb.7_26 + vector
size < end of array.


-- 


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

[Bug fortran/44207] ICE on ALLOCATE statement

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-05-20 08:52 ---
Confirmed. Note that as such the code is invalid (dim is not set), but adding a
line "dim=10" does not remove the ICE. The backtrace is:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x00010007dd6c in resolve_allocate_deallocate (code=0x141816470, fcn=) at
../../work/gcc/fortran/resolve.c:6097
6097  if (e2->ref && e1->rank != e2->ref->u.ar.as->rank)
(gdb) bt
#0  0x00010007dd6c in resolve_allocate_deallocate (code=0x141816470,
fcn=) at
../../work/gcc/fortran/resolve.c:6097
#1  0x000100084867 in resolve_code (code=, ns=0x142078200) at ../../work/gcc/fortran/resolve.c:8450
#2  0x000100085f46 in resolve_codes (ns=0x142078200) at
../../work/gcc/fortran/resolve.c:12777
#3  0x00010007864e in gfc_resolve (ns=0x142078200) at
../../work/gcc/fortran/resolve.c:12804
#4  0x00010006c6e3 in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4292
#5  0x0001000a58dc in gfc_be_parse_file (set_yydebug=) at ../../work/gcc/fortran/f95-lang.c:239
#6  0x0001006dc0c1 in toplev_main (argc=2, argv=0x7fff5fbfd9d0) at
../../work/gcc/toplev.c:1047
#7  0x000110e4 in start ()

Replacing

allocate(this%list(dim0),source=[(i,i=1,dim0)])

with

dim = 10
allocate(this%list(dim))
this%list = [(i,i=1,dim)]

works.


-- 


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

[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2010-05-20 09:36 ---
Confirmed. The problem occurs with allocatable components only, allocatable
variables are fine.

#0  0x0813d1cd in conformable_arrays (e1=0x8bff710, e2=0x8bc9a30) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6077
#1  0x0813d7df in resolve_allocate_expr (e=0x8bc9a30, code=0x8bff778) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6257
#2  0x0813e1c7 in resolve_allocate_deallocate (code=0x8bff778, fcn=0x8964f31
"ALLOCATE") at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6510
#3  0x08141647 in resolve_code (code=0x8bff778, ns=0x8bfdeb8) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:8430
#4  0x0814ad70 in resolve_codes (ns=0x8bfdeb8) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:12757
[...]

Note: resolve.c (conformable_arrays) and resolve.c (compare_shapes) seem to do
the same. Could they be merged?


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 09:36:07
   date||
Summary|ICE on ALLOCATE statement   |ICE with ALLOCATABLE
   ||components and SOURCE


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

[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-05-20 09:57 
---
On it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2010-05-20 10:04 ---
I am curious what is the problem with that? These elements are not used, they
are just loaded... 


-- 


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-05-20 10:18 ---
(In reply to comment #3)
> I am curious what is the problem with that? These elements are not used, they
> are just loaded... 

An out-of-bounds read can result in a SEGV if the memory is unmapped. Worse
things can happen if the memory is "special" (think kernels and MMIO).


-- 


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

[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[redi at gcc dot gnu dot org]

--- Comment #26 from redi at gcc dot gnu dot org  2010-05-20 10:18 ---
I tweaked the patch to apply it to 4.4.3 (replacing ASM_BYTE with .byte) and it
fixes the bootstrap failure for this config:

--enable-languages=c,c++,fortran --with-arch=core2 --with-as=/usr/sfw/bin/gas
--with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld


-- 


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[irar at il dot ibm dot com]

--- Comment #5 from irar at il dot ibm dot com  2010-05-20 10:24 ---
Even if we are talking about less than vector size from array boundary? And
that boundary is not (vector) aligned.


-- 


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-05-20 10:29 ---
Subject: Bug 44074

Author: jakub
Date: Thu May 20 10:28:36 2010
New Revision: 159622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159622
Log:
PR target/44074
* configure: Regenerate.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/configure


-- 


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-05-20 10:30 ---
Patching in configure pieces generated with autoconf 2.64 into autoconf 2.59
generated configure totally broke the branch, configure after a few errors kept
printing y in an endless loop.


-- 


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

[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-05-20 
10:32 ---
Subject: Re:  Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on
same line

> --- Comment #13 from jakub at gcc dot gnu dot org  2010-05-20 10:30 
> ---
> Patching in configure pieces generated with autoconf 2.64 into autoconf 2.59
> generated configure totally broke the branch, configure after a few errors 
> kept
> printing y in an endless loop.

Sorry about the mess, will be more careful next time.

Rainer


-- 


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

[Bug tree-optimization/44183] Vectorizer may generate invalid memory access

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2010-05-20 11:05 ---
It depends on the specific values of (a) array end alignment and (b) the number
of bytes read. As long as the array end + number of bytes read can cross a page
boundary, you're potentially causing SEGV or other errors.


-- 


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

[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2010-05-20 11:06 ---
A patch has been proposed to
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01476.html


-- 


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

[Bug driver/44209] New: Some warnings are not linked to diagnostics options

[eric dot estievenart at free dot fr]

Sorry, I report this bug with a Major severity, because it applies to all
front-ends and backends.

Consider the following code:

static void f() __attribute__((warning("should not be linked")));
void f() {}
int main() { f(); }
---
You just can't compile it without removing -Werror,
because there is no diagnostic option associated:
==
$ gcc -Werror -fdiagnostics-show-option -c test.c
..
test.c:3: error: call to ‘f’ declared with attribute warning: should not be
linked

== Context ==
I think that serious developpers compile their code with options like
-Wall -Werror
and on some files or builds disable either a warning:
-Wno-unused-parameter
or let the warning be shown but don't make it an error:
-Wno-error=unused-parameter  (e.g. in debug builds)

The conditions depend on the files, type of build, organization preferences,
etc;
combining -Wall.. and -Werror is for me a prerequisite for high-quality code,
so removing -Werror is barely unacceptable; it'll go in the makefiles, be
dumped
into the source-control, and time will be lost looking for a bug which would
have been detected and blocked by the compiler instead of on the field.

I would just recommend that within gcc, it would be impossible to emit a
warning
without having it associated to a diagnostic.

I'm not providing a patch yet, but if you think that the idea is valuable, I'll
consider digging into the code. The amount of work fixing all backends is
probably huge,
so it should be incremental.

Sincerely


-- 
   Summary: Some warnings are not linked to diagnostics options
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot estievenart at free dot fr
 GCC build triplet: ALL
  GCC host triplet: ALL
GCC target triplet: ALL


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

[Bug driver/44209] Some warnings are not linked to diagnostics options

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-05-20 11:40 ---
IMHO this is an enhancement request, not severity=Major

-Werror is not on by default, if you choose to enable it then you deal with the
consequences.

Obviously the ideal is for every warning to be controllable by an option, but
until that happens gcc behaves as documented and if -Werror is not suitable for
your program then don't use it.


-- 


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

[Bug driver/44209] Some warnings are not linked to diagnostics options

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-05-20 11:45 ---
N.B. Bug 44054 is the PR for the fortran FE to support -Werror= etc.


-- 


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

[Bug driver/44210] New: Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

As I always wonder if my compiler could help me find more bugs,
and the list of warnings I enable tend to be very long,
and -Wall is not enough for me...

(This bug certainly depends on #44209: "Some warnings are not linked to
diagnostics options")

It would be great to have the following options:
(I really don't care for their names if you have better suggestions;
I focus on the functionality)

-Wevery:  would enable all warnings known to gcc 

This would allow reducing this (infamous) list:
-W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
-Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
-Wsequence-point -Woverloaded-virtual
(I never know which one is enabled by -W, -Wall, -Wextra...)
to a single -Wevery with a few -Wno-XX

-show-warnings:  would show the enabled warnings 

An example usage would be:
$ gcc -c somefile.c -Wall -Werror -Wno-error=reorder -Wno-unused-function
. -show-warnings
status  name from

ERROR   address  -Wall -Werror
warnreorder  -Wall -Werror -Wno-error=reorder
-   unused-function  -Wno-unused-function
-   clobbered(would be enabled by -Wextra)
...

372 known warnings, 300 shown, 297 as errors  (muted: 72)

If the team is interested, I'll consider providing a patch.


-- 
   Summary: Extended warning control: like -Wevery -show-warnings
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot estievenart at free dot fr
 GCC build triplet: does not apply
  GCC host triplet: does not apply
GCC target triplet: does not apply


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenther at suse dot de]

--- Comment #16 from rguenther at suse dot de  2010-05-20 11:48 ---
Subject: Re:  [4.5 Regression] Aliasing bug triggered by
 Boost.Bind/Boost.Function

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> --- Comment #15 from jason at gcc dot gnu dot org  2010-05-20 05:35 
> ---
> Giving all unions alias set 0 doesn't fix the testcase.  This surprises me,
> since I thought that the problem was with the union assignment
> 
>   this->functor = f.functor;
> 
> in assign_to_own.  Giving alias set 0 to all classes with a member or base of
> alias set 0 also doesn't fix the testcase.  Giving alias set 0 to all classes
> does fix the testcase.

Ok, I'll try to pin-point the exact problem.


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at gcc dot gnu dot org]

--- Comment #10 from ro at gcc dot gnu dot org  2010-05-20 12:06 ---
Subject: Bug 43870

Author: ro
Date: Thu May 20 12:05:54 2010
New Revision: 159625

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159625
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare): Stabilize sort.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at gcc dot gnu dot org]

--- Comment #11 from ro at gcc dot gnu dot org  2010-05-20 12:07 ---
Subject: Bug 43870

Author: ro
Date: Thu May 20 12:07:23 2010
New Revision: 159626

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159626
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare): Stabilize sort.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/df-scan.c


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at gcc dot gnu dot org]

--- Comment #12 from ro at gcc dot gnu dot org  2010-05-20 12:08 ---
Subject: Bug 43870

Author: ro
Date: Thu May 20 12:08:34 2010
New Revision: 159627

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159627
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare): Stabilize sort.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/df-scan.c


-- 


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

[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c

[ro at gcc dot gnu dot org]

--- Comment #13 from ro at gcc dot gnu dot org  2010-05-20 12:10 ---
Fixed for 4.4.5, 4.5.1, 4.6.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.4.5 4.5.1 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[segher at gcc dot gnu dot org]

--- Comment #6 from segher at gcc dot gnu dot org  2010-05-20 12:10 ---
I don't see the problem with 4.3 .

Kyle, are you sure it doesn't happen for you with 4.4?

I use

powerpc-linux-gnuspe-gcc -Wall -W -O1 -pthread -ftls-model=initial-exec
-mcpu=8540 -fPIC -S t.c -fverbose-asm

paste your output of that?


-- 

segher at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.5


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[joakim dot tjernlund at transmode dot se]

--- Comment #7 from joakim dot tjernlund at transmode dot se  2010-05-20 
12:13 ---
The below code doesn't generate any "add with carry" insn's for
either x86 nor powerpc:

u16
ipsum(u16 *buf, unsigned len, u16 sum)
{
  int rest, carry ;
  u32 acc_sum, *buf_u32, x;

  acc_sum = sum;
  len >>= 2;
  buf_u32 =  (u32 *) buf;
  carry = 0;
  for(buf_u32--; len; --len) {
  x = *++buf_u32;
  acc_sum += x;
  acc_sum += carry;
  carry = x > acc_sum ? 1 : 0;
  }
  acc_sum += carry;
  /* Add back carry outs from top 16 bits to low 16 bits.
   */
  acc_sum = (acc_sum >> 16) + (acc_sum & 0x);/* add high-16 to low-16
*/
  acc_sum += (acc_sum >> 16); /* add carry */
  return acc_sum;
}


-- 

joakim dot tjernlund at transmode dot se changed:

   What|Removed |Added

   Severity|enhancement |normal
  Component|rtl-optimization|regression


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #7 from Kyle dot D dot Moffett at boeing dot com  2010-05-20 
12:17 ---
Created an attachment (id=20707)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20707&action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.3.4


-- 


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

[Bug middle-end/44204] [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug fortran/44211] New: ICE with TBP of pointer component of derived type array

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice_module
  type::ice_type
 class(ice_type),pointer::next
   contains
 procedure::ice_proc
  end type ice_type
contains
  subroutine ice_proc(this)
class(ice_type)::this
  end subroutine ice_proc
  subroutine ice_sub()
type(ice_type),dimension(2)::ice_array
class(ice_type),pointer::ice_p
ice_p=>ice_array(2)%next ! works
call ice_array(2)%ice_proc() ! works
call ice_array(2)%next%ice_proc()! ICE
  end subroutine ice_sub
end module ice_module

Compiling this with GNU Fortran (GCC) 4.6.0 20100518 (experimental) will cause
a segmentation violation at compile time.

The two lines with "! works" and ice_p are not relevant, they only show that
the combination of the array, the pointer component and the type bound
procedure is really necessary for the compiler error.


-- 
   Summary: ICE with TBP of pointer component of derived type array
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #8 from Kyle dot D dot Moffett at boeing dot com  2010-05-20 
12:19 ---
Created an attachment (id=20708)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20708&action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.4


-- 


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

[Bug middle-end/44203] [4.6 regression] New prefetch test failures

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug middle-end/44203] [4.6 regression] New prefetch test failures

[borntraeger at de dot ibm dot com]

--- Comment #2 from borntraeger at de dot ibm dot com  2010-05-20 12:28 
---
Created an attachment (id=20709)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20709&action=view)
new version of the fix. 

There is actually a second bug :-(
We not only have to replace step with stepsize (a=a+b*b vs. a=a+b*c)
we also have to fix the fact that we changed a=a+b*c to a=(a+b)*c


-- 


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #9 from Kyle dot D dot Moffett at boeing dot com  2010-05-20 
12:29 ---
Created an attachment (id=20710)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20710&action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.2


-- 


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

[Bug rtl-optimization/44169] Wrong code while generating TLS offsets

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #10 from Kyle dot D dot Moffett at boeing dot com  2010-05-20 
12:37 ---
Ok, it looks like the bug was introduced in the 4.4 branch between 4.4.2 and
4.4.4, because my old GCC 4.4.2 compiler works, but the 4.4.4 I built yesterday
after I noticed this report does not.

If needed I can spend some time to track down exactly which optimization
flag(s) cause the problem, but hopefully we've narrowed down the versions
closely enough for it to be easy to find. :-D

Cheers,
Kyle Moffett


-- 


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2010-05-20 13:24 
---
It is actually the scheduler that breaks the testcase.  Easier to look at
is -O2 -fwhole-program.  -fno-schedule-insns2 fixes it (as well as
-fno-tree-pre
or -fno-tree-dominator-opts, both of which are necessary to produce the
input to the scheduler).


-- 


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

[Bug debug/44205] Wrong .debug_line for -O0 -g

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-20 13:27 ---
So, we have:
:
  [pr44205.c : 7:11] i.1_2 = i;
  [pr44205.c : 7:10] if (i.1_2 != 0)
goto ;
  else
goto ;

:
  [pr44205.c : 8:4] i = 0;
  goto ;

:
  [pr44205.c : 10:4] i = 1;

:
  goto ;

:
  [pr44205.c : 13:7] i = 2;

:
  [pr44205.c : 14:1] return;

in *.optimized dump which roughly corresponds to the first goto after i = 0
being on line 6 and then another goto on line 8.  Then during cfgcleanup mode
the jump is forwarded and just one of the locations is kept.

Now, either we'd need for -O0 to prevent jump forwarding when the locus is
different (or add a nop with one locus followed by jump with the second locus),
which would lead to gdb seeing movl $0, i; nop; on line 8 and jmp ... on line
10 (or movl $0, i; jmp 1f; on line 8 and movl $1, i; 1: jmp 3f; on line 10.
Or we need to do something already during gimplification and for nested if/else
if if(){}else{} isn't followed by any other statement and is inside of then
block of another if, ensure the branch goes stright to the last label instead
of hopping through some pad in the middle.  Only that would ensure movl $0, i;
jmp 3f; is on line 8 and that line 14 is immediately next insn after that.


-- 


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

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-05-20 13:31 ---
(In reply to comment #0)
> This would allow reducing this (infamous) list:
> -W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
> -Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
> -Wsequence-point -Woverloaded-virtual
> (I never know which one is enabled by -W, -Wall, -Wextra...)

-W is a synonym for -Wextra, so it is pointless to use both (older versions
won't accept -Wextra, new versions don't need both)

The manual fairly clearly documents what controls what:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html



> 
> -show-warnings:  would show the enabled warnings 
> 
> An example usage would be:
> $ gcc -c somefile.c -Wall -Werror -Wno-error=reorder -Wno-unused-function
> . -show-warnings
> status  name from
> 
> ERROR   address  -Wall -Werror
> warnreorder  -Wall -Werror -Wno-error=reorder
> -   unused-function  -Wno-unused-function
> -   clobbered(would be enabled by -Wextra)
> ...
> 
> 372 known warnings, 300 shown, 297 as errors  (muted: 72)
> 
> If the team is interested, I'll consider providing a patch.
> 


-- 


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

[Bug fortran/43851] Add _gfortran_error_stop_numeric

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-05-20 13:33 
---
Also have one tweak to do for blank STOP which I will fix shortly and add some
test cases.


-- 


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

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2010-05-20 13:51 ---
(In reply to comment #10)
Am I right in thinking that -fwhole-file could be enabled by default, if this
PR were to be fixed?  (The appropriate changes in the testsuite would have to
be mad too.)

Paul


-- 


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

[Bug fortran/44212] New: [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice_module

  type :: B_type
 class(A_type),pointer :: A_comp   ! A_type is not yet defined
  end type B_type

  type :: A_type
  contains
 procedure :: A_proc
  end type A_type

contains

  subroutine A_proc(this)
class(A_type),target,intent(inout) :: this
  end subroutine A_proc

  subroutine ice_proc(this)
class(A_type) :: this
call this%A_proc()
  end subroutine ice_proc

end module ice_module

f951: interner Compiler-Fehler: in gfc_add_component_ref, bei
fortran/class.c:77

Sorry, the error is in german, but you will understand it :)


-- 
   Summary: [OOP] ICE when defining a pointer component before
defining the class and calling a TBP then
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

--- Comment #18 from jason at gcc dot gnu dot org  2010-05-20 14:00 ---
Unassigning myself.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

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

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 14:01 ---
And changing component to rtl-opt.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |rtl-optimization


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[dje at gcc dot gnu dot org]

--- Comment #8 from dje at gcc dot gnu dot org  2010-05-20 14:25 ---
Has anyone tested if generating an instruction sequence that uses the carry bit
actually improves performance on modern POWER processors?  It reduces the
number of instructions, which is good when optimizing for size, but that may
not necessarily translate to performance.


-- 


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

[Bug fortran/35849] "wrong" line shown in error message for parameter

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-20 14:33 ---
A similar example:

$ cat conversion.f90
   REAL(8), PARAMETER :: h = HUGE(0.0_8)

   real*4 x
   data x / h /
end

$ gfortran-svn -Wall conversion.f90
conversion.f90:1.28:

   REAL(8), PARAMETER :: h = HUGE(0.0_8)
1
Error: Arithmetic overflow converting REAL(8) to REAL(4) at (1). This check can
be disabled with the option -fno-range-check


The overflowing conversion occurs in the DATA statement ^^


-- 


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

[Bug fortran/44213] New: [OOP] ICE when extending abstract type

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice_module
  type :: a_type
  end type a_type

  type,extends(a_type),abstract :: b_type
  end type b_type

  type,extends(b_type) :: c_type
  end type c_type
end module ice_module

f951: interner Compiler-Fehler: in ensure_not_abstract, bei
fortran/resolve.c:10559


-- 
   Summary: [OOP] ICE when extending abstract type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug debug/44205] Wrong .debug_line for -O0 -g

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-20 14:44 ---
Created an attachment (id=20711)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20711&action=view)
gcc46-pr44205.patch

Doing it at gimplification time would be actually very hard, we only create the
continue label after then block is gimplified and only if it could fall
through.

Here is an attempt to fix this by removing forwarder blocks even at -O0 during
tree cfg cleanup if they don't care any useful location info (either everything
is UNKNOWN_LOCATION as in this testcase, or everything has the same location).
The goto to the cont label intentionally has no location:
  g = gimple_build_goto (label_cont);

  /* GIMPLE_COND's are very low level; they have embedded
 gotos.  This particular embedded goto should not be marked
 with the location of the original COND_EXPR, as it would
 correspond to the COND_EXPR's condition, not the ELSE or the
 THEN arms.  To avoid marking it with the wrong location, flag
 it as "no location".  */
  gimple_set_do_not_emit_location (g);
and nothing else on the edges here has any locus either, so I believe nothing
is lost by removing the forwarder block.  We then avoid removing the forwarder
block at RTL cleanup time when the extra jump already has some, in this case
undesirable, location.

This patch definitely needs testing on gdb testsuite if it doesn't regress
anything at -O0 -g.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[joakim dot tjernlund at transmode dot se]

--- Comment #9 from joakim dot tjernlund at transmode dot se  2010-05-20 
14:47 ---
(In reply to comment #8)
> Has anyone tested if generating an instruction sequence that uses the carry 
> bit
> actually improves performance on modern POWER processors?  It reduces the
> number of instructions, which is good when optimizing for size, but that may
> not necessarily translate to performance.
> 

On my mpc8321 it is a big difference(don't have numbers handy). Why would
such a simply insn be a problem performance wise?
I know the kernel still uses the carry insn's for calculating the
Internet checksum.

I have also noticed that gcc 4.3.4 prefers to do post increment even
if I write *++buf, why is that?


-- 


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

[Bug middle-end/44197] [4.6 Regresssion] varpool SEGV

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2010-05-20 14:57 ---
Subject: Bug 44197

Author: hubicka
Date: Thu May 20 14:57:27 2010
New Revision: 159629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159629
Log:
PR middle-end/44197
* varpool.c (varpool_remove_node): Handle in-varpool aliases.
* gcc.c-torture/compile/pr44197.c: New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr44197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c


-- 


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

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

--- Comment #2 from eric dot estievenart at free dot fr  2010-05-20 15:06 
---
> -W is a synonym for -Wextra, so it is pointless to use both
This perfectly illustrates the problem; I have already spend hours digging
into the manual, what I attempted was to have as much warnings as possible.

> The manual fairly clearly documents what controls what
I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
wouldn't want to rely on the manual to have a clear overview of what happens
exactly on your build, with a specific file, with your options !

Cheers


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2010-05-20 15:13 ---
Hmm...I tried reverting the change to functional::swap, but all the libstdc++
tests still pass on x86_64-linux, and I haven't been able to write a failing
testcase either.  Anyone else have a testcase that still fails with 4.5.1pre or
trunk?  For instance, this doesn't break when compiled either as C or C++:

union __attribute ((aligned (__alignof (float U { char c[32]; };

int main ()
{
  union U u1, u2;
  *(float*)(u1.c) = 42.0;
  u2 = u1;
  if (*(float*)(&u2) != 42.0)
return 1;
  return 0;
}


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[rguenther at suse dot de]

--- Comment #18 from rguenther at suse dot de  2010-05-20 15:17 ---
Subject: Re:  Revisit std::function for aliasing issues
 and efficiency

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> --- Comment #17 from jason at gcc dot gnu dot org  2010-05-20 15:13 
> ---
> Hmm...I tried reverting the change to functional::swap, but all the libstdc++
> tests still pass on x86_64-linux, and I haven't been able to write a failing
> testcase either.  Anyone else have a testcase that still fails with 4.5.1pre 
> or
> trunk?  For instance, this doesn't break when compiled either as C or C++:
> 
> union __attribute ((aligned (__alignof (float U { char c[32]; };

That's because the union now effectively uses alias-set zero after

2010-04-15  Richard Guenther  

* alias.c (alias_set_subset_of): Handle alias-set zero
child properly.

which is also a pessimization (because we use alias-set zero for
structs with chars, not only char lvalues).

A testcase that breaks would use a union without a character member
(where you'd still need to copy the object representation).

So like

union { int i; } u,v;

float *f = new (&u) float(0.0;
v = u;
return (float *)&v;

Richard.


-- 


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

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-05-20 15:30 ---
Subject: Bug 44185

Author: spop
Date: Thu May 20 15:29:40 2010
New Revision: 159630

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159630
Log:
Fix PR44185: new prefetch test failures.

2010-05-20  Changpeng Fang  

PR middle-end/44185
* gcc.dg/tree-ssa/prefetch-6.c: Add --param
min-insn-to-prefetch-ratio=6.
* gcc.dg/tree-ssa/prefetch-7.c: Remove --param max-unrolled-insns=1 to
allow unrolling, and adjust the movnti count.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-7.c


-- 


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

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-05-20 15:30 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 15:40 ---
Aha.  That sounds good to me; I don't expect your testcase to work, because it
doesn't involve a char buffer.  The copy does need to use the object
representation, but I think the new-expression should be undefined (though the
standard needs fixing to make it so--this is core issue 1027).

So, can we revert the function::swap change for 4.6, then?


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[rguenther at suse dot de]

--- Comment #20 from rguenther at suse dot de  2010-05-20 15:44 ---
Subject: Re:  Revisit std::function for aliasing issues
 and efficiency

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> --- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 15:40 
> ---
> Aha.  That sounds good to me; I don't expect your testcase to work, because it
> doesn't involve a char buffer.  The copy does need to use the object
> representation, but I think the new-expression should be undefined (though the
> standard needs fixing to make it so--this is core issue 1027).
> 
> So, can we revert the function::swap change for 4.6, then?

Well.  It is probably safe (though I'd like to know how 44164 is
exactly broken - backporting that change doesn't fix that testcase).

Richard.


-- 


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

[Bug debug/44205] Wrong .debug_line for -O0 -g

[jan dot kratochvil at redhat dot com]

--- Comment #3 from jan dot kratochvil at redhat dot com  2010-05-20 16:03 
---
No regressions for FSF GDB HEAD x86_64-linux-gnu with FSF GCC HEAD.


-- 


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

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-05-20 16:14 ---
(In reply to comment #2)
> > -W is a synonym for -Wextra, so it is pointless to use both
> This perfectly illustrates the problem; I have already spend hours digging

Then I have misunderstood the problem. How does this illustrate it?

> into the manual, what I attempted was to have as much warnings as possible.

How does adding the redundant -W help get more warnings if you already have
-Wextra?

> > The manual fairly clearly documents what controls what
> I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
> wouldn't want to rely on the manual to have a clear overview of what happens
> exactly on your build, with a specific file, with your options !

I don't understand what you mean here.
You said you never know what is enabled by -Wall or -Wextra, I pointed out the
manual explains it.
It is quite rare for a -W option to be moved in or out of the -Wall set, so it
doesn't vary between versions.


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[pthaugen at gcc dot gnu dot org]

--- Comment #9 from pthaugen at gcc dot gnu dot org  2010-05-20 16:23 
---
Spec testing went fine, differences in the noise range.


-- 


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

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-20 16:25 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-28 17:12:36 |2010-05-20 16:25:56
   date||


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-05-20 16:31 ---
Have you also bootstrapped/regtested the patch?  I can do so (easily for 4.4
branch, with more effort for the trunk), but haven't done that yet.


-- 


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-20 16:35 ---
Subject: Bug 44178

Author: jakub
Date: Thu May 20 16:34:43 2010
New Revision: 159632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159632
Log:
PR debug/44178
* haifa-sched.c (initiate_bb_reg_pressure_info): Do not call
setup_ref_regs for DEBUG_INSNs.

* g++.dg/debug/pr44178.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr44178.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #21 from jason at gcc dot gnu dot org  2010-05-20 16:49 ---
The alias_set_subset_of change isn't in 4.5?  Then that's not what's making the
libstdc++ function tests pass with the swap change reverted...:)


-- 


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-20 16:59 ---
Subject: Bug 44178

Author: jakub
Date: Thu May 20 16:58:52 2010
New Revision: 159634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159634
Log:
PR debug/44178
* haifa-sched.c (initiate_bb_reg_pressure_info): Do not call
setup_ref_regs for DEBUG_INSNs.

* g++.dg/debug/pr44178.C: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/pr44178.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/haifa-sched.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-20 17:00 ---
Subject: Bug 43521

Author: jakub
Date: Thu May 20 17:00:32 2010
New Revision: 159635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159635
Log:
PR debug/43521
* decl.c (start_java_method): Set DECL_ARTIFICIAL on the 'this'
PARM_DECL.

Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/decl.c


-- 


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-20 17:01 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-20 17:01 ---
A proper come-on-and-pick-up testcase would be nice ...


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-05-20 17:04 ---
The manual documents what is enabled by -Wall and -Wextra and all other groups
options. We will accept patches fixing any missing/mistaken entries. You could
also propose some warnings to be moved to Wextra. Getting into Wall is more
difficult because they have to be pretty clear and serious warnings without few
false positives.

See also the option -fdiagnostics-show-option.

It would be extremely useful to go through the manual and:

* Document which warnings are exactly enabled by -pedantic -Wall and -Wextra.
Wall and Wextra should be ok but could be good to double check them.

* Document which warnings are not enabled by default or by one of the above.
Provide a complete list of those warnings.

* With this list at hand, one could suggest to move some warnings to Wextra
or...

* perhaps provide a "Wparanoid" setting that includes all those warnings.
Although some may be too specific to make sense at all except for very specific
situations. That is why the list might be interesting.

* A list of warnings enabled by default would also be interesting. (They are
mentioned in the manual for each warning, but there is no complete list.)

Instead of -show-warnings, I would propose to extend the current
--help=warnings --verbose. However, that would mean documenting within GCC the
relations between the warnings options. That by itself (even without the
output) would be EXTREMELY useful if done properly, that is, by adding the
information to the *.opt files that define the flags. I can provide pointers on
how this could be implemented. A follow-up patch could even fill the details of
the manual from that information automatically!

So, I think yes, we are interested in any of the above, so if you are
interested in providing patches, choose something small to start with (some
small documentation patch to the manual), and ask whatever you want. You may
ask here or write to me directly.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 17:04:01
   date||


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

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-20 17:06 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-05-20 17:15 ---
Initial patch posted for COMDAT group with Sun as.  Will require an updated
configure test to work on SPARC, though.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/43544] TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION can misoptimize when MD builtins overlap with standard builtins

[meissner at gcc dot gnu dot org]

--- Comment #4 from meissner at gcc dot gnu dot org  2010-05-20 17:39 
---
Fix checked in on March 26, 2010.


-- 

meissner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/44214] New: Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

If you have code that does division by a constant that can be auto vectorized
by the compiler, the compiler does not convert the division to multiplication
by the reciprocal if -freciprocal-math (or -ffast-math), but instead does the
division.

The bug is in fold-const.c near line 11254, where the code for handling
REAL_CST should be cloned to handle VECTOR_CST (and presumably COMPLEX_CST
also).


-- 
   Summary: Compiler does not optimize vector divide with -
freciprocal-math (or -ffast-math)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

[dje at gcc dot gnu dot org]

--- Comment #21 from dje at gcc dot gnu dot org  2010-05-20 17:52 ---
I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR
44132, which was necessary to get back to a sane level of C++ and libgomp
failures on AIX.  The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch did not have
any further affect on AIX testsuite results.


-- 


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

[Bug c++/44215] New: undefinied reference with static constant initialized data member in conditional expression

[doreille at smr dot ch]

The following code raise undefined reference link errors:
toto.C:(.text+0x10): undefined reference to `A::a'
toto.C:(.text+0x18): undefined reference to `B::a'

The code:

struct A {
static const int a = 0;
};

struct B {
static const int a = 1;
};

int main() {
bool b = true;
return b ? A::a : B::a;
}


-- 
   Summary: undefinied reference with static constant initialized
data member in conditional expression
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doreille at smr dot ch


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

[Bug c++/44215] undefinied reference with static constant initialized data member in conditional expression

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-20 17:53 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42101] Linking failure with static constants and ternary inline function

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2010-05-20 17:53 
---
*** Bug 44215 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doreille at smr dot ch


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

[Bug target/44199] ppc64 glibc miscompilation

[pthaugen at gcc dot gnu dot org]

--- Comment #11 from pthaugen at gcc dot gnu dot org  2010-05-20 17:59 
---
No I didn't bootstrap/regtest. I can take care of trunk if you want to do 4.4.


-- 


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

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2010-05-20 18:00 
---
Actually in looking at it further, I was wrong in the initial claim.  Auto
vectorization now handles division by a constant.  Explicit vectors like
PowerPC (and probably SPU) do show the problem.


-- 


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

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2010-05-20 18:02 
---
Created an attachment (id=20712)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20712&action=view)
Example program that shows the issue on powerpc.

Compile with -mcpu=power7 on powerpc.


-- 


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

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-05-20 18:14 ---
Fixed for 4.3.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/44216] New: [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

Since the introduction of the configure check for the --no-merge-exidx-entries
linker option, all libjava tests fail on IRIX 6.5:

output is:
(null): WARNING 1  : Unknown option: -no-merge-exidx-entries (ignored).


FAIL: linking PR9577

The problem is that the SGI ld warns about unknown options as above, but still
exists with status 0.  None of the options to suppress errors/warnings has an
effect on this, neither -LD_MSG:error=1 nor -LD_MSG:off=1 nor -woff 1.

I've found no good way to handle this generically, since the AC_LINK_IFELSE
macro only logs stderr of the link command to conftest,err and the warning
goes to stdout.  I could of course simply set libgcj_cv_exidx=no for
mips-sgi-irix6.5, but perhaps there's a cleaner solution I'm just not seeing?


-- 
   Summary: [4.6 regression] All libjava tests fail on IRIX 6.5: ld
warns about -no-merge-exidx-entries
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2010-05-20 18:23 ---
Paolo, do you happen to have an idea how to handle this cleanly?


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-05-20 18:23 ---
If you could, it would be very much appreciated.  Starting 4.4
bootstrap/regtest now.


-- 


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

[Bug testsuite/28242] running the testsuite with -fstack-protector fail (not finding libssp)

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-05-20 18:26 ---
This is not an enhancement, but simply a bug: the testsuite should use the
built
libraries, not some version that happens (or not) to be installed on the
system.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
   Severity|enhancement |normal
  Known to fail||4.6.0
   Last reconfirmed|2006-07-04 14:40:54 |2010-05-20 18:26:55
   date||


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

[Bug target/44217] New: GCC emits cmpxchg16b which Sun as cannot handle

[ro at gcc dot gnu dot org]

On Solaris 11/x86 with Sun as, two 64-bit libgomp testcases fail:

FAIL: libgomp.c/atomic-2.c (test for excess errors)
WARNING: libgomp.c/atomic-2.c compilation failed to produce executable
FAIL: libgomp.c/atomic-5.c (test for excess errors)
WARNING: libgomp.c/atomic-5.c compilation failed to produce executable

In libgomp.log, I find

Excess errors:
Assembler: atomic-2.c
"/var/tmp//ccXCaqFL.s", line 51 : Illegal mnemonic
Near line: "lock cmpxchg16b ld(%rip)"
"/var/tmp//ccXCaqFL.s", line 51 : Syntax error
Near line: "lock cmpxchg16b ld(%rip)"
"/var/tmp//ccXCaqFL.s", line 51 : Illegal mnemonic
Near line: "lock cmpxchg16b ld(%rip)"

>From running strings on the as binary, Sun as simply doesn't know about this
instruction.


-- 
   Summary: GCC emits cmpxchg16b which Sun as cannot handle
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug target/44218] New: Improve powerpc -mrecip support

[meissner at gcc dot gnu dot org]

The current powerpc -mrecip can be improved in several areas.

1) The compiler generates a conditional test to deal with NaN, etc. even though
it is only used with -ffast-math, where the programmer declares that he/she is
not interested in Nan/infinity/etc.  This causes the code to single thread the
approximation, and does not allow the power7 to issue two streams of FRSQRTES
and fixup in parallel.

2) Right now, -mrecip only enables single precision reciprocal square estimate.
 The compiler should be modified so that it also supports double precision
reciprocal estimate on newer machines (power6/power7) that have a high enough
precision FRSQRTE instruction.

3) In addition to optimizing 1/sqrt(x), the compiler should be able to optimize
normal divisions using the FRE/FRES instructions.  Machines with higher
precision FRE instructions should do fewer passes in the fixup than the older
machines.

4) On altivec and VSX systems, the compiler should enable auto vectorization of
the estimate instructions and fixup.

5) The compiler should provide more builtins to allow the user to access to
double reciprocal square root, as well as vector versions.


-- 
   Summary: Improve powerpc -mrecip support
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: meissner at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-05-20 18:45 ---
Note: The ICE happens with 4.5 and trunk. With 4.4 one gets

allocate(this%list(dim),source=[(i,i=1,dim)])
  1
Error: Syntax error in ALLOCATE statement at (1)

since support for the SOURCE argument was only added in 4.5.


-- 


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

[Bug c++/44219] New: Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

I apologize if this is not a bug, or if it has been reported (I thoroughly
searched the bug database, but couldn't find anything related).
When class B publicly inherit class A, class A private members should be seen
as private in class B. However, they are not visible in class B (as if "public"
keyword was omitted). Here is the whole example:

class A {
  int x;
};

class B : public A {
  B()
  {
x = 5;
  }

};


int main(int argc, char *argv[])
{
return 0;
}

And here is the compiler output:
g++ -v -save-temps bug1.cpp

Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/specs
Target: x86_64-slackware-linux
Configured with: ../gcc-4.4.4/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib
--with-python-dir=/lib64/python2.6/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose
--disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 4.4.4 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-slackware-linux/4.4.4/cc1plus -E -quiet -v
-D_GNU_SOURCE bug1.cpp -mtune=generic -fpch-preprocess -o bug1.ii
ignoring duplicate directory "/usr/lib64/qt/include"
ignoring duplicate directory "/usr/lib/qt/include"
ignoring nonexistent directory
"/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../x86_64-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/qt/include
 /usr/lib/qt/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4

/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-slackware-linux

/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4/backward
 /usr/local/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-slackware-linux/4.4.4/cc1plus -fpreprocessed bug1.ii
-quiet -dumpbase bug1.cpp -mtune=generic -auxbase bug1 -version -o bug1.s
GNU C++ (GCC) version 4.4.4 (x86_64-slackware-linux)
compiled by GNU C version 4.4.4, GMP version 5.0.1, MPFR version
2.4.2-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: df3503c115036a5e101a3ec035b30ab4
bug1.cpp: In constructor ‘B::B()’:
bug1.cpp:5: error: ‘int A::x’ is private
bug1.cpp:12: error: within this context


-- 
   Summary: Public inheritance treated as private
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeljkoj at tesla dot rcub dot bg dot ac dot rs
 GCC build triplet: x86_64-slackware-linux
  GCC host triplet: x86_64-slackware-linux
GCC target triplet: x86_64-slackware-linux


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

[Bug c++/44219] Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

--- Comment #1 from zeljkoj at tesla dot rcub dot bg dot ac dot rs  
2010-05-20 18:51 ---
Created an attachment (id=20713)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20713&action=view)
Preprocessed source of the test case


-- 


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

[Bug c++/44219] Public inheritance treated as private

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-05-20 18:51 ---
> class A private members should be seen as private in class B

No, they are private to A which means only A can access them, not any base
classes.  If you want that, use protected.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[uros at gcc dot gnu dot org]

--- Comment #27 from uros at gcc dot gnu dot org  2010-05-20 18:52 ---
Subject: Bug 43733

Author: uros
Date: Thu May 20 18:52:03 2010
New Revision: 159636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159636
Log:
PR target/43733
* configure.ac (gcc_cv_as_ix86_sahf): Switch to 64bit mode.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.md (x86_sahf_1): Conditionally output 0x9e
instead of sahf only for 64bit targets.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/i386.md
trunk/gcc/configure
trunk/gcc/configure.ac


-- 


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|bootstrap   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 18:52:52
   date||


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

[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-05-20 19:01 ---
Confirmed. Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0,
ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2497
2497n = se->loop->order[0];
(gdb) bt
#0  0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0,
ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2497
#1  0x00571f17 in gfc_conv_array_ref (se=0x7fffd6a0, ar=0x17f6048,
sym=0x17f4370, where=0x17f40f0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2550
#2  0x005988e0 in gfc_conv_variable (se=0x7fffd6a0, expr=0x17f40a0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:702
#3  0x005a3712 in gfc_conv_expr (se=0x7fffd6a0, expr=0x17f40a0) at
/home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:4453
#4  0x0059a833 in get_proc_ptr_comp (e=0x17f2560) at
/home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:1529
#5  0x0059a88b in conv_function_val (se=0x7fffdd60, sym=0x17effb0,
expr=0x17f2560) at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:1541
#6  0x0059fe41 in gfc_conv_procedure_call (se=0x7fffdd60,
sym=0x17effb0, arg=0x0, expr=0x17f2560, append_args=0x0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:3323


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 19:01:47
   date||
Summary|ICE with TBP of pointer |[OOP] ICE with TBP of
   |component of derived type   |pointer component of derived
   |array   |type array
   Target Milestone|--- |4.6.0


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

[Bug c++/44219] Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

--- Comment #3 from zeljkoj at tesla dot rcub dot bg dot ac dot rs  
2010-05-20 19:13 ---

> > class A private members should be seen as private in class B
> 
> No, they are private to A which means only A can access them, not any base
> classes.  If you want that, use protected.

You are right. Thank you for a quick reply.


-- 


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

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-05-20 19:15 ---
Confirmed.

I think the code is valid. At least 'A_type' being defined after 'B_type' is
not a problem, since the Fortran 2003 standard says:

C438 (R440) If the POINTER attribute is not specified for a component,
the declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall
specify an intrinsic type or a previously defined derived type.

C439 (R440) If the POINTER attribute is specified for a component, the
declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall
specify an intrinsic type or any accessible derived type including the type
being defined.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 19:15:09
   date||


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

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-20 19:19 ---
*** Bug 39994 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug fortran/39994] Bounds checking (-fcheck=bounds): "A = [ constructor ]" does not work

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-20 19:19 ---
(In reply to comment #2)
> I believe that this is a duplicate of PR 31059.

Me too.

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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

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

[paolo at gcc dot gnu dot org]

--- Comment #12 from paolo at gcc dot gnu dot org  2010-05-20 19:32 ---
Subject: Bug 30298

Author: paolo
Date: Thu May 20 19:31:47 2010
New Revision: 159637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159637
Log:
/cp
2010-05-20  Paolo Carlini  

PR c++/30298
* decl.c (xref_basetypes): Return false in case of ill-formed
redefinition.

/testsuite
2010-05-20  Paolo Carlini  

PR c++/30298
* g++.dg/inherit/crash1.C: New.
* g++.dg/inherit/crash2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/inherit/crash1.C
trunk/gcc/testsuite/g++.dg/inherit/crash2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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