[Bug testsuite/49432] New: [4.7 Regression] FAIL: obj-c++.dg/invalid-type-1.mm

[dominiq at lps dot ens.fr]

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

   Summary: [4.7 Regression] FAIL: obj-c++.dg/invalid-type-1.mm
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: nicola.p...@meta-innovation.com


At revision 175082 obj-c++.dg/invalid-type-1.mm fails

FAIL: obj-c++.dg/invalid-type-1.mm -fgnu-runtime  (test for errors, line 21)
FAIL: obj-c++.dg/invalid-type-1.mm -fgnu-runtime  (test for errors, line 24)
FAIL: obj-c++.dg/invalid-type-1.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/invalid-type-1.mm -fnext-runtime  (test for errors, line 21)
FAIL: obj-c++.dg/invalid-type-1.mm -fnext-runtime  (test for errors, line 24)
FAIL: obj-c++.dg/invalid-type-1.mm -fnext-runtime (test for excess errors)

This is due to a change in the error messages

Excess errors:
/opt/gcc/work/gcc/testsuite/obj-c++.dg/invalid-type-1.mm:21:1: error: 'Integer
{aka int}' is not a template
/opt/gcc/work/gcc/testsuite/obj-c++.dg/invalid-type-1.mm:24:1: error: 'Integer
{aka int}' is not a template

 which no longer match ".Integer. is not a template".

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[xinliangli at gmail dot com]

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

--- Comment #25 from davidxl  2011-06-16 07:41:57 
UTC ---
On Wed, Jun 15, 2011 at 10:26 PM, ebotcazou at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #24 from Eric Botcazou 
> 2011-06-16 05:26:56 UTC ---
> > It would be nice if the expander does not spill the return into memory in
> the
> > first place if possible.  On other hand tagging compiler created memory
> > location with temp decls so that aliaser has the symbolic information
> seems a
> > useful mechanism.
>
> But a poor kludge if you can avoid spilling to memory in the first place.
>

No I am talking about more general situation where temporary memory is
created in RTL pass.

David


>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-06-16 
07:45:22 UTC ---
Author: jakub
Date: Thu Jun 16 07:45:17 2011
New Revision: 175092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175092
Log:
PR tree-optimization/49419
* tree-vrp.c (execute_vrp): Call init_range_assertions
before estimate_numbers_of_iterations, call
free_number_of_iterations_estimates before calling
remove_range_assertions.

* gcc.c-torture/execute/pr49419.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr49419.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug target/44618] [4.4/4.5/4.6 regression] wrong code with -frename-registers

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  2011-06-16 
07:50:00 UTC ---
Author: jakub
Date: Thu Jun 16 07:49:58 2011
New Revision: 175093

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175093
Log:
2011-06-13  Edmar Wienskoski  

PR target/44618
* config/rs6000/rs6000.md (save_gpregs_): Replaced pattern
with a set of similar patterns, where the MATCH_OPERAND for the
function argument is replaced with individual references to hardware
registers.
(save_fpregs_): Ditto
(restore_gpregs_): Ditto
(return_and_restore_gpregs_): Ditto
(return_and_restore_fpregs_): Ditto
(return_and_restore_fpregs_aix_): Ditto

* gcc.target/powerpc/outofline_rnreg.c: New testcase.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/44618] [4.4/4.5/4.6 regression] wrong code with -frename-registers

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  2011-06-16 
07:52:47 UTC ---
Author: jakub
Date: Thu Jun 16 07:52:44 2011
New Revision: 175094

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175094
Log:
Backported from mainline
2011-06-13  Edmar Wienskoski  

PR target/44618
* config/rs6000/rs6000.md (save_gpregs_): Replaced pattern
with a set of similar patterns, where the MATCH_OPERAND for the
function argument is replaced with individual references to hardware
registers.
(save_fpregs_): Ditto
(restore_gpregs_): Ditto
(return_and_restore_gpregs_): Ditto
(return_and_restore_fpregs_): Ditto
(return_and_restore_fpregs_aix_): Ditto

* gcc.target/powerpc/outofline_rnreg.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/outofline_rnreg.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-06-16 
07:54:46 UTC ---
Author: jakub
Date: Thu Jun 16 07:54:43 2011
New Revision: 175095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175095
Log:
PR tree-optimization/49419
* tree-vrp.c (execute_vrp): Call init_range_assertions
before estimate_numbers_of_iterations, call
free_number_of_iterations_estimates before calling
remove_range_assertions.

* gcc.c-torture/execute/pr49419.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49419.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-vrp.c

[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Jakub Jelinek  2011-06-16 
08:17:46 UTC ---
The bug should be fixed now, though VRP should be cerrtainly improved in
various ways, including choosing better vr during extract_range_from_assert,
trying to derive numeric ranges from symbolic ranges x - 1 maximums or x + 1
minimums,
and IMHO adjust_range_for_scev could use number_of_latch_executions to see if
the number is simple enough and a smaller iteration count can be derived from
its value ranges or, e.g. if it is the init SSA_NAME itself or that plus/minus
a constant, it could determine it doesn't decrease until -INF but only until 0
+- constant.

[Bug target/41999] Bug in generation of interrupt function code for ARM processor

[domen at cba dot si]

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

Domen Puncer  changed:

   What|Removed |Added

 CC||domen at cba dot si

--- Comment #3 from Domen Puncer  2011-06-16 08:23:25 UTC 
---
FWIW, this and 45540 don't happen on gcc 4.5.2 anymore (confirmed that it DOES
happen on 2010q1-188 4.4.1):

irq_:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sublr, lr, #4
stmfdsp!, {r0, r1, r2, r3, r4, r5, ip, lr}
ldrr4, .L2
ldrr0, [r4, #0]
blexternal
ldrr0, [r4, #0]
movr3, r0, asl #1
movr0, r3
strr3, [r4, #0]
blexternal
ldmfdsp!, {r0, r1, r2, r3, r4, r5, ip, pc}^
.L3:
.align2
.L2:
.word.LANCHOR0
.sizeirq_, .-irq_
.bss
.align2
.set.LANCHOR0,. + 0
.typecnt, %object
.sizecnt, 4
cnt:
.space4
.ident"GCC: (Sourcery G++ Lite 2011.03-42) 4.5.2"

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de  
2011-06-16 08:36:21 UTC ---
On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> 
> davidxl  changed:
> 
>What|Removed |Added
> 
>  CC||xinliangli at gmail dot com
> 
> --- Comment #23 from davidxl  2011-06-15 
> 23:14:50 UTC ---
> (In reply to comment #22)
> > > The DSE patch still leaves 2 redundant stores.
> > 
> > OK, I missed this, reopening...
> > 
> > > The following patch will enable DSE to remove those two stores. Does this
> > > look ok?
> > 
> > Calling into the gimplifier from the RTL expander doesn't look appropriate.

It also should use create_tmp_var, not create_tmp_reg.  But I wonder why
memory allocated via assign_temp isn't marked in a way to let dse
do its job (I guess dse thinks that memory escapes?).

> > More fundamentally, it's a little unfortunate to spill to memory a value
> > returned in registers.  Can we try to use emit_group_move_into_temps here
> > instead (under the appropriate circumstances)?
> 
> It would be nice if the expander does not spill the return into memory in the
> first place if possible.  On other hand tagging compiler created memory
> location with temp decls so that aliaser has the symbolic information seems a
> useful mechanism. 

Sure - but I wonder why assign_temp doesn't do something equivalent
that doesn't require a automatic VAR_DECL to be created.

Where does the aliaser catch things with the VAR_DECL around that
it doesn't without it?

Richard.

[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.7.0
Summary|dse.c changes to fix|[4.7 Regression] dse.c
   |PR44194 (r175063) cause |changes to fix PR44194
   |execution failures  |(r175063) cause execution
   ||failures

[Bug c/49428] Wrong FP calculation that yields 0.0.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-06-16 
08:51:35 UTC ---
Well, properly return uint64_t from rdtsc ... otherwise you only get the
lower bits.

[Bug target/49313] Inefficient libgcc implementations for avr

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2011-06-16 
09:06:50 UTC ---
Author: gjl
Date: Thu Jun 16 09:06:44 2011
New Revision: 175097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175097
Log:
gcc/
PR target/49313
PR target/29524
* longlong.h: Add AVR support:
(count_leading_zeros): New macro.
(count_trailing_zeros): New macro.
(COUNT_LEADING_ZEROS_0): New macro.
* config/avr/t-avr (LIB1ASMFUNCS): Add
_ffssi2, _ffshi2, _loop_ffsqi2,
_ctzsi2, _ctzhi2, _clzdi2, _clzsi2, _clzhi2, 
_paritydi2, _paritysi2, _parityhi2,
_popcounthi2,_popcountsi2, _popcountdi2, _popcountqi2,
_bswapsi2, _bswapdi2,
_ashldi3, _ashrdi3, _lshrdi3
(LIB2FUNCS_EXCLUDE): Add _clz.
* config/avr/libgcc.S (XCALL): Move up in file.
(XJMP): New C Macro.
(DEFUN): New asm macro.
(ENDF): New asm macro.
(__ffssi2): New function.
(__ffshi2): New function.
(__loop_ffsqi2): New function.
(__ctzsi2): New function.
(__ctzhi2): New function.
(__clzdi2): New function.
(__clzsi2): New function.
(__clzhi2): New function.
(__paritydi2): New function.
(__paritysi2): New function.
(__parityhi2): New function.
(__popcounthi2): New function.
(__popcountsi2): New function.
(__popcountdi2): New function.
(__popcountqi2): New function.
(__bswapsi2): New function.
(__bswapdi2): New function.
(__ashldi3): New function.
(__ashrdi3): New function.
(__lshrdi3): New function.
Fix suspicous lines.

libgcc/
PR target/49313
PR target/29524
* config/avr/t-avr: Fix line endings.
(intfuncs16): Remove _ffsXX2,  _clzXX2, _ctzXX2, _popcountXX2,
_parityXX2.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/libgcc.S
trunk/gcc/config/avr/t-avr
trunk/gcc/longlong.h
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/t-avr

[Bug target/29524] [4.3/4.4/4.5/4.6/4.7 Regression] Too much RAM used: __clz_tab[] linked

[gjl at gcc dot gnu.org]

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

--- Comment #24 from Georg-Johann Lay  2011-06-16 
09:06:50 UTC ---
Author: gjl
Date: Thu Jun 16 09:06:44 2011
New Revision: 175097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175097
Log:
gcc/
PR target/49313
PR target/29524
* longlong.h: Add AVR support:
(count_leading_zeros): New macro.
(count_trailing_zeros): New macro.
(COUNT_LEADING_ZEROS_0): New macro.
* config/avr/t-avr (LIB1ASMFUNCS): Add
_ffssi2, _ffshi2, _loop_ffsqi2,
_ctzsi2, _ctzhi2, _clzdi2, _clzsi2, _clzhi2, 
_paritydi2, _paritysi2, _parityhi2,
_popcounthi2,_popcountsi2, _popcountdi2, _popcountqi2,
_bswapsi2, _bswapdi2,
_ashldi3, _ashrdi3, _lshrdi3
(LIB2FUNCS_EXCLUDE): Add _clz.
* config/avr/libgcc.S (XCALL): Move up in file.
(XJMP): New C Macro.
(DEFUN): New asm macro.
(ENDF): New asm macro.
(__ffssi2): New function.
(__ffshi2): New function.
(__loop_ffsqi2): New function.
(__ctzsi2): New function.
(__ctzhi2): New function.
(__clzdi2): New function.
(__clzsi2): New function.
(__clzhi2): New function.
(__paritydi2): New function.
(__paritysi2): New function.
(__parityhi2): New function.
(__popcounthi2): New function.
(__popcountsi2): New function.
(__popcountdi2): New function.
(__popcountqi2): New function.
(__bswapsi2): New function.
(__bswapdi2): New function.
(__ashldi3): New function.
(__ashrdi3): New function.
(__lshrdi3): New function.
Fix suspicous lines.

libgcc/
PR target/49313
PR target/29524
* config/avr/t-avr: Fix line endings.
(intfuncs16): Remove _ffsXX2,  _clzXX2, _ctzXX2, _popcountXX2,
_parityXX2.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/libgcc.S
trunk/gcc/config/avr/t-avr
trunk/gcc/longlong.h
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/t-avr

[Bug c++/49433] New: internal compiler error: in write_builtin_type, at cp/mangle.c:2167

[philb at gnu dot org]

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

   Summary: internal compiler error: in write_builtin_type, at
cp/mangle.c:2167
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org


Created attachment 24543
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24543
testcase

Due to some stray CFLAGS I found myself compiling libstdc++ with -flto turned
on, which yielded:

$ arm-oe-linux-gnueabi-g++ -O2 -flto -g -fpermissive -std=gnu++0x atomic.ii -S
In file included from
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libstdc++-v3/include/functional:59:0,
 from
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libstdc++-v3/include/mutex:43,
 from
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/libstdc++-v3/src/atomic.cc:28:
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libstdc++-v3/include/bits/functional_hash.h:
In instantiation of 'std::size_t std::hash<_Tp>::operator()(_Tp) const [with
_Tp = long double, std::size_t = unsigned int]':
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/libstdc++-v3/src/atomic.cc:122:1:
  instantiated from here
/home/pb/oe/build-giga/tmp-eglibc/work/armv6-oe-linux-gnueabi/gcc-runtime-4.6.0-r4/gcc-4.6.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libstdc++-v3/include/bits/functional_hash.h:184:5:
internal compiler error: in write_builtin_type, at cp/mangle.c:2167
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

[Bug target/29524] [4.3/4.4/4.5/4.6/4.7 Regression] Too much RAM used: __clz_tab[] linked

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |RESOLVED
  Known to work||4.7.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.7.0

--- Comment #25 from Georg-Johann Lay  2011-06-16 
09:47:09 UTC ---
Closed as resolved+fixed as using __clz_tab is avoided altogether now.

[Bug c++/49434] New: Cypher ECC using libecc library

[antoniolife at hotmail dot it]

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

   Summary: Cypher ECC using libecc library
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoniol...@hotmail.it


Hi,

I need to create a c++ code that realize the Ecc cypher (Elliptic Curve
Cryptography) using the libecc library. Somebody have something like that? 
I agree to any suggestions. 
Thanks a lot.

[Bug target/46779] wrong code generation for array access

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.16 10:01:03
 CC|avr at gjlay dot de |gjl at gcc dot gnu.org
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

--- Comment #9 from Georg-Johann Lay  2011-06-16 
10:01:03 UTC ---
Reconfirmed with current 4.7 trunk against 

gcc.target/avr/pr46779-1.c

[Bug c++/49434] Cypher ECC using libecc library

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  2011-06-16 
10:18:07 UTC ---
Not a bug. This is not a forum to learn C++, check stackoverflow.com

[Bug target/49427] v850e-elf wants 850e/v850e-common.c

[nickc at gcc dot gnu.org]

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

--- Comment #2 from Nick Clifton  2011-06-16 10:21:08 
UTC ---
Author: nickc
Date: Thu Jun 16 10:21:05 2011
New Revision: 175100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175100
Log:
PR target/49427
* config.gcc: Set cpu_type to v850 for any V850 architecture.
(v850*-*-*): Delete explicit setting of tm_p_file, tmake_file,
md_file, extra_modes, out_file and extra_options are these are all
deduced from cpu_type.

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

[Bug other/49435] New: get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[longvalery at gmail dot com]

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

   Summary: get_z.c:46: MPFR assertion failed: exp < 0 || exp <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: longval...@gmail.com


I try build Wine on machine: "Linux comp-MCVC 2.4.32-vniins42 #1 Wed Jul 25
00:00:00 MSD 2007 i686 i686 i386 GNU/Linux"
but got next error (see Summary)
Full log below
-start log -
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --with-gmp=/usr/local
--disable-libquadmath --disable-libquadmath-support --disable-libgcj
--enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.6.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-I' '.' '-I' '.' '-I' '../../include' '-I'
'../../include' '-D' '__WINESRC__' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe'
'-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wstrict-prototypes'
'-Wtype-limits' '-Wwrite-strings' '-Wpointer-arith' '-Wlogical-op' '-v'
'-save-temps' '-g' '-O2' '-o' 'arb_program_shader.o' '-mtune=generic'
'-march=pentiumpro'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1 -E -quiet -v -I . -I . -I
../../include -I ../../include -D __WINESRC__ -D _REENTRANT
arb_program_shader.c -mtune=generic -march=pentiumpro -Wall
-Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings
-Wpointer-arith -Wlogical-op -fPIC -fno-strict-aliasing -g -fworking-directory
-O2 -fpch-preprocess -o arb_program_shader.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../include"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../include
 /usr/lib/gcc/i686-pc-linux-gnu/4.6.0/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-I' '.' '-I' '.' '-I' '../../include' '-I'
'../../include' '-D' '__WINESRC__' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe'
'-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wstrict-prototypes'
'-Wtype-limits' '-Wwrite-strings' '-Wpointer-arith' '-Wlogical-op' '-v'
'-save-temps' '-g' '-O2' '-o' 'arb_program_shader.o' '-mtune=generic'
'-march=pentiumpro'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1 -fpreprocessed
arb_program_shader.i -quiet -dumpbase arb_program_shader.c -mtune=generic
-march=pentiumpro -auxbase-strip arb_program_shader.o -g -O2 -Wall
-Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings
-Wpointer-arith -Wlogical-op -version -fPIC -fno-strict-aliasing -o
arb_program_shader.s
GNU C (GCC) version 4.6.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version 3.0.1, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32052
GNU C (GCC) version 4.6.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version 3.0.1, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32052
Compiler executable checksum: 6b9885df530ab8e935fc0944a8cab71e
get_z.c:46: MPFR assertion failed: exp < 0 || exp <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
In file included from arb_program_shader.c:35:0:
wined3d_private.h: In function 'float_16_to_32':
wined3d_private.h:202:9: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [arb_program_shader.o] Error 1
-- end log -

Can you help me?

[Bug fortran/49436] New: Modifying actual arguments in subroutine not detected

[tjf at rsc dot anu.edu.au]

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

   Summary: Modifying actual arguments in subroutine not detected
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@rsc.anu.edu.au
  Host: i686-pc-linux-gnu


Created attachment 24544
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24544
Nonconforming code that compiles happily

There's an aspect of the f95 standard that seems to not be enforced by
gfortran.

As I interpret it, the standard says that if an object passed as an actual
argument is also accessible in a subprogram through other means, then this can
only be modified through the corresponding dummy argument (12.4.1.6).

The attached code violates this by modifying a directly inside subroutine c,
rather than through the dummy argument n.  With gfortran 4.6.0 on
i686-pc-linux-gnu this nonconforming code compiles happily, even with -Wall
-std=f95 -pedantic.

When run, two 15s are printed despite the value 2 being passed as intent(in)
(clearly the argument is passed by reference).

[Bug middle-end/33349] Redundant zero-extension of registers

[gcc.hall at gmail dot com]

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

Jeremy  changed:

   What|Removed |Added

 CC||gcc.hall at gmail dot com

--- Comment #2 from Jeremy  2011-06-16 11:27:24 UTC 
---

Another example I came across ...

  unsigned short sw;
  asm( "fnstsw %0" : "=a" (sw) );

  if( sw & FE_DIVBYZERO )
...   
  if( sw & FE_OVERFLOW )
...  
  if( sw & FE_UNDERFLOW )
...

generates:

movzx   eax, ax # D.14460, sw

testal, 1   # D.14460,

testal, 4   # D.14460,

testal, 8   # D.14460,

[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-06-16 11:45:09 UTC ---
Author: janus
Date: Thu Jun 16 11:45:05 2011
New Revision: 175101

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175101
Log:
2011-06-16  Janus Weil  

PR fortran/49417
* module.c (mio_component): Make sure the 'class_ok' attribute is set
for use-associated CLASS components.
* parse.c (parse_derived): Check for 'class_ok' attribute.
* resolve.c (resolve_fl_derived): Ditto.

2011-06-16  Janus Weil  

PR fortran/49417
* gfortran.dg/class_43.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_43.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/49437] New: interrupt return pop sometimes corrupts sp

[domen at cba dot si]

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

   Summary: interrupt return pop sometimes corrupts sp
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: do...@cba.si


Simple to reproduce, it seems >=5 arguments with any of printf* can cause this.
Some code around it was left, as it does not happen otherwise.

$ cat bug.c 
#include 

char *pending_messages_put_start(void);
void pending_messages_put_final(void);

void __attribute__((interrupt)) TIM7_IRQHandler(void)
{
char *msg = pending_messages_put_start();
snprintf(msg, 20, "%i %i", 1, 1);
pending_messages_put_final();
}
$ arm-none-eabi-gcc -Wall -Os -S bug.c
$ cat bug.s 
.syntax unified
.arch armv7-m
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.thumb
.file   "bug.c"
.text
.align  1
.global TIM7_IRQHandler
.thumb
.thumb_func
.type   TIM7_IRQHandler, %function
TIM7_IRQHandler:
@ Stack Align: May be called with mis-aligned SP.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
mov r0, sp
bic r1, r0, #7
mov sp, r1
push{r0, lr}
sub sp, sp, #8
bl  pending_messages_put_start
movsr3, #1
movsr1, #20
ldr r2, .L2
str r3, [sp, #0]
bl  snprintf
bl  pending_messages_put_final
pop {r0, r2, r3, lr}// <-- r3 is in place of r0; expected would
be add sp, sp, #8, pop {r0, lr}, I guess
mov sp, r0
bx  lr
.L3:
.align  2
.L2:
.word   .LC0
.size   TIM7_IRQHandler, .-TIM7_IRQHandler
.section.rodata.str1.1,"aMS",%progbits,1
.LC0:
.ascii  "%i %i\000"
.ident  "GCC: (GNU) 4.5.3"

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2011-06-16 12:00:52 UTC ---
(In reply to comment #0)
> As I interpret it, the standard says that if an object passed as an actual
> argument is also accessible in a subprogram through other means, then this can
> only be modified through the corresponding dummy argument (12.4.1.6).

I guess you refer to this part:


(2) If the value of any part of the entity is affected through the dummy
argument, then at any time during the execution of the procedure, either before
or after the definition, it may be referenced only through that dummy argument
unless
(a) the dummy argument has the POINTER attribute,
(b) the part is all or part of a pointer subobject, or
(c) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT (IN), the dummy argument is a scalar object or an assumed-shape
array, and the actual argument is a target other than an array section with a
vector subscript.


And indeed I would interpret it in the same way as you do. However, the
question is whether the standard requires the *compiler* to enforce this
restriction, or if it is simply a restriction that the programmer is supposed
to follow.

Are you aware of any compiler which enforces this restriction?

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-06-16 
12:04:35 UTC ---
(In reply to comment #0)
> There's an aspect of the f95 standard that seems to not be enforced by
> gfortran.

The Fortran standard only requires that constraints ("C" in the
standard) are checked by the compiler. Some other things might be checkable
(and compilers do diagnose some of those) - either at compile time or at run
time, but for a lot of code, it is practically impossible to diagnose the
invalidity.

Your program belongs to the latter:

call c(a)
[...]
subroutine c(n)
integer,intent(in)::n
a=15

This cannot be detected in general - and in specific cases only with
difficulty. I doubt that any Fortran compiler can detect this at compile time -
and I am not sure whether there is any which can do so at run time.

Assume, the variable "a" is in one file, the caller in another and the callee
in the third. In that case it should be clear that a compile-time diagnostic is
unfortunately not possible.

By the way, the result of your program depends on the compiler. Some might do a
copy-in of the argument, in that case "n" and "a" are disjunct. Or the compiler
might not do so - which gives the known result that modifying "a" also modifies
"n".


Thus, I think it is (unfortunately) a WONTFIX bug.

[Bug fortran/49438] New: error during make

[eisoab at gmail dot com]

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

   Summary: error during make
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eis...@gmail.com


Created attachment 24545
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24545
config.log

make ends with 

checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/home/e.ab/software/src/gcc-4.5.3-build/i686-pc-linux-gnu/libgfortran/config.log
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: Leaving directory `/data1/software/src/gcc-4.5.3-build'
make: *** [all] Error 2


config.log attached...

-E

[Bug middle-end/49439] New: [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed
to build
   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-64, revision 175074 gave:

g++  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64EtherAppCli.o EtherAppCli_n.o
EtherAppSrv.o EtherAppSrv_n.o EtherApp_m.o EtherBus.o EtherBus_n.o
EtherCtrl_m.o EtherEncap.o EtherEncap_n.o EtherFrame_m.o EtherHost_n.o
EtherHub.o EtherHub_n.o EtherLLC.o EtherLLC_n.o EtherMAC.o EtherMAC_n.o
EtherSwitch_n.o LargeNet_n.o MACAddress.o MACAddress_m.o MACRelayUnitBase.o
MACRelayUnitNP.o MACRelayUnitNP_n.o MACRelayUnitPP.o MACRelayUnitPP_n.o
MACRelayUnit_n.o Networks_n.o eth-index_n.o utils.o libs/cmdenv/cmdenv.o
libs/cmdenv/enumstr.o libs/cmdenv/heap.o libs/envir/akoutvectormgr.o
libs/envir/args.o libs/envir/cenvir.o libs/envir/cinifile.o
libs/envir/filemgrs.o libs/envir/main.o libs/envir/omnetapp.o
libs/envir/patmatch.o libs/envir/platdep.o libs/envir/seeds.o
libs/envir/slaveapp.o libs/envir/speedmtr.o libs/sim/carray.o
libs/sim/cexception.o libs/sim/cmessage.o libs/sim/cpar.o libs/sim/ctypes.o
libs/sim/task.o libs/sim/cchannel.o libs/sim/cfsm.o libs/sim/cmodule.o
libs/sim/cpsquare.o libs/sim/cvarhist.o libs/sim/util.o libs/sim/ccoroutine.o
libs/sim/cgate.o libs/sim/cmsgheap.o libs/sim/cqueue.o libs/sim/cwatch.o
libs/sim/cdensity.o libs/sim/chead.o libs/sim/cnetmod.o libs/sim/csimul.o
libs/sim/distrib.o libs/sim/cdetect.o libs/sim/chist.o libs/sim/cobject.o
libs/sim/cstat.o libs/sim/errmsg.o libs/sim/cdispstr.o libs/sim/cksplit.o
libs/sim/coutvect.o libs/sim/cstruct.o libs/sim/onstartup.o libs/sim/cenum.o
libs/sim/cllist.o libs/sim/cpacket.o libs/sim/ctopo.o libs/sim/random.o
libs/sim/std/netpack.o libs/spec/spec_qsort.o -o omnetpp
lto1: internal compiler error: in lto_wpa_write_files, at lto/lto.c:2139
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [omnetpp] Error 1

Revision 174982 is OK.

[Bug middle-end/49439] [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-06-16 
13:15:32 UTC ---
The empty-partition-problem.

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

[Bug lto/48246] ICE in lto_wpa_write_files

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #10 from Richard Guenther  2011-06-16 
13:15:32 UTC ---
*** Bug 49439 has been marked as a duplicate of this bug. ***

[Bug c++/49440] New: Invalid dynamic_cast for unnamed namespace

[hordi at ukr dot net]

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

   Summary: Invalid dynamic_cast for unnamed namespace
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ho...@ukr.net


We have a base class, from this base class we are creating two classes in
unnamed namespace (each class in different *.cpp-file). After that we are
creating one from it and trying to dynamic_cast to other - in result this
operation is processed but should not. This code works properly for gcc-4.4.5
for example...

small description:

file: a.h

class Module{...}

Module *gp = 0;

file a.cpp
namespace
{
  class ItemModule : public Module{}
}

some code:
gp = new ItemModule();

file main.cpp
namespace
{
  class ItemModule : public Module{}
}

int main()
{
  ItemModule *p = dynamic_cast(gp);

  //I expect to see NULL, but have real address
  printf("%p\n",p);
}

[Bug c++/49440] Invalid dynamic_cast for unnamed namespace

[hordi at ukr dot net]

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

--- Comment #1 from Iurii Gordiienko  2011-06-16 13:22:31 
UTC ---
4.5.1, 4.5.2 - same result

[Bug c++/49440] Invalid dynamic_cast for unnamed namespace

[hordi at ukr dot net]

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

--- Comment #2 from Iurii Gordiienko  2011-06-16 13:23:47 
UTC ---
Created attachment 24546
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24546
small example for reprodusing

[Bug fortran/49438] error during make

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-06-16 
13:39:34 UTC ---
In 95% of the cases one sees this error, there is a problem with GMP or MPFR.

That seems to be also the case here:

/home/e.ab/software/src/gcc-4.5.3-build/./gcc/f951: symbol lookup error:
/usr/local/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions


Can you check that your GMP and MPFR are compatible, that they are in the
library search path, etc.?

[Bug middle-end/46500] target.h includes tm.h

[amylaar at gcc dot gnu.org]

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

--- Comment #10 from Jorn Wolfgang Rennecke  
2011-06-16 13:45:54 UTC ---
Author: amylaar
Date: Thu Jun 16 13:45:47 2011
New Revision: 175103

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175103
Log:
PR middle-end/46500
gcc:
* doc/tm.texi.in: Update Copyright date.
* doc/tm.texi: Regenerate.
* targhooks.c (default_setup_incoming_varargs): Replace
CUMULATIVE_ARGS* argument type with cumulative_args_t.
(default_pretend_outgoing_varargs_named): Likewise.
(hook_pass_by_reference_must_pass_in_stack): Likewise.
(hook_callee_copies_named): Likewise.
(default_function_arg_advance): Likewise.
(default_function_arg): Likewise.
(default_function_incoming_arg): Likewise.
(hook_bool_CUMULATIVE_ARGS_false): Likewise.
(hook_bool_CUMULATIVE_ARGS_true): Likewise.
(hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false): Likewise.
(hook_bool_CUMULATIVE_ARGS_mode_tree_bool_true): Likewise.
(hook_int_CUMULATIVE_ARGS_mode_tree_bool_0): Likewise.
* targhooks.h (default_setup_incoming_varargs): Likewise.
(default_pretend_outgoing_varargs_named): Likewise.
(hook_pass_by_reference_must_pass_in_stack): Likewise.
(hook_callee_copies_named): Likewise.
(default_function_arg_advance): Likewise.
(default_function_arg): Likewise.
(default_function_incoming_arg): Likewise.
(hook_bool_CUMULATIVE_ARGS_false): Likewise.
(hook_bool_CUMULATIVE_ARGS_true): Likewise.
(hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false): Likewise.
(hook_bool_CUMULATIVE_ARGS_mode_tree_bool_true): Likewise.
(hook_int_CUMULATIVE_ARGS_mode_tree_bool_0): Likewise.
* target.def (pass_by_reference): Likewise.
(setup_incoming_varargs, strict_argument_naming): Likewise.
(pretend_outgoing_varargs_named, callee_copies): Likewise.
(arg_partial_bytes, function_arg_advance, function_arg): Likewise.
(function_incoming_arg): Likewise.
* target.h: Don't include "tm.h" .
(cumulative_args_t): New typedef.
[GCC_TM_H] (get_cumulative_args): New static inline function.
[GCC_TM_H] (pack_cumulative_args): Likewise.
* config/alpha/alpha.c (alpha_function_arg): Replace CUMULATIVE_ARGS*
argument type with cumulative_args_t.
(alpha_function_arg_advance, alpha_arg_partial_bytes): Likewise.
(alpha_pass_by_reference, alpha_setup_incoming_varargs): Likewise.
* config/frv/frv.c (frv_setup_incoming_varargs): Likewise.
(frv_arg_partial_bytes, frv_function_arg): Likewise.
(frv_function_incoming_arg, frv_function_arg_advance): Likewise.
(frv_function_arg_1): Likewise.
* config/s390/s390.c (s390_pass_by_reference): Likewise.
(s390_function_arg_advance, s390_function_arg): Likewise.
* config/m32c/m32c.c (m32c_function_arg): Likewise.
(m32c_pass_by_reference, m32c_function_arg_advance): Likewise.
(m32c_strict_argument_naming): Likewise.
* config/spu/spu.c (spu_pass_by_reference, spu_function_arg): Likewise.
(spu_function_arg_advance): Likewise.
(spu_setup_incoming_varargs): Likewise.  Make static.
* config/spu/spu-protos.h (spu_setup_incoming_varargs):
Remove prototype.
* config/sparc/sparc.c (sparc_strict_argument_naming): Replace
CUMULATIVE_ARGS* argument type with cumulative_args_t.
(sparc_pass_by_reference, sparc_function_arg_advance): Likewise.
(sparc_function_arg, sparc_function_incoming_arg): Likewise.
(sparc_arg_partial_bytes, sparc_function_arg_1): Likewise.
* config/mep/mep.c (mep_setup_incoming_varargs): Likewise.
(mep_pass_by_reference, mep_function_arg): Likewise.
(mep_function_arg_advance): Likewise.
* config/m32r/m32r.c (m32r_setup_incoming_varargs): Likewise.
(m32r_pass_by_reference, m32r_arg_partial_bytes): Likewise.
(m32r_function_arg, m32r_function_arg_advance): Likewise.
* config/rx/rx.c (rx_function_arg, rx_function_arg_advance): Likewise.
* config/i386/i386.c (ix86_function_arg_advance): Likewise.
(ix86_function_arg, ix86_pass_by_reference): Likewise.
(ix86_setup_incoming_varargs): Likewise.
* config/sh/sh.c (sh_setup_incoming_varargs): Likewise.
(sh_strict_argument_naming): Likewise.
(sh_pretend_outgoing_varargs_named, sh_pass_by_reference): Likewise.
(sh_callee_copies, sh_arg_partial_bytes): Likewise.
(sh_function_arg_advance, sh_function_arg): Likewise.
* config/pdp11/pdp11.c (pdp11_function_arg): Likewise.
(pdp11_function_arg_advance): Likewise.
* config/microblaze/microblaze.c (microblaze_function_arg_advance):
Likewise.
(microblaze_function_arg, function_arg_partial_bytes): Likewise.
* config/avr/avr.c (avr_function_arg): Likewise.
(avr_function_arg_advance): Likewise.
* config/xtensa/xtensa.c (xtensa_function_arg_advance): Likewise.
(xtensa_function_arg, xtensa_function_incoming_arg): Likewise.
(xtensa_function_arg_1): Likewise.
* config/stormy16/stormy16.c (xstormy16_function_arg_advance)

[Bug target/49398] [4.7 Regression] bootstrap broken for arm-linux-gnueabi with thumb mode.

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  2011-06-16 
13:51:20 UTC ---
Author: ramana
Date: Thu Jun 16 13:51:17 2011
New Revision: 175104

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

Revert r174940

Fix PR target/49398



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/ldmstm.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr40457-1.c
trunk/gcc/testsuite/gcc.target/arm/pr40457-2.c
trunk/gcc/testsuite/gcc.target/arm/pr40457-3.c

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

[rth at gcc dot gnu.org]

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

--- Comment #29 from Richard Henderson  2011-06-16 
13:54:45 UTC ---
Works For Me.

[rth@anchor bld-avr-46]$ size avr/avr25/libgcc/_lshrdi3.o
   text   databssdechexfilename
244  0  0244 f4   
avr/avr25/libgcc/_lshrdi3.o

[Bug c/49428] Wrong FP calculation that yields 0.0.

[ecologicyborg at gmail dot com]

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

--- Comment #2 from ecologicyborg at gmail dot com 2011-06-16 14:31:28 UTC ---
2011/6/16 rguenth at gcc dot gnu.org 

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49428
>
> Richard Guenther  changed:
>
>   What|Removed |Added
>
> 
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
> --- Comment #1 from Richard Guenther 
> 2011-06-16 08:51:35 UTC ---
> Well, properly return uint64_t from rdtsc ... otherwise you only get the
> lower bits.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

Thanks Richard Guentner, damn my error due to that i did rewrite rdtsc
because
extern "C" was not recognized by the C compiler. Damn, damn.

[Bug fortran/48887] [OOP] SELECT TYPE: Associate name shall not be a pointer/allocatable

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-06-16 14:32:38 UTC ---
Note: Apparenty "select_type_23.f03" in the testsuite is invalid due to this PR
(cf. PR 48699).

[Bug java/49441] New: @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

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

   Summary: @LDLIBICONV@ lost from installed libgcj.spec
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Both current gcc trunk and gcc-4_6-branch no longer properly set @LDLIBICONV@
in the installed libgcj.spec. The odd part is that the libgcj.spec generated in
the build directory shows @LDLIBICONV@ expanded...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj-L/sw/lib -liconv-lz
%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}  %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions

whereas the installed copy is missing the "-L/sw/lib -liconv"...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj-lz
%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}  %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions

I suspect this is caused by...


r169822 | rwild | 2011-02-04 00:51:57 -0500 (Fri, 04 Feb 2011) | 12 lines

Fix PR java/21206: Unrecognized option '-Wl,-rpath' for jv-convert

libjava/:
PR java/21206
* configure.ac (LDLIBICONV): New substituted variable, with
instances of '-Wl,' removed from LIBICONV.
* configure: Regenerate.
* libgcj.spec.in: Use @LDLIBICONV@ not @LIBICONV@.
* Makefile.in: Regenerate.
* gcj/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.

[Bug tree-optimization/49442] New: [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

   Summary: [4.5/4.6/4.7 Regression] Misaligned store support
pessimization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: i...@gcc.gnu.org, revit...@gcc.gnu.org
Target: x86_64-linux


__attribute__((noinline, noclone))
void baz (double *out1, double *out2, double *out3, double *in1, double *in2,
int len)
{
  for (int i = 0; i < len; ++i)
{
  out1[i] = in1[i] * in2[i];
  out2[i] = in1[i] + in2[i];
  out3[i] = in1[i] - in2[i];
}
}

double a[5] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 50; i++)
baz (a + 0, a + 1, a + 2, a + 3, a + 4, 1);
  return 0;
}

is measurably slower in 4.6 compared to 4.4 with -m64 -O3 -mtune=generic,
apparently starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148211
at least on Intel CPUs.
with r148210:
Strip out best and worst realtime result
minimum: 6.603036509 sec real / 0.86529 sec CPU
maximum: 6.720307841 sec real / 0.000159148 sec CPU
average: 6.629486345 sec real / 0.000133896 sec CPU
stdev  : 0.024886889 sec real / 0.20014 sec CPU
with r148211:
Strip out best and worst realtime result
minimum: 6.969550715 sec real / 0.72647 sec CPU
maximum: 7.564913575 sec real / 0.000162211 sec CPU
average: 7.192333688 sec real / 0.000135634 sec CPU
stdev  : 0.101616835 sec real / 0.22659 sec CPU

[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with "illegal instruction"

[gcc.gnu.org at stellar dot eclipse.co.uk]

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

--- Comment #5 from Joe Stroller  
2011-06-16 15:10:30 UTC ---
(In reply to comment #4)
> Does this solve your problem?

Yes! Thank you, Mikael, and apologies for not testing sooner.

The fix in attachment 24326 works perfectly.

I tested it on gcc 4.5.2, and the "if" that is changed is at line 509 on that
version, but the structure is exactly the same. 

Now:

# echo | gcc -dM -E - -march=native gcc -v -Q --help=target -march=native 2>&1
| grep march
 /usr/libexec/gcc/i586-pc-linux-gnu/4.5.2/cc1 -E -v help-dummy
-D_FORTIFY_SOURCE=2 -march=k6-3 --param l1-cache-size=32 --param
l1-cache-line-size=32 --param l2-cache-size=128 -mtune=k6 -fhelp=target -dM
  -march=   k6-3
# cc -march=native -E -v - &1 | grep cc1
 /usr/libexec/gcc/i586-pc-linux-gnu/4.5.2/cc1 -E -quiet -v -
-D_FORTIFY_SOURCE=2 -march=k6-3 --param l1-cache-size=32 --param
l1-cache-line-size=32 --param l2-cache-size=128 -mtune=k6
#

Additionally I have recompiled my whole system with -march=native, and it is
working perfectly.

I would be very grateful if this were able to be incorporated into gcc.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.16 15:23:05
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-16 
15:23:05 UTC ---
Does -mtune=barcelona improve it?  What Intel CPUs?  I suppose the vectorizer
cost model could be adjusted for -mtune=generic?  I suppose the old rev.
is equivalent to -fno-tree-vectorize?

On AMD K8 I get

38.26user 0.12system 0:38.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

with vectorization and

31.09user 0.08system 0:31.21elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

without.  With -mtune=barcelona I get

37.08user 0.20system 0:37.39elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

and the following with native tuning

32.93user 0.25system 0:33.20elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

(movlpd instead of movsd and incl instead of add difference to generic only).
So, confirmed on AMD K8 as well.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.5.4

[Bug other/49435] get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.16 15:31:07
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-16 
15:31:07 UTC ---
Please provide preprocessed source as a testcase.

[Bug middle-end/49439] [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||hubicka at gcc dot gnu.org
 Resolution|DUPLICATE   |
   Target Milestone|--- |4.7.0

--- Comment #2 from H.J. Lu  2011-06-16 15:44:43 
UTC ---
This is a new regression introduced by revision 175021:

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

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[marc.glisse at normalesup dot org]

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

--- Comment #24 from Marc Glisse  2011-06-16 
15:59:11 UTC ---
(In reply to comment #21)
> Hmm, looks like I need to delay evaluation of noexcept for implicitly declared
> functions, too.

Hello,

just to confirm: this has solved for us all the problems that appeared when
libstdc++ started using noexcept, thank you.

[Bug middle-end/49439] [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed to build

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-06-16 
16:07:46 UTC ---
Well, it just expose the previously latent problem.  I will take a look into
the partitioning code...

[Bug tree-optimization/49443] New: gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[sje at cup dot hp.com]

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

   Summary: gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on
IA64 after testsuite change
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: i...@il.ibm.com
Target: ia64-*-*


This Change:

r175009 | irar | 2011-06-14 00:00:37 -0700 (Tue, 14 Jun 2011) | 12 lines


* gcc.dg/vect/vect-16.c: Rename to...
* gcc.dg/vect/no-fast-math-vect16.c: ...this.
* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
for double-word vectors.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/bb-slp-10.c: Replace vect_hw_misalign with
vect_element_align.
* gcc.dg/vect/vect.exp: Run no-fast-math-* tests with

Caused gcc.dg/vect/vect-peel-3.c and gcc.dg/vect/vect-peel-4.c to
start failing on the ia64-*-* platforms (HP-UX and Linux).


FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/vect/vect-peel-4.c -flto scan-tree-dump-times vect "vectorized 1
loops" 1

[Bug tree-optimization/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-06-16 16:13:42 
UTC ---
Created attachment 24547
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24547
Dump file with vectorize details

Dump file from vect-peel-3.c when run with

-ftree-vectorize -fno-vect-cost-model -O2 -fdump-tree-vect-details

[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures

[eraman at google dot com]

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

--- Comment #8 from Easwaran Raman  2011-06-16 
16:27:44 UTC ---
Compiling x.c with a ia64-unknown-linux cross compiler, setting a breakpoint in
can_escape(), I see that,


(gdb) p debug_rtx (body)
(set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
(reg:DI 112 in0))

This is part of an instruction that gets removed:
(insn 4 3 6 2 (set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
(reg:DI 112 in0)) y.c:23 5 {movdi_internal}
 (expr_list:REG_DEAD (reg:DI 112 in0)
(nil)))

(gdb) p expr->base.code 
$24 = PARM_DECL
(gdb) p may_be_aliased (expr)
$23 = 0 '\000'

So can_escape() returns false. But later on, in the same BB, I see:


(insn 36 30 37 2 (set (reg:DI 120 out0)
(reg/f:DI 357)) 5 {movdi_internal}
 (expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
(const_int 62 [0x3e]))
(nil)))
(insn 37 36 38 2 (set (reg:DI 121 out1)
(reg/f:DI 341)) 5 {movdi_internal}
 (expr_list:REG_DEAD (reg/f:DI 341)
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
(const_int 96 [0x60]))
(nil
(insn 38 37 39 2 (set (reg:DI 122 out2)
(const_int 31 [0x1f])) 5 {movdi_internal}
 (nil))
(call_insn 39 38 42 2 (parallel [
(set (reg:DI 8 r8)
(call (mem:DI (symbol_ref:DI ("memcpy") [flags 0x41] 
) [0 memcpy S8 A64])
(const_int 1 [0x1])))
(clobber (reg:DI 320 b0))
(clobber (scratch:DI))
(clobber (scratch:DI))
]) 332 {call_value_gp}
 (expr_list:REG_DEAD (reg:DI 122 out2)
(expr_list:REG_DEAD (reg:DI 121 out1)
(expr_list:REG_DEAD (reg:DI 120 out0)
(expr_list:REG_UNUSED (reg:DI 8 r8)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:DI 122 out2))
(expr_list:REG_DEP_TRUE (use (reg:DI 121 out1))
(expr_list:REG_DEP_TRUE (use (reg:DI 120 out0))
(nil))

reg 341 is passed as source argument of a memcpy. Why does the expression
return 0 for may_be_aliased()?

[Bug fortran/49438] error during make

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-06-16 16:31:23 UTC ---
(In reply to comment #0)
> Created attachment 24545 [details]
> config.log
> 
> make ends with 
> 
> checking whether the GNU Fortran compiler is working... no
> configure: error: GNU Fortran is not working; please report a bug in
> http://gcc.gnu.org/bugzilla, attaching
> /home/e.ab/software/src/gcc-4.5.3-build/i686-pc-linux-gnu/libgfortran/config.log
> make[1]: *** [configure-target-libgfortran] Error 1
> make[1]: Leaving directory `/data1/software/src/gcc-4.5.3-build'
> make: *** [all] Error 2
> 

What is the configure command line you used to configure
the gcc?

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-06-16 
16:33:16 UTC ---
I was testing on SandyBridge, but it was reported to us for Core2.
The loop used to be vectorized in 4.4 and is now too, in both cases it does a
huge hard to decipher test with many conditions and either uses non-vectorized
loop or vectorized loop.  In the r148210 condition was also:
  vect_p.44_29 = (vector double *) out1_6(D);
  addr2int0.45_28 = (long int) vect_p.44_29;
  vect_p.48_37 = (vector double *) out2_21(D);
  addr2int1.49_38 = (long int) vect_p.48_37;
  orptrs1.50_40 = addr2int0.45_28 | addr2int1.49_38;
  vect_p.53_41 = (vector double *) out3_34(D);
  addr2int2.54_42 = (long int) vect_p.53_41;
  orptrs2.55_51 = orptrs1.50_40 | addr2int2.54_42;
  andmask.56_52 = orptrs2.55_51 & 15;
...
  D.2833_72 = andmask.56_52 == 0;
but in the new condition is not, and previously it used movaps stores in the
loop:
movapd%xmm0, (%rdi,%r10)
...
movapd%xmm0, (%rsi,%r10)
...
movapd%xmm0, (%rdx,%r10)
while newly it uses:
movlpd%xmm0, (%rdi,%rbx)
movhpd%xmm0, 8(%rdi,%rbx)
...
movlpd%xmm0, (%rsi,%rbx)
movhpd%xmm0, 8(%rsi,%rbx)
...
movlpd%xmm0, (%rdx,%rbx)
movhpd%xmm0, 8(%rdx,%rbx)

Surprisingly, the new code is slower even when the pointers aren't aligned:
r128110:
Strip out best and worst realtime result
minimum: 8.849950347 sec real / 0.85810 sec CPU
maximum: 9.278652529 sec real / 0.000153471 sec CPU
average: 9.055898562 sec real / 0.000138755 sec CPU
stdev  : 0.073603342 sec real / 0.16469 sec CPU
r128111:
Strip out best and worst realtime result
minimum: 12.089365836 sec real / 0.81233 sec CPU
maximum: 12.378188295 sec real / 0.000158253 sec CPU
average: 12.234883839 sec real / 0.000136920 sec CPU
stdev  : 0.073461527 sec real / 0.17463 sec CPU
(same baz routine, and
double a[6] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 50; i++)
baz (a + 1, a + 10001, a + 3, a + 4, a + 5, 1);
  return 0;
}
instead).  Here, in r128110 generated code it uses the scalar loop, while in
r128111 it uses the vectorized one with those movlpd+movhpd stores.
So in this particular case for this particular CPU, it would be better if the
cost model said that it should verify whether all store pointers are
sufficiently aligned and only use the vectorized loop in that case.

BTW, the vectorization condition is really long, is it a good idea to let it go
through with just a single branch at the end?  Wouldn't it be better to test
several most likely to fail checks first, conditional branch, then some other
tests, again conditional branch?

I've talked with Richard on IRC about how users could promise the compiler
that the pointers are sufficiently aligned and thus it can just assume it is
aligned (if it would test for it) and use it in the loop, both for loads and
stores.  Possibilities include __attribute__((ptr_align (align [, misalign])))
on const pointer parameters and const pointer variables, or adding
__builtin_unreachable () using assertions.

But now that I think about it more, we already version the loop for
vectorization in this case, wouldn't it be better to just add some extension
which would allow the user to say something is likely?  Such hint could be
e.g. hint that some pointer is likely to be so and so aligned/misaligned,
or e.g. that pointers don't overlap (yeah, I know, we have restrict, but
e.g. on STL containers it is more fun to add those)?

E.g. if this loop was hinted that all 5 pointers are 16 byte aligned and
that neither in1[0..len-1] nor in2[0..len-1] overlap out{1,2,3}[0..len-1], the
vectorizer could verify those conditions at runtime and use an correct
alignment
and __restrict assuming faster vectorized loop, while for the fallback case
(vectorization not beneficial, or some overlaps somewhere, or misaligned
pointers) would be a scalar loop not assuming anything of that.
Or perhaps the hints could tell the vectorizer to emit 3 different versions
instead of two, each with different assumptions or something similar.

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #3 from kargl at gcc dot gnu.org 2011-06-16 16:34:29 UTC ---
See comments #1 and #2.  Closing as WONTFIX.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org,
   ||tromey at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #1 from Rainer Orth  2011-06-16 16:59:31 UTC 
---
After some further debugging, I could reproduce the issue with the following
testcase:

class arraycopy {
public static void main(String[] argv) {
String src = "a";
byte dst[] = new byte[64];

System.arraycopy (src.getBytes(), 0, dst, 0, src.length());
}
}

With some debug code in java/lang/natSystem.cc (java::lang::System::arraycopy),
I get

arraycopy: src_offset = 0 src_a->length = 0
   dst_offset = 0 dst_a->length = 64
   count = 1
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
   at java.lang.System.arraycopy(Unknown Source)
   at arraycopy.main(Unknown Source)

I haven't yet found where src_a->length is supposed to be initialized.  Any
suggestions?

  Rainer

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at google dot com]

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

--- Comment #27 from Easwaran Raman  2011-06-16 
17:14:38 UTC ---
(In reply to comment #26)
> On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> > 
> > davidxl  changed:
> > 
> >What|Removed |Added
> > 
> >  CC||xinliangli at gmail dot com
> > 
> > --- Comment #23 from davidxl  2011-06-15 
> > 23:14:50 UTC ---
> > (In reply to comment #22)
> > > > The DSE patch still leaves 2 redundant stores.
> > > 
> > > OK, I missed this, reopening...
> > > 
> > > > The following patch will enable DSE to remove those two stores. Does 
> > > > this
> > > > look ok?
> > > 
> > > Calling into the gimplifier from the RTL expander doesn't look 
> > > appropriate.
> 
> It also should use create_tmp_var, not create_tmp_reg.  But I wonder why
> memory allocated via assign_temp isn't marked in a way to let dse
> do its job (I guess dse thinks that memory escapes?).
If the mem rtx doesn't have a tree_expression associated with it, DSE assumes
the memory escapes.

> 
> > > More fundamentally, it's a little unfortunate to spill to memory a value
> > > returned in registers.  Can we try to use emit_group_move_into_temps here
> > > instead (under the appropriate circumstances)?
> > 
> > It would be nice if the expander does not spill the return into memory in 
> > the
> > first place if possible.  On other hand tagging compiler created memory
> > location with temp decls so that aliaser has the symbolic information seems 
> > a
> > useful mechanism. 
> 
> Sure - but I wonder why assign_temp doesn't do something equivalent
> that doesn't require a automatic VAR_DECL to be created.
> 
> Where does the aliaser catch things with the VAR_DECL around that
> it doesn't without it?

Is it just that when I create a VAR_DECL, TREE_ADDRESSABLE is false and
may_be_aliased returns true?

> Richard.

[Bug ada/42974] Array slice assignment is missing bounds checking for the source array

[tero.koskinen at iki dot fi]

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

Tero Koskinen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Tero Koskinen  2011-06-16 
17:18:12 UTC ---
This is fixed in GCC 4.6.0 and GNAT GPL 2011.

I don't know which commit fixed this, but I can no longer repeat the problem
with 4.6.0 or GPL 2011.

Resolving as FIXED.

[Bug target/26883] ICE when assigning memory attribute to class with simple constructor

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #3 from Georg-Johann Lay  2011-06-16 
17:24:03 UTC ---
This is similar to PR44643. avr backend now rejects such code with an error
instead of trying to set TREE_READONLY when not appropriate.

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

[Bug target/44643] ice in c-typeck.c

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||n...@bike-nomad.com

--- Comment #13 from Georg-Johann Lay  2011-06-16 
17:24:03 UTC ---
*** Bug 26883 has been marked as a duplicate of this bug. ***

[Bug fortran/49438] error during make

[eisoab at gmail dot com]

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

--- Comment #3 from eisoab at gmail dot com 2011-06-16 17:36:15 UTC ---
kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49438
>
> kargl at gcc dot gnu.org changed:
>
> What|Removed |Added
> 
>   CC||kargl at gcc dot gnu.org
>
> --- Comment #2 from kargl at gcc dot gnu.org 2011-06-16 16:31:23 UTC ---
> (In reply to comment #0)
>
>> Created attachment 24545 [details]
>> config.log
>>
>> make ends with
>>
>> checking whether the GNU Fortran compiler is working... no
>> configure: error: GNU Fortran is not working; please report a bug in
>> http://gcc.gnu.org/bugzilla, attaching
>> /home/e.ab/software/src/gcc-4.5.3-build/i686-pc-linux-gnu/libgfortran/config.log
>> make[1]: *** [configure-target-libgfortran] Error 1
>> make[1]: Leaving directory `/data1/software/src/gcc-4.5.3-build'
>> make: *** [all] Error 2
>>
>>  
> What is the configure command line you used to configure
> the gcc?
>
>
nothing. just ../configure

there was a gmp version on the machine that was too old and no mpfr

I unpacked the latest source tar files of gmp and mpfr in  the
source directory (gcc-4.5.3) hoping that they would be found an installed.

But after make distclean  ;  ../gcc-4.5.3/configure
make  ends with the same error as before. (although i didn't compare the 
config.log
it was overwritten)

I'm now first installing gmp and mpfr by hand.
I probably have to remove the old gmp version right?


Eiso

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey  2011-06-16 17:44:03 
UTC ---
(In reply to comment #1)

> I haven't yet found where src_a->length is supposed to be initialized.  Any
> suggestions?

It is set when the array is created.
I would suggest stepping through String::getBytes.

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.16 17:51:22
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2011-06-16 17:51:22 UTC ---
Slightly reduced test case:


module foo

  type bar
  contains
generic :: assignment (=) => assgn
procedure :: assgn
  end type

contains

  elemental subroutine assgn (a, b)
class (bar), intent (inout) :: a
class (bar), intent (in) :: b
  end subroutine

end module

  use foo
  type (bar) :: foobar(2)
  foobar = bar()
end

[Bug fortran/49438] error during make

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-06-16 17:52:39 UTC ---
On Thu, Jun 16, 2011 at 05:36:35PM +, eisoab at gmail dot com wrote:
> 
> > What is the configure command line you used to configure
> > the gcc?
> >
> >
> nothing. just ../configure
> 

This appears to mean that you are trying to build
gcc within its source tree.  That is not support.
Please the instructions for building gcc.

>
> I probably have to remove the old gmp version right?
> 

This would certainly ensure that the old versions are
not found and used.

[Bug fortran/49438] error during make

[eisoab at gmail dot com]

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

--- Comment #5 from eisoab at gmail dot com 2011-06-16 17:56:10 UTC ---
sgk at troutmask dot apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49438
>
> --- Comment #4 from Steve Kargl  
> 2011-06-16 17:52:39 UTC ---
> On Thu, Jun 16, 2011 at 05:36:35PM +, eisoab at gmail dot com wrote:
>>
>>> What is the configure command line you used to configure
>>> the gcc?
>>>
>>>
>> nothing. just ../configure
sorry that was incorrect, I meant

../gcc-4.5.3/configure

I'm using a gcc-4.5.3-build dir next to gcc-4.5.3

Eiso

>>
>
> This appears to mean that you are trying to build
> gcc within its source tree.  That is not support.
> Please the instructions for building gcc.
>
>>
>> I probably have to remove the old gmp version right?
>>
>
> This would certainly ensure that the old versions are
> not found and used.
>

[Bug middle-end/45098] Missed induction variable optimization

[vries at gcc dot gnu.org]

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

--- Comment #16 from vries at gcc dot gnu.org 2011-06-16 17:57:12 UTC ---
Author: vries
Date: Thu Jun 16 17:57:08 2011
New Revision: 175105

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175105
Log:
2011-06-16  Tom de Vries  

PR target/45098
* tree-ssa-loop-niter.c (infer_loop_bounds_from_pointer_arith): Disallow
NULL pointer for pointer arithmetic.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug middle-end/45098] Missed induction variable optimization

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org 2011-06-16 18:00:57 UTC ---
Author: vries
Date: Thu Jun 16 18:00:54 2011
New Revision: 175106

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175106
Log:
2011-06-16  Tom de Vries  

PR target/45098
* gcc.target/arm/ivopts-3.c: Update test.
* gcc.target/arm/ivopts-5.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/ivopts-3.c
trunk/gcc/testsuite/gcc.target/arm/ivopts-5.c

[Bug fortran/49438] error during make

[eisoab at gmail dot com]

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

--- Comment #6 from eisoab at gmail dot com 2011-06-16 18:07:41 UTC ---
Eiso AB wrote:
> sgk at troutmask dot apl.washington.edu wrote:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49438
>>
>> --- Comment #4 from Steve Kargl> apl.washington.edu> 2011-06-16 17:52:39 UTC ---
>> On Thu, Jun 16, 2011 at 05:36:35PM +, eisoab at gmail dot com wrote:
>>>
 What is the configure command line you used to configure
 the gcc?


>>> nothing. just ../configure
> sorry that was incorrect, I meant
>
> ../gcc-4.5.3/configure
>
> I'm using a gcc-4.5.3-build dir next to gcc-4.5.3
>
> Eiso
>
>>>
>>
>> This appears to mean that you are trying to build
>> gcc within its source tree. That is not support.
>> Please the instructions for building gcc.
>>
>>>
>>> I probably have to remove the old gmp version right?
>>>
>>
>> This would certainly ensure that the old versions are
>> not found and used.

yum wants to remove about 60 packages when I try that. So I
think I'll leave that one alone.

-E



>>
>

[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-06-16 
18:18:55 UTC ---
Created attachment 24548
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24548
gcc47-vrp.patch

So, I've tried this patch for extract_range_from_assert.
It bootstrapped/regtested on x86_64-linux and i686-linux, but regressed
FAIL: g++.dg/tree-ssa/pr18178.C scan-tree-dump-times vrp1 "if " 1
(just the vrp1 dump checking and code removal, the assembly is the same at the
end).
The VR is just different (- is vanilla, + is with the patch).
 Value ranges after VRP:

-i_1: [0, +INF(OVF)]
+i_1: [0, +INF]
 a_3(D): VARYING
 D.2084_4: VARYING
 D.2090_7: VARYING
@@ -681,10 +927,10 @@ D.2094_11: VARYING
 i_12: [1, +INF(OVF)]
 D.2077_13: VARYING
 .MEM_14: VARYING
-i_19: [-INF, D.2084_4 + -1]  EQUIVALENCES: { i_1 } (1 elements)
-i_20: [0, +INF]  EQUIVALENCES: { i_1 i_19 } (2 elements)
+i_19: [0, +INF]  EQUIVALENCES: { } (0 elements)
+i_20: [0, +INF]  EQUIVALENCES: { i_19 } (1 elements)
 a_21: ~[0B, 0B]  EQUIVALENCES: { a_3(D) } (1 elements)
-D.2084_22: [i_19 + 1, +INF]  EQUIVALENCES: { D.2084_4 } (1 elements)
+D.2084_22: [1, +INF]  EQUIVALENCES: { D.2084_4 } (1 elements)
 D.2077_23: ~[0B, 0B]  EQUIVALENCES: { D.2077_13 } (1 elements)

but resulted in:
 Folding statement: if (i_20 >= D.2084_22)
-Folding predicate i_20 >= D.2084_22 to 0
-Folded into: if (0 != 0)
-
+Not folded

So, not sure if I should push this anyway (with adjusting/removing the
testcase), or not.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-16 18:18:59 UTC ---
> It is set when the array is created.
> I would suggest stepping through String::getBytes.

When I do this, I find that the count argument to _Jv_NewPrimArray is
0.  It is read in natString.cc:

jbyteArray java::lang::String::getBytes (jstring enc)

which calls String.java (public int length()).  This just return the
count member.  I couldn't find so far where this is initialized for the
static string src.

Rainer

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org 2011-06-16 18:24:15 UTC ---
Ok, in fact we just fail to propagate the locus when replacing the assignment
with the corresponding type-bound call. The following one-liner fixes it:


Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 175100)
+++ gcc/fortran/interface.c(working copy)
@@ -3242,6 +3242,7 @@ gfc_extend_assign (gfc_code *c, gfc_namespace *ns)
   c->expr1 = gfc_get_expr ();
   build_compcall_for_operator (c->expr1, actual, tb_base, tbo, gname);
   c->expr1->value.compcall.assign = 1;
+  c->expr1->where = c->loc;
   c->expr2 = NULL;
   c->op = EXEC_COMPCALL;


With this one gets the correct error message:

foobar = [bar(1), bar(2)]
 1
Error: Non-scalar base object at (1) currently not implemented


Will commit as obvious after regtesting.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[tromey at gcc dot gnu.org]

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

--- Comment #4 from Tom Tromey  2011-06-16 18:57:35 
UTC ---
(In reply to comment #3)
> I couldn't find so far where this is initialized for the
> static string src.

It has been a while, but I think either _Jv_NewStringUTF
or _Jv_NewStringUtf8Const.  IIRC one of these is run
during class initialization to turn string constants into
String objects.

[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2011-06-16 
19:37:44 UTC ---
Author: jamborm
Date: Thu Jun 16 19:37:37 2011
New Revision: 175109

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175109
Log:
2011-06-16  Martin Jambor  

PR tree-optimization/48613
* ipa-prop.c (ipa_prop_write_jump_functions): Return immediately if
ipa_node_params_vector is NULL.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/ipa-prop.c

[Bug fortran/49213] [OOP][F2008] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.16 19:43:45
Summary|[OOP] gfortran rejects  |[OOP][F2008] gfortran
   |structure constructor   |rejects structure
   |expression  |constructor expression
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2011-06-16 19:43:45 UTC ---
Note: Intrinsic assignments to polymorphic variables are forbidden in the
Fortran 2003 standard, and currently not supported by gfortran, cf. PR 43366.

F03:7.4.1.2:
"In an intrinsic assignment statement, variable shall not be polymorphic, and
..."

[Bug tree-optimization/49444] New: IV-OPTs changes an unaligned loads into aligned loads incorrectly

[pinskia at gcc dot gnu.org]

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

   Summary: IV-OPTs changes an unaligned loads into aligned loads
incorrectly
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Take:
/* { dg-do compile { target mips*-*-* } } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler "uld\\t|ldr\\t|lwr\\t" } } */


struct s
{
  unsigned int l;
  unsigned int z[2];
};

struct r
{
  char c;
  struct s s;
} __attribute__ ((packed));

struct s *ss;

f (struct r *p, int l)
{
  int i;
  for (i = 0; i < l; i++)
{
  *ss = p[i].s;
  g ();
}
}
--- CUT ---
Currently this fails and the load from p[i].s is turned into an aligned load.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP][F2008] gfortran   |[OOP] gfortran rejects
   |rejects structure   |structure constructor
   |constructor expression  |expression

--- Comment #2 from janus at gcc dot gnu.org 2011-06-16 19:49:33 UTC ---
(In reply to comment #1)
> Note: Intrinsic assignments to polymorphic variables are forbidden in the
> Fortran 2003 standard, and currently not supported by gfortran, cf. PR 43366.


However, the same error message appears for the following variant (with a
defined assignment), which is valid according to F03:


module m

  type :: S
integer :: n
  contains
generic :: assignment (=) => assgn
procedure :: assgn
  end type

  type :: T
class(S), allocatable :: x
  end type

contains

  subroutine assgn (a, b)
class (S), intent (inout) :: a
class (S), intent (in) :: b
  end subroutine

end module


  use m
  type(S) :: Sobj
  type(T) :: Tobj

  Sobj = S(1)
  Tobj = T(Sobj)

end program 



  Tobj = T(Sobj)
   1
Error: Can't convert TYPE(s) to CLASS(s) at (1)

[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-06-16 
20:08:43 UTC ---
Well, I'm 100% sure this is just the age-old bug that GCC can't expand
misaligned indirect-refs (or nowadays mem-refs and target-mem-refs) on
strict-align targets properly.

Try the following on any GCC version:

typedef int myint __attribute__((aligned(1)));

int foo(myint *p)
{
  return *p;
}
int main()
{
  char c[5] = {};
  return foo(&c[1]);
}

it'll fault on any strict-align target since forever.  Now it would
indeed be nice if _finally_ somebody would go and fix that ...

Dup of 

[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-06-16 
20:16:09 UTC ---
(In reply to comment #1)
> Well, I'm 100% sure this is just the age-old bug that GCC can't expand
> misaligned indirect-refs (or nowadays mem-refs and target-mem-refs) on
> strict-align targets properly.

This has nothing to do with the misalgined indirect-ref issue as it works when
IV-opts is disabled.

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

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

Ryan Mansfield  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ryan Mansfield  2011-06-16 
20:17:00 UTC ---
(In reply to comment #2)
> I don't see this with an arm-linux-gnu toolchain for r163798.

Were you using a 64 bit host?

   8486   if (immtype == 17)
   8487 {
   8488   /* FIXME: Broken on 32-bit H_W_I hosts.  */
   8489   gcc_assert (sizeof (HOST_WIDE_INT) == 8);
   8490 
   8491   for (i = 0; i < 8; i++)


I can still reproduce this with trunk, and there's a FIXME with a note about
this bug. Can this PR be moved out of WAITING, or is there some other
information I need to provide?

[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

--- Comment #6 from Martin Jambor  2011-06-16 
20:21:24 UTC ---
Author: jamborm
Date: Thu Jun 16 20:21:21 2011
New Revision: 175111

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175111
Log:
2011-06-16  Martin Jambor  

PR tree-optimization/49343
* tree-sra.c (build_ref_for_model): Use component_ref_field_offset to
calculate offset, provide 2nd operand for the new COMPONENT_REF.

* testsuite/gnat.dg/discr31.adb: New test.
* testsuite/gnat.dg/discr31.ads: Likewise.


Added:
trunk/gcc/testsuite/gnat.dg/discr31.adb
trunk/gcc/testsuite/gnat.dg/discr31.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug libstdc++/49445] New: Undefined reference to std::atomic "operator float"

[raskolnikov at gnu dot org]

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

   Summary: Undefined reference to std::atomic "operator
float"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: raskolni...@gnu.org


Hello,

It looks like std::atomic does is not fully implemented. I get an
undefined reference to its operator float:

libtool: link: g++ -Wall -I/usr/include -I../../src -I../../src -g -O2
-std=c++0x -DNDEBUG -o .libs/psynth_unit_test
psynth_unit_test-psynth_unit_test.o [... a big list of object files ...]
-L/usr/lib64 -lboost_unit_test_framework-mt -lboost_filesystem-mt
-lboost_signals-mt -lboost_system-mt ../psynth/.libs/libpsynth.so -Wl,-rpath
-Wl,/home/raskolnikov/usr/lib

../psynth/.libs/libpsynth.so: undefined reference to 
   `atomic::operator float() const'

A similar bug happened when I tried std::atomic with "my_enum" being a
"enum class my_enum : int", I got an undefined reference to the "store ()"
method instead.

I am using GCC 4.6 as included in Debian Sid:

  g++ --version
  g++ (Debian 4.6.0-13) 4.6.1 20110611 (prerelease)

  apt-cache show libstdc++6-4.6-dev
  Package: libstdc++6-4.6-dev
  Source: gcc-4.6
  Version: 4.6.0-13

Anyways, thanks a lot for your hard work implementing C++11 :)

JP

[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Martin Jambor  2011-06-16 
20:29:02 UTC ---
Fixed.

[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|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Martin Jambor  2011-06-16 
20:30:04 UTC ---
Fixed.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

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

--- Comment #3 from neil.n.carlson at gmail dot com 2011-06-16 20:35:48 UTC ---
(In reply to comment #1)
> Note: Intrinsic assignments to polymorphic variables are forbidden [...]

This was really about the structure constructor; the assignment was
just to do something with the value, so the example was poor.  Here's
a slightly different version that gets to the heart of what I intended:

program main

  type :: S
integer :: n
  end type
  type(S) :: Sobj

  type, extends(S) :: S2
integer :: m
  end type
  type(S2) :: S2obj

  type :: T
class(S), allocatable :: x
  end type

  Sobj = S(1)
  call pass_it (T(Sobj))

  S2obj = S2(1,2)
  call pass_it (T(S2obj))

contains

  subroutine pass_it (foo)
type(T), intent(in) :: foo
  end subroutine

end program

This gives the same errors:

  call pass_it (T(Sobj))
  1
Error: Can't convert TYPE(s) to CLASS(s) at (1)

  call pass_it (T(S2obj))
  1
Error: Can't convert TYPE(s2) to CLASS(s) at (1)

[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2

[sje at gcc dot gnu.org]

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

--- Comment #2 from Steve Ellcey  2011-06-16 20:38:52 
UTC ---
Author: sje
Date: Thu Jun 16 20:38:49 2011
New Revision: 175112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175112
Log:
2011-06-16  Steve Ellcey  

PR testsuite/48727
* g++.dg/opt/devirt2.C: Change xfail rule to target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/devirt2.C

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

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

--- Comment #4 from neil.n.carlson at gmail dot com 2011-06-16 20:49:32 UTC ---
An intuitive way of viewing (and maybe even implementing I guess) the process
triggered by a structure constructor is as a sequence of assignment statements
for the components of the structure.  But that's not how the (2008) standard
describes what takes place, and so constraints that apply to assignments (like
assigning to a polymorphic) don't apply in this context.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-16 20:51:00 UTC ---
> It has been a while, but I think either _Jv_NewStringUTF
> or _Jv_NewStringUtf8Const.  IIRC one of these is run
> during class initialization to turn string constants into
> String objects.

Thanks.  It turned out those were ok.

When I logged calls to JvNewByteArray, I found two:

JvNewByteArray: length = 1
JvNewByteArray: length = 0

The first one is as expected for "a", the second seems fishy: at the end
of java::lang::String::getBytes, bufpos was 0 and buflen 1, so a new
empty buffer was returned.

Looking further, this is a problem with iconv somehow: in
gnu::gcj::convert::Output_iconv::write, iconv_adapter returns -1 with
errno == EILSEQ.  Not understanding this iconv business at all, I have
no idea how this can happen.

Rainer

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2011-06-16 21:07:00 UTC ---
On Thu, 16 Jun 2011, rmansfield at qnx dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
> 
> Ryan Mansfield  changed:
> 
>What|Removed |Added
> 
>  CC||ramana at gcc dot gnu.org
> 
> --- Comment #4 from Ryan Mansfield  2011-06-16 
> 20:17:00 UTC ---
> (In reply to comment #2)
> > I don't see this with an arm-linux-gnu toolchain for r163798.
> 
> Were you using a 64 bit host?
> 
>8486   if (immtype == 17)
>8487 {
>8488   /* FIXME: Broken on 32-bit H_W_I hosts.  */
>8489   gcc_assert (sizeof (HOST_WIDE_INT) == 8);

EABI targets force 64-bit HOST_WIDE_INT, so the vast majority of users of 
the ARM port won't hit this assert.  If you really care about old-ABI 
targets (and deprecation of arm-linux-gnu and arm-elf is long overdue), 
maybe ARM should just force 64-bit HOST_WIDE_INT unconditionally.

[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2011-06-16 
21:10:18 UTC ---
Something like this:
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c(revision 61384)
+++ tree-ssa-loop-ivopts.c(working copy)
@@ -6066,6 +6066,8 @@ rewrite_use_address (struct ivopts_data
   tree base_hint = NULL_TREE;
   tree ref, iv;
   bool ok;
+  unsigned align;
+  tree type;

   adjust_iv_update_pos (cand, use);
   ok = get_computation_aff (data->current_loop, use, cand, use->stmt, &aff);
@@ -6087,7 +6089,10 @@ rewrite_use_address (struct ivopts_data
 base_hint = var_at_stmt (data->current_loop, cand, use->stmt);

   iv = var_at_stmt (data->current_loop, cand, use->stmt);
-  ref = create_mem_ref (&bsi, TREE_TYPE (*use->op_p), &aff,
+  align = get_object_alignment (*use->op_p, BIGGEST_ALIGNMENT);
+  type = TREE_TYPE (*use->op_p);
+  type = build_aligned_type (type, align);
+  ref = create_mem_ref (&bsi, type, &aff,
 reference_alias_ptr_type (*use->op_p),
 iv, base_hint, data->speed);
   copy_ref_info (ref, *use->op_p);

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-06-16 21:29:07 UTC ---
(In reply to comment #4)
> An intuitive way of viewing (and maybe even implementing I guess) the process
> triggered by a structure constructor is as a sequence of assignment statements
> for the components of the structure.  But that's not how the (2008) standard
> describes what takes place, and so constraints that apply to assignments (like
> assigning to a polymorphic) don't apply in this context.

I think you are wrong here.

F08:7.2.1.3p13:

"An intrinsic assignment where the variable is of derived type is performed as
if each component of the variable were assigned from the corresponding
component of expr using pointer assignment (7.2.2) for each pointer component,
defined assignment for each nonpointer nonallocatable component of a type that
has a type-bound defined assignment consistent with the component, intrinsic
assignment for each other nonpointer nonallocatable component, and intrinsic
assignment for each allocated coarray component. For unallocated coarray
components, the corresponding component of the variable shall be unallocated.
For a noncoarray allocatable component the following sequence of operations is
applied."

In essence this means that a derived type assignment *is* viewed as a sequence
of component assignments. Therefore I think that the corresponding restrictions
*do* apply.

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-06-16 21:45:29 UTC ---
Author: janus
Date: Thu Jun 16 21:45:26 2011
New Revision: 175113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175113
Log:
2011-06-16  Janus Weil  

PR fortran/49074
* interface.c (gfc_extend_assign): Propagate the locus from the
assignment to the type-bound procedure call.

2011-06-16  Janus Weil  

PR fortran/49074
* gfortran.dg/typebound_assignment_3.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-06-16 21:49:28 UTC ---
r175113 fixes the problem on trunk. Is it worth backporting this to 4.6?

[Bug testsuite/49432] [4.7 Regression] FAIL: obj-c++.dg/invalid-type-1.mm

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-06-16 
21:55:36 UTC ---
The test passes with the following patch:

--- ../_clean/gcc/testsuite/obj-c++.dg/invalid-type-1.mm2010-11-19
18:12:20.0 +0100
+++ gcc/testsuite/obj-c++.dg/invalid-type-1.mm2011-06-16 23:49:20.0
+0200
@@ -18,8 +18,8 @@ id  object; /* This is fine.

 AClass  *object1; /* This is fine.  */

-Integer  *object2; /* { dg-error ".Integer. is not a template" }
*/
+Integer  *object2; /* { dg-error ".Integer .aka int.. is not a
template" } */
 /* { dg-error ".MyProtocol. was not declared in this scope" "" { target *-*-*
} 21 } */

-Integer  *object3; /* { dg-error ".Integer. is not a
template" } */
+Integer  *object3; /* { dg-error ".Integer .aka int.. is
not a template" } */
 /* { dg-error ".NonExistingProtocol. was not declared in this scope" "" {
target *-*-* } 24 } */

[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 #4 from Kazumoto Kojima  2011-06-16 
22:02:48 UTC ---
Author: kkojima
Date: Thu Jun 16 22:02:45 2011
New Revision: 175116

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175116
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.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49307.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/sh/sh.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug testsuite/49432] [4.7 Regression] FAIL: obj-c++.dg/invalid-type-1.mm

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #2 from Nicola Pero  2011-06-16 22:03:41 
UTC ---
Looks good ... you should submit the patch to gcc-patches ;-)

Thanks

[Bug c++/49420] [C++0x] compiler segfault using result_of

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-06-16 
22:05:52 UTC ---
Author: jason
Date: Thu Jun 16 22:05:46 2011
New Revision: 175117

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175117
Log:
PR c++/49420
* error.c (dump_template_argument): Don't try to omit default
template args from an argument pack.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic112.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog

[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 #5 from Kazumoto Kojima  2011-06-16 
22:08:23 UTC ---
Author: kkojima
Date: Thu Jun 16 22:08:20 2011
New Revision: 175118

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175118
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.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr49307.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/sh/sh.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[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

Kazumoto Kojima  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Kazumoto Kojima  2011-06-16 
22:10:25 UTC ---
Fixed.

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2011-06-16 
22:09:32 UTC ---
Author: jason
Date: Thu Jun 16 22:09:28 2011
New Revision: 175123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175123
Log:
PR c++/44160
* parser.c (cp_parser_lambda_body): Share code between
simple and complex cases instead of using cp_parser_function_body.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49229] [C++0x][SFINAE] ICE with variadics and depending non-type default parameter

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-06-16 
22:09:08 UTC ---
Author: jason
Date: Thu Jun 16 22:09:05 2011
New Revision: 175120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175120
Log:
PR c++/49229
* pt.c (tsubst_decl) [FUNCTION_DECL]: Handle substitution failure.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae26.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/45378] [C++0x] Narrowing error not detected

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-16 
22:09:25 UTC ---
Author: jason
Date: Thu Jun 16 22:09:20 2011
New Revision: 175122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175122
Log:
PR c++/45378
* decl.c (check_initializer): Check narrowing.

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