[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

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

--- Comment #31 from Michael Haubenwallner  2011-05-17 07:17:57 UTC ---
(In reply to comment #29)
> I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
> problem seems to persist with newer versions of gcc as well. I installed 
> gcc 4.4.6 today after having issues trying to build GNU barcode from source.
> gcc -v

> ld: 0711-596 SEVERE ERROR: Object main.o
>  An RLD for section 2 (.data) refers to symbol 944,
>  but the storage class of the symbol is not C_EXT or C_HIDEXT.

This most likely is bug#46072 comment#10, which is a subsequent AIX bug already
known to IBM (bug#46072 comment#18).

[Bug target/48986] Missed optimization in atomic decrement on x86/x64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2011-05-17 
07:43:33 UTC ---
Fixed on the trunk, on the 4.6 branch just small improvement for
__sync_add_and_fetch (p, -1) == 0.

[Bug target/48986] Missed optimization in atomic decrement on x86/x64

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-05-17 
07:42:38 UTC ---
Author: jakub
Date: Tue May 17 07:42:30 2011
New Revision: 173817

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173817
Log:
PR target/48986
* config/i386/sync.md (sync_old_add): Relax operand 2
predicate to allow CONST_INT.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/sync.md

[Bug target/48986] Missed optimization in atomic decrement on x86/x64

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-05-17 
07:38:03 UTC ---
Author: jakub
Date: Tue May 17 07:37:59 2011
New Revision: 173816

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173816
Log:
PR target/48986
* config/i386/sync.md (sync_old_add): Relax operand 2
predicate to allow CONST_INT.
(*sync_old_add_cmp): New insn and peephole2 for it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sync.md

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-05-17 
08:19:15 UTC ---
TREE_ADDRESSABLE is cleared by maybe_optimize_var during
execute_update_addresses_taken.  If the debug stmt contains just the VAR_DECL,
it will be renamed, but in this case it is MEM_REF and for some reason isn't
renamed in that case (if I manually change it to the VAR_DECL, it is).
Later on fold_stmt_1 on the debug stmt performs maybe_fold_reference and
optimizes the MEM_REF into the VAR_DECL and triggers the checking failure.
If maybe_fold_reference is used already when the DEBUG stmt is created, it will
be just a VAR_DECL and thus it will work, but not sure if that is the way we
want to go.

[Bug c/49012] weak const optimisations

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-05-17 
08:39:50 UTC ---
I suppose PR47278 might be related.

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-17 
09:40:20 UTC ---
(In reply to comment #4)
> TREE_ADDRESSABLE is cleared by maybe_optimize_var during
> execute_update_addresses_taken.  If the debug stmt contains just the VAR_DECL,
> it will be renamed, but in this case it is MEM_REF and for some reason isn't
> renamed in that case (if I manually change it to the VAR_DECL, it is).
> Later on fold_stmt_1 on the debug stmt performs maybe_fold_reference and
> optimizes the MEM_REF into the VAR_DECL and triggers the checking failure.
> If maybe_fold_reference is used already when the DEBUG stmt is created, it 
> will
> be just a VAR_DECL and thus it will work, but not sure if that is the way we
> want to go.

Hm, I thought we fold all debug stmts initially.  Probably update-address-taken
should handle debug-stmts in the if (update_vops) path similar to how it
handles other mem-refs.  But I suppose it would have to drop debug stmts
in case it cannot rewrite them(?)

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #6 from Janne Blomqvist  2011-05-17 09:32:18 
UTC ---
I suppose we could still use __builtin_fmod if -fno-signed-zeros is in effect.

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-05-17 
10:03:08 UTC ---
Not always, it is fine to keep say &a around even when a is no longer
addressable - then we emit is as (debug_implicit_ptr a).  So, if possible
ADDR_EXPR of the var should stay as is, but certainly what can be rewritten
should be.

[Bug tree-optimization/49018] New: Inline assembly block executed outside conditional check with "-O1 -ftree-vrp"

[ted at thereisnospork dot com]

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

   Summary: Inline assembly block executed outside conditional
check with "-O1 -ftree-vrp"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@thereisnospork.com


In the following test case, the int3 instruction inserted by the assertion
macro is executed before any conditional check is performed when compiled with
"-O1 -ftree-vrp".  Without -ftree-vrp (as well as "-O2 -fno-tree-vrp"), the
instructions are ordered as expected.

$ cat asmvolatiletest.c 
#include 

#define CUSTOM_ASSERT( X ) if( !( X ) ) { __asm__ __volatile__ ( "int3" ); }

void testFunction( unsigned int a, unsigned int b )
{
CUSTOM_ASSERT( a >= b );
if( a < b )
{
printf( "Error: %u < %u\n", a, b );
}
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-mandriva-linux-gnu
Configured with: ./configure --build=x86_64-mandriva-linux-gnu --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/lib64 --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include
--x-libraries=/usr/lib64 --disable-libgcj --with-cloog --with-ppl
--enable-cloog-backend=ppl --disable-libssp --disable-libunwind-exceptions
--disable-werror --enable-__cxa_atexit --enable-bootstrap
--enable-checking=release --enable-gnu-unique-object
--enable-languages=c,ada,c++,fortran,go,lto,objc,obj-c++
--enable-linker-build-id --enable-plugin --enable-shared --enable-threads=posix
--with-system-zlib --with-bugurl=https://qa.mandriva.com/ --with-tune=generic
--with-arch_32=i686 --host=x86_64-mandriva-linux-gnu
--target=x86_64-mandriva-linux-gnu
Thread model: posix
gcc version 4.6.0 20110513 (prerelease) (GCC)

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-05-17 
10:29:39 UTC ---
Author: rguenth
Date: Tue May 17 10:29:36 2011
New Revision: 173827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173827
Log:
2011-05-17  Richard Guenther  

PR bootstrap/49013
Revert
2011-05-16  Richard Guenther  

* gimple.c (gimple_types_compatible_p_1): Use names of the
type itself, not its main variant.
(iterative_hash_gimple_type): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-05-17 
10:30:18 UTC ---
Fixed.

[Bug tree-optimization/49018] Inline assembly block executed outside conditional check with "-O1 -ftree-vrp"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.17 10:50:48
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-05-17 
10:50:48 UTC ---
if-combine is doing this.  bb_no_side_effects_p returns true for the
basic-block with the asm.

Mine.

[Bug tree-optimization/49019] New: [4.4 Regression] Spurious aliasing warning with boost:optional

[jakub at gcc dot gnu.org]

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

   Summary: [4.4 Regression] Spurious aliasing warning with
boost:optional
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


On the attached testcase with g++ -O2 -Wall g++ emits a couple of
/home/ts/pack/boost_1_46_1/boost/optional/optional.hpp:346: warning:
dereferencing pointer ‘pretmp.811’ does break strict-aliasing rules
warnings.  Works fine with 4.3, or 4.5/4.6/4.7 (on the trunk it went away
with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147805 which is clearly
not backportable) or with -fno-tree-pre -fno-tree-fre.
The warning is about a pointer var with def_stmt being & of a may_alias union
inside aligned_storage, wonder why if (bitmap_empty_p (pi->pt_vars)) is true
in find_what_p_points_to and doesn't say at least that it can point to what it
has been initialized to.  Richard, is there anything that can be done about
this
for 4.4, or is it too risky?

[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.4.5, 4.5.2, 4.6.0

--- Comment #6 from Jonathan Wakely  2011-05-17 
11:33:03 UTC ---
No ICE on i686-pc-linux-gnu with:

gcc version 4.4.5 (Debian 4.4.5-8) 
gcc version 4.4.5 (GCC) 
gcc version 4.5.2 (GCC) 
gcc version 4.6.0 (GCC)

[Bug libstdc++/49020] New: Invalid std::strchr prototype in cstring

[d.v.a at ngs dot ru]

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

   Summary: Invalid std::strchr prototype in cstring
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d@ngs.ru


Shall be

const char *strchr(const char * , int );
char *strchr(char * , int );

according to Standard.
But we have

char *strchr(char * , int );

and invalid

char *strchr(const char * , int );

from string.h

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[thenlich at users dot sourceforge.net]

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

--- Comment #7 from Thomas Henlich  
2011-05-17 11:57:31 UTC ---
I suppose we could still use __builtin_fmod if we reset the sign bit if the
result is -0.

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  2011-05-17 
12:17:24 UTC ---
You haven't said which version of gcc or which platform.

With a recent GCC and recent glibc I get:

extern "C++"
{
extern char *strchr (char *__s, int __c)
 throw () __asm ("strchr") __attribute__ ((__pure__)) __attribute__
((__nonn
ull__ (1)));
extern __const char *strchr (__const char *__s, int __c)
 throw () __asm ("strchr") __attribute__ ((__pure__)) __attribute__
((__nonn
ull__ (1)));
}

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2011-05-17 
12:22:25 UTC ---
dup of PR 33935 - also related to PR 30928

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

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[d.v.a at ngs dot ru]

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

--- Comment #3 from __vic  2011-05-17 12:24:56 UTC ---
(In reply to comment #1)
> You haven't said which version of gcc or which platform.
> 
Actually 3.4.3 on Linux and Windows (MinGW) but in SVN trunk version (r169421)
/trunk/libstdc++-v3/include/c_std/cstring
I have not found any changes.

[Bug libstdc++/33935] overloads in C headers

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-05-17 
12:22:25 UTC ---
*** Bug 49020 has been marked as a duplicate of this bug. ***

[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2011-05-17 
12:37:52 UTC ---
Created attachment 24260
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24260
test case, preprocessed on x86_64-linux

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[d.v.a at ngs dot ru]

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

--- Comment #4 from __vic  2011-05-17 12:31:50 UTC ---
(In reply to comment #1)
> With a recent GCC and recent glibc I get:
> 
In which version of GCC can I find valid implementation?

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[d.v.a at ngs dot ru]

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

__vic  changed:

   What|Removed |Added

Version|unknown |4.1.1

--- Comment #5 from __vic  2011-05-17 12:41:29 UTC ---
GCC 4.1.1 - still no luck

[Bug c++/49021] New: [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[mikpe at it dot uu.se]

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

   Summary: [4.6 regression] BOOST_FOREACH over vector segfaults
at runtime
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


The following test case, which I'll also attach, segfaults at runtime when
compiled by gcc-4.6-20110513 on x86_64-linux or i686-linux.  When compiled by
gcc-4.5-20110512 it works as expected.

> cat comm-bug-test.cc 
#include 
#include 
#include 

std::vector v;

std::vector x;

const inline std::vector
getv()
{
const size_t num_accesses(x.size());
std::vector ret(num_accesses);
for (size_t i = 0; i < num_accesses; i++)
ret[i] = &v[x[i]];
return ret;
}

int
main(int argc, char **argv)
{
x.push_back(0);
x.push_back(1);
x.push_back(2);
x.push_back(3);
x.push_back(4);
x.push_back(5);

v.push_back(11);
v.push_back(12);
v.push_back(13);
v.push_back(14);
v.push_back(15);
v.push_back(16);

BOOST_FOREACH(int *w, getv())
printf("%d\n", *w);

return 0;
}
> /mnt/misc/install45/bin/g++ -O2 -Wall comm-bug-test.cc; ./a.out
11
12
13
14
15
16
> /mnt/misc/install46/bin/g++ -O2 -Wall comm-bug-test.cc; ./a.out
Segmentation fault
> /mnt/misc/install46/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/mnt/misc/install46/bin/g++
COLLECT_LTO_WRAPPER=/mnt/misc/install46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/misc/gcc-4.6-20110513/configure
--prefix=/mnt/misc/install46 --with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86_64/mpc-0.8.2 --disable-plugin
--disable-lto --disable-nls --disable-libmudflap --enable-threads=posix
--enable-checking=release
--enable-languages=c,c++,objc,obj-c++,fortran,java,ada
Thread model: posix
gcc version 4.6.1 20110513 (prerelease) (GCC)

Initially found by a colleague when testing our code on Fedora 15 with Red
Hat's gcc-4.6.0 (20110428) and boost 1.46.  I then confirmed the bug on Fedora
13 with a self-compiled gcc-4.6-20110513 and boost-1.41.  -m32 or -m64 makes no
difference.

[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2011-05-17 
12:38:38 UTC ---
Created attachment 24261
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24261
test case, non-preprocessed

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2011.05.17 12:57:53
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2011-05-17 12:57:53 
UTC ---
I still got the same error with revision 173828:

http://gcc.gnu.org/ml/gcc-regression/2011-05/msg00380.html

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-17 
13:04:47 UTC ---
LTO bootstrap passed for me with the revert and the previously applied patch.
I didn't try LTO profiled-bootstrap.

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-05-17 
13:12:17 UTC ---
Try again with rev. 173829.

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2011-05-17 
13:07:24 UTC ---
In glibc 2.10 and later together with gcc 4.4 and later.

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[d.v.a at ngs dot ru]

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

__vic  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from __vic  2011-05-17 13:25:31 UTC ---
Ok, I'll try to upgrade my GCC version.
Thanx

[Bug libstdc++/49022] New: [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[flast at flast dot jp]

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

   Summary: [C++0x] std::begin and std::end specialized for
std::valarray with some operators are missing.
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp


Currently, std::begin and std::end specialized for std::valarray are exist.
However operators for std::valarray are using Expression Template technique.
And std::begin and std::end specialized for those are not exist.

For example, GCC rejects following code.
 testcase.cc 
#include 

void f()
{
std::valarray x,y;
std::begin(x + y);
}


output:
$ g++-4.6 -std=c++0x testcase.cc
testcase.cc: In function 'void f()':
testcase.cc:6:23: error: no matching function for call to
'begin(std::_Expr, int>)'
testcase.cc:6:23: note: candidates are:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/initializer_list:86:38:
note: template constexpr const _Tp*
std::begin(std::initializer_list<_Tp>)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:48:57:
note: template decltype (__cont->begin())
std::begin(_Container&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:58:63:
note: template decltype (__cont->begin()) std::begin(const
_Container&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:87:28:
note: template _Tp* std::begin(_Tp (&)[_Nm])
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/valarray:1126:30:
note: template _Tp* std::begin(std::valarray<_Tp>&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/valarray:1136:36:
note: template const _Tp* std::begin(const std::valarray<_Tp>&)

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #6 from Lee Merrill  2011-05-17 
13:29:56 UTC ---
(In reply to comment #5)
> Yeah, 128 bytes below %rsp can be freely used on x86_64, interrupts must not
> clobber those.

I should have mentioned that this is kernel driver code, so then the interrupt
does not change privilege level, and a stack switch will not occur. When an
interrupt happens, the flags / cs / ip are stored at the next 24 bytes of
stack, overwriting the variables in view here. I've seen this happen on a
standard Suse 10 x86_64 Linux machine, so this would not be just theoretical...

[Bug libstdc++/49020] Invalid std::strchr prototype in cstring

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-05-17 
13:38:57 UTC ---
3.4 and 4.1 are ancient history, active release series are listed on the home
page, http://gcc.gnu.org/

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.17 13:54:13
 Ever Confirmed|0   |1

[Bug fortran/49023] New: ICE on invalid code with C_ASSOCIATED

[dennis.wassel at googlemail dot com]

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

   Summary: ICE on invalid code with C_ASSOCIATED
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dennis.was...@googlemail.com


Hi list,

when messing around with C_ASSOCIATED, I got an ICE with this bit of invalid
code using stock gfortran on Ubuntu 10.4

- 8< -
PROGRAM test

  USE, INTRINSIC :: iso_c_binding
  IMPLICIT NONE

  TYPE (C_PTR) :: x, y

  PRINT *, C_ASSOCIATED([x,y])  ! wrong: C_ASSOCIATED is not ELEMENTAL

END PROGRAM test
- 8< -

$ gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)


valgrind says

valgrind /usr/lib/gcc/x86_64-linux-gnu/4.4.3/f951 /home/uni/tmp/test.f90
-dumpbase test.f90 -mtune=generic -auxbase test -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/finclude -o /tmp/ccMioHAS.s
==1488== Memcheck, a memory error detector
==1488== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1488== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==1488== Command: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/f951
/home/uni/tmp/test.f90 -dumpbase test.f90 -mtune=generic -auxbase test
-fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.4.3/finclude -o
/tmp/ccMioHAS.s
==1488== 
==1488== Invalid read of size 8
==1488==at 0x4FC5F2: ??? (in /usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x4F95C1: gfc_resolve_expr (in
/usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x4FFC22: ??? (in /usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x5031EB: gfc_resolve_blocks (in
/usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x4FFC02: ??? (in /usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x5015C0: ??? (in /usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x501604: gfc_resolve (in
/usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x4EFD5F: gfc_parse_file (in
/usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x520937: ??? (in /usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x738FF1: toplev_main (in
/usr/lib/gcc/x86_64-linux-gnu/4.4/f951)
==1488==by 0x54FEC4C: (below main) (libc-start.c:226)
==1488==  Address 0x28 is not stack'd, malloc'd or (recently) free'd
==1488== 

On a side note:
The example code at
http://gcc.gnu.org/onlinedocs/gfortran/C_005fASSOCIATED.html
puzzles me. Shouldn't the message read 'b and a DO point to the same target'?

Cheers,
Dennis

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #7 from Lee Merrill  2011-05-17 
13:42:23 UTC ---
I think what is happening in the compiler BTW is that a "sub $XX, %rsp" is
dropping out, perhaps as an optimization. If for example, you comment out the
"#define inline" line in the test code, a stack adjustment appears:

   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   48 83 ec 10 sub$0x10,%rsp   # SP adjustment here
   8:   48 89 7d f8 mov%rdi,-0x8(%rbp)
   c:   89 75 f4mov%esi,-0xc(%rbp)
etc.

And as far as using stack space below your stack pointer, suppose someone has
an operating system that runs applications at the same privilege level as the
OS?

[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-05-17 
13:52:40 UTC ---
The temporary returned by getv() seems to be destroyed too early, before the
printf that uses it

[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.17 13:36:29
 CC||davidxl at gcc dot gnu.org
   Target Milestone|--- |4.7.0
Summary|ICE: in |[4.7 Regression] ICE: in
   |reset_sched_cycles_in_curre |reset_sched_cycles_in_curre
   |nt_ebb, at sel-sched.c:7132 |nt_ebb, at sel-sched.c:7132
   |with even more insane set   |with even more insane set
   |of flags|of flags
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-17 13:36:29 
UTC ---
It is caused by revision 173177:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01373.html

[Bug c/49016] always_inline causes references below the current stack pointer

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-05-17 
14:01:51 UTC ---
It is of course fine if an interrupt uses the same stack, after all, user
interrupts do that too.  But the ABI says that 128 bytes below the %rsp are
reserved, so the interrupt code first needs to subtract 128 from %rsp before
calling any functions and must not modify that area.
You can compile with -mno-red-zone to force no red zone.
Apparently that's a flag x86_64-linux kernel uses during compilation and
therefore
probably doesn't bother to preserve the red zone during interrupts except when
creating a user interrupt:
arch/x86/Makefile has:
KBUILD_CFLAGS += -mno-red-zone
KBUILD_CFLAGS += -mcmodel=kernel
Thus if you are compiling Linux kernel x86_64 code or modules without
-mno-red-zone, it would be a user error.

[Bug libfortran/49024] New: REAL*16 ERFC_SCALED inaccuracy

[thenlich at users dot sourceforge.net]

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

   Summary: REAL*16 ERFC_SCALED inaccuracy
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The libfortran implementation of the ERFC_SCALED intrinsic function is not
accurate enough to be useful for REAL*16 arithmetics.

program test_erfc_scaled
real(16), parameter :: p16 = 1.0_16
real(16) :: v16 = p16

print *, erfc_scaled(v16)
print *, erfc_scaled(p16)
print *, erfc(v16) * exp(v16 * v16)
end program test_erfc_scaled

==>
  0.427583576155807003967191251980322016  
  0.427583576155807004410750344490515188  
  0.427583576155807004410750344490515140  

This should be easy to fix by adding an erfc_scaled() function to libquadmath.

In fact, the error function code in libquadmath is based on the same code as
http://www.netlib.org/cephes/128bdoc.html and the latter already contains a
separate function for a scaled error function. In libquadmath it has been
merged into one (or maybe the other was split later).

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  2011-05-17 14:02:07 
UTC ---
So does the fallback path actually ever get used? AFAICS the builtins are
always available, and if the builtin results in a call to fmod{f,,l,Q} we have
fallback implementations in c99_functions.c for non-C99 functions.  See PR
29810.

A problem with a naive implementation of the algorithm specified by the
standard is that it doesn't work for large arguments, which was what prompted
the usage of builtin_fmod in the first place. See PR 24518.

Taken together, it seems the proper approach would be to just remove the
fallback path (not really related to this PR per se, just as a general
janitorial patch), and fix the result if it's negative zero. E.g. something
like the following pseudocode for MOD(a,p):

if (!options.fast_math && fabs(p) == 0.0)
  generate_error(...) // TBH, aborting the program here seems quite drastic..
[1]
res = __builtin_fmod (a, p)
if (options.signed_zeros)
{
  if (res == -0.0)
res = 0.0
}

[1] While ISO C leaves it implementation-defined what happens here, POSIX
specifies that "If y is zero, a domain error shall occur, and either a NaN (if
supported), or an implementation-defined value shall be returned.".  Similarly,
MS fmod returns NaN (according to MSDN, I haven't tested). So while not
strictly conforming to the Fortran spec, the POSIX/MS approach seems more
sensible, and is IMHO a better choice than aborting the program.

[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags

[abel at gcc dot gnu.org]

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

--- Comment #2 from Andrey Belevantsev  2011-05-17 
14:20:52 UTC ---
That patch is most likely just exposed a sel-sched bug or a target bug. I will
be looking at it tomorrow.

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

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.17 14:05:46
 CC||dje at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #25 from David Edelsohn  2011-05-17 
14:05:46 UTC ---
GCC uses the AIX assembler and probably is the most heavy user of the assembler
of all applications on AIX (IBM XL compilers generate object code directly). 
An upgrade to the AIX assembler has introduced a bug that can generate invalid
object files.  The is an AIX bug, not a GCC bug.  The broken assembler is
distributed in AIX 7.1 TL0, and updates for earlier levels of AIX: AIX 6.1 TL6
and AIX 5.3 TL12.

A number of PMRs have been reported about the problem:

PMR 32726, 379, 000
PMR 40999, 122, 000 (unable to compile after TL12 upgrade)
PMR 13417, 005, 000 (assembler-compiler errors at TL12 update)

An initial fix introduced other problems.  A new fix is available, but it still
is unclear when it generally will be available.  APARs:

IZ98134 for AIX 5.3 TL12
IZ98861 for AIX 6.1 TL6
IZ99344 for AIX 7.1 TL0

Other related APARs:
IZ98226 IZ98385 IZ98477 IZ98732 IZ99107

The fixed assembler is available as an efix for customers who ask.

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  
2011-05-17 14:02:11 UTC ---
On Tue, May 17, 2011 at 06:05:50AM +, thenlich at users dot sourceforge.net
wrote:
> --- Comment #5 from Thomas Henlich  
> 2011-05-17 05:51:56 UTC ---
> The fmod behaviour is correct for x < 0 according to N1548:
> 

Yes, I know.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||g...@integrable-solutions.ne
   ||t

--- Comment #1 from Paolo Carlini  2011-05-17 
14:41:25 UTC ---
Frankly, I have no idea what is missing vs the letter of the FDIS. Tips?

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot
   ||com

--- Comment #2 from Paolo Carlini  2011-05-17 
14:48:35 UTC ---
To expand: *if* the '+' itself is allowed per the specs to return something !=
std::valarray, and the specs only mandate std::begin and std::end overloads
taking std::valarray& and const std::valarray& I don't see where is the bug in
our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't
followed the recent discussion about ranges in any detail, I may be missing
something.

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #10 from Lee Merrill  2011-05-17 
14:49:33 UTC ---
And the compile (and the compile in the "rc" script here) is indeed specifying
-mcmodel=kernel in the flags.

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

[michael.haubenwallner at salomon dot at]

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

--- Comment #26 from Michael Haubenwallner  2011-05-17 14:52:36 UTC ---
(In reply to comment #25)
> The fixed assembler is available as an efix for customers who ask.

We did do this here, but the efix'ed assembler just dumps core upon some C++
construct found in strstream.cc (and others) - IBM is already aware of this.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-05-17 
14:52:41 UTC ---
[valarray.syn] paragraph 4 

   for every function taking a const valarray&, identical functions
   taking the replacement types shall be added;

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  
2011-05-17 14:50:52 UTC ---
On Tue, May 17, 2011 at 02:17:22PM +, jb at gcc dot gnu.org wrote:
>
> So does the fallback path actually ever get used? AFAICS the builtins are
> always available, and if the builtin results in a call to fmod{f,,l,Q} we have
> fallback implementations in c99_functions.c for non-C99 functions.  See PR
> 29810.
> 

I don't know all the targets on which gfortran can run.  Of course,
if all target have the builtin, then the fallback code won't be used.
We can garbage collect the code if you're confident that it is unneeded.

> Taken together, it seems the proper approach would be to just remove the
> fallback path (not really related to this PR per se, just as a general
> janitorial patch), and fix the result if it's negative zero. E.g. something
> like the following pseudocode for MOD(a,p):
> 
> if (!options.fast_math && fabs(p) == 0.0)
>   generate_error(...) // TBH, aborting the program here

The restriction that "P shall not be zero" is on the user
not the compiler, and the compiler is not required to 
diagnosis that problem.  I think we can simply issue a
warning and let the builtin set res = NaN. 

> res = __builtin_fmod (a, p)
> if (options.signed_zeros)
> {
>   if (res == -0.0)
> res = 0.0
> }

I don't have n1256.pdf handy (draft of C standard), but
IIRC, this check is expensive because zero and negative zero
compare equal.  One needs to explicitly check the sign
bit or simply do

   if (res == 0.0) res = abs(res)

to clear the sign.

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #9 from Lee Merrill  2011-05-17 
14:47:34 UTC ---
(In reply to comment #8)
> ... the ABI says that 128 bytes below the %rsp are
> reserved, so the interrupt code first needs to subtract 128 from %rsp before
> calling any functions and must not modify that area.

Thanks for your reply, yet the interrupt itself will modify the next 24 bytes
below %rsp, in storing flags / cs / rip. So then this area would be corrupted,
which indeed I am seeing.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  2011-05-17 
15:03:37 UTC ---
Ah, ok, now I see, it's just that std::begin and std::end fall under 26.6.1/4.
Only the const std::valarray& version, if I understand correctly. I can look
into it reasonably soon, seems easy.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-05-17 
15:09:44 UTC ---
Double Sigh! I was hoping very few overloads would be enough... If we are
really talking about many I would be in favor of raising the issue, indeed.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

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

--- Comment #5 from Gabriel Dos Reis  2011-05-17 
15:04:48 UTC ---
(In reply to comment #2)
> To expand: *if* the '+' itself is allowed per the specs to return something !=
> std::valarray, and the specs only mandate std::begin and std::end overloads
> taking std::valarray& and const std::valarray& I don't see where is the bug in
> our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't
> followed the recent discussion about ranges in any detail, I may be missing
> something.


LWG failed to resist the longstanding temptation to turn valarray into
yet another container.  You can't turn it into an container and yet
make is possible for implementations to EFFECTIVELY exploit the lack
of aliasing guarantees.  If looks like everytime I turn my back LWG
jumps tto do something to valarray.
Either we have a flood of begin/end functions decorated with __enable_if
stuff or we make it a defect in LWG.

Sigh.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #7 from Gabriel Dos Reis  2011-05-17 
15:14:04 UTC ---
(In reply to comment #6)
> Double Sigh! I was hoping very few overloads would be enough... If we are
> really talking about many I would be in favor of raising the issue, indeed.

The issue is even trickier than that:  If you were allowed to write those
functions, what would begin() and end() return?  a pointer into a 
soon-to-be-destroyed valarray? 

I think this is a defect in the standard.  I just sent an email.

-- Gaby

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2011-05-17 
15:17:01 UTC ---
Ok, I'll follow the discussion...

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

[david.kirkby at onetel dot net]

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

--- Comment #27 from Dr. David Kirkby  
2011-05-17 15:25:50 UTC ---
(In reply to comment #25)

> The fixed assembler is available as an efix for customers who ask.

Can you give me more precise details about how to get this. Who do I ask - I
don't have a service contract for my old AIX box. 

I have a workaround for this, as someone sent me an older version of the
assembler which works, but clearly using a later version would be preferable. 

Dave

[Bug c++/45221] missed optimization with multiple bases and casting

[navin.kumar at gmail dot com]

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

Navin Kumar  changed:

   What|Removed |Added

Version|4.5.0   |4.6.0

--- Comment #11 from Navin Kumar  2011-05-17 
15:18:06 UTC ---
Bumping this to 4.6.0 since the problem still exists.

As a review (since this has been open and not updated for a while), the problem
is very slow performance when dealing with C++'s multiple-inheritance (even
under -O3).  In the example below, the 'simple' fooA function generates slow
code, whereas the equivalent code written with more steps in fooB generates
optimal code.

Base2* fooA(Derived* x)
{
Base2& y = *x;
return &y;
}
Base2* fooB(Derived* x) {
Derived& x2 = *x;
Base2& y = x2;
return &y;
}

Both fooA and fooB are funtionally identical.

Yet the assembly generated for fooA is:
leaq4(%rdi), %rdx
xorl%eax, %eax
testq   %rdi, %rdi
cmovne  %rdx, %rax
ret

and the assembly generated for fooB is:
leaq4(%rdi), %rax
ret

[Bug java/48417] -ffixed-regs option can't work in mips-elf-gcj compiler

[licheng.1212 at gmail dot com]

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

licheng.1...@gmail.com  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
   Severity|blocker |critical

--- Comment #4 from licheng.1212 at gmail dot com  2011-05-17 15:33:45 UTC ---
still hava this problem,please see the latest commit

[Bug fortran/49025] New: gfortran bug: Local variable does not hide generic procedure.

[david.sagan at gmail dot com]

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

   Summary: gfortran bug: Local variable does not hide generic
procedure.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.sa...@gmail.com


Consider the following test code:

---

module test

interface kick
  subroutine a_kick
  end subroutine
end interface

contains

subroutine my_sub
  implicit none
  integer kick
  call some_sub(kick)
end subroutine

end module

--
Compiling gives:

lnx4103:~/dcs/bmad_distribution/test_build> gfortran --version
GNU Fortran (GCC) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.

lnx4103:~/dcs/bmad_distribution/test_build> gfortran -c test.f90
test.f90:13.16:

  call some_sub(kick)
1
Error: GENERIC procedure 'kick' is not allowed as an actual argument at (1)


The local "kick" variable is not hiding the "kick" generic procedure. 
This code compiles with ifort v9 and v12.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-05-17 
15:27:01 UTC ---
The workaround for users is to construct a valarray from the expr:

std::valarray result(x + y);
std::begin( result );

That avoids the problem of returning an iterator into a temporary which no
longer exists.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2011-05-17 
15:49:25 UTC ---
For sure that works.

Gaby, just to make sure we are on the same page: did you send a message to the
reflector about this issue already? Or do you want me (us) to do that? Shall we
suspend this PR in the meanwhile?

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2011-05-17 
15:54:19 UTC ---
All in all, now that I understand the issue with the temporary, this seems
really sort of a NAD, maybe the wording needs only clarifying that you don't
want to add std::begin and std::end overloads, no?

[Bug target/49026] New: [4.7 Regression] FAIL: gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution test at r173809 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

   Summary: [4.7 Regression] FAIL:
gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution
test at r173809 on x86_64-apple-darwin10
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: js...@gcc.gnu.org
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


Created attachment 24262
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24262
preprocessed file for sse4_1-ceil-vec.c

At revision 173809 I get on x86_64-apple-darwin10

FAIL: gcc.target/i386/sse4_1-ceil-vec.c execution test
FAIL: gcc.target/i386/sse4_1-floor-vec.c execution test

for both -m32 and -m64. Revision 173808 is OK. Replacing the abort with

printf("%d, %f, %f\n", i, r[i], ceil (a[i]));

I get

62, 0.00, 1.00

Preprocessed file attached.

[Bug java/26007] initialized final static data should go in .rodata, not .data

[licheng.1212 at gmail dot com]

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

licheng.1...@gmail.com  changed:

   What|Removed |Added

 CC||licheng.1212 at gmail dot
   ||com

--- Comment #3 from licheng.1212 at gmail dot com  2011-05-17 15:47:32 UTC ---
(In reply to comment #1)
> Note there are ticks for final static data to be changed IIRC.  I don't know
> how useful they are or if they really are valid.

put it to .rodata is very useful to embebed system,this will release many
memory useage.

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  2011-05-17 
16:18:41 UTC ---
(In reply to comment #10)
> On Tue, May 17, 2011 at 02:17:22PM +, jb at gcc dot gnu.org wrote:
> >
> > So does the fallback path actually ever get used? AFAICS the builtins are
> > always available, and if the builtin results in a call to fmod{f,,l,Q} we 
> > have
> > fallback implementations in c99_functions.c for non-C99 functions.  See PR
> > 29810.
> > 
> 
> I don't know all the targets on which gfortran can run.  Of course,
> if all target have the builtin, then the fallback code won't be used.
> We can garbage collect the code if you're confident that it is unneeded.

I'm fairly confident. AFAICS the idea is that the builtins are always
available, but if the compiler cannot optimize it in some meaningful way (e.g.
constant folding) then a call to the corresponding library function is emitted,
and this is the situation where things can go wrong as not all targets provide
a C99 libm. However, as we provide fallbacks in c99_functions.c this case is
covered.

This is, in short, the story behind PR 29810; when we started using
BUILT_IN_FMOD{F,,L} the float and long double builtins were available also on
targets where fmod{f,l} were not.

> > Taken together, it seems the proper approach would be to just remove the
> > fallback path (not really related to this PR per se, just as a general
> > janitorial patch), and fix the result if it's negative zero. E.g. something
> > like the following pseudocode for MOD(a,p):
> > 
> > if (!options.fast_math && fabs(p) == 0.0)
> >   generate_error(...) // TBH, aborting the program here
> 
> The restriction that "P shall not be zero" is on the user
> not the compiler, and the compiler is not required to 
> diagnosis that problem.

Ah, good point.

>  I think we can simply issue a
> warning and let the builtin set res = NaN. 

Well, I was thinking of not testing whether p == 0 at all; As the NaN will
presumably propagate the user will find out that something went wrong quickly
enough (if the user bothers to check the output, that is! :) ), and finding the
place where the NaN occurred is as simple as recompiling with
-ffpe-trap=invalid.

> > res = __builtin_fmod (a, p)
> > if (options.signed_zeros)
> > {
> >   if (res == -0.0)
> > res = 0.0
> > }
> 
> I don't have n1256.pdf handy (draft of C standard), but
> IIRC, this check is expensive because zero and negative zero
> compare equal.  One needs to explicitly check the sign
> bit or simply do
> 
>if (res == 0.0) res = abs(res)
> 
> to clear the sign.

Ah, so it seems.

[Bug java/26007] initialized final static data should go in .rodata, not .data

[licheng.1212 at gmail dot com]

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

--- Comment #4 from licheng.1212 at gmail dot com  2011-05-17 16:12:07 UTC ---
can anybody tell me how to change the final form .data to .rodata.
which files have the check in gcc?

[Bug fortran/49025] gfortran bug: Local variable does not hide generic procedure.

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||burnus at gcc dot gnu.org
  Known to fail||4.3.4, 4.5.1, 4.7.0

--- Comment #1 from Tobias Burnus  2011-05-17 
16:16:13 UTC ---
Confirmed.

That's an interesting issue. "external kick" and using "a_kick" works, only
generic + type spec fails.

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #7 from H.J. Lu  2011-05-17 15:50:15 
UTC ---
Fixed as of revision 173830.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #13 from Gabriel Dos Reis  2011-05-17 
16:24:57 UTC ---
(In reply to comment #11)
> All in all, now that I understand the issue with the temporary, this seems
> really sort of a NAD, maybe the wording needs only clarifying that you don't
> want to add std::begin and std::end overloads, no?

yes, my recommendation (in the email I sent LWG reflector) was to remove
the begin/end pairs -- at least for the version that takes a const valarray&.

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  2011-05-17 
16:33:56 UTC ---
Created attachment 24263
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24263
gcc46-pr49000.patch

Untested fix.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #12 from Gabriel Dos Reis  2011-05-17 
16:23:37 UTC ---
(In reply to comment #10)
> For sure that works.
> 
> Gaby, just to make sure we are on the same page: did you send a message to the
> reflector about this issue already? Or do you want me (us) to do that? Shall 
> we
> suspend this PR in the meanwhile?

Yes, I did send an email to c++std-lib.  Apparently, there is some kind
of partial network outage at the TAMU CSE so there might be a delay.
Yes, it makes sense to suspend this PR in the meantime.

[Bug c++/49027] New: g++ ignores -fno-exceptions in uninstantiated template

[ian at airs dot com]

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

   Summary: g++ ignores -fno-exceptions in uninstantiated template
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com


This file compiles without error when using -fno-exceptions:

extern int f2();
template
void f1() {
  try { f2(); } catch (...) { }
}

Compiling this very similar file:

extern int f2();
template
void f1() {
  try { f2(); } catch (...) { }
}
template f1();

gives these errors:

foo.cc: In function ‘void f1() [with T = int]’:
foo.cc:6:   instantiated from here
foo.cc:4: error: exception handling disabled, use -fexceptions to enable

I think it would be more consistent for g++ to reject uses of try/catch when
compiling with -fno-exceptions even in uninstantiated templates.  Otherwise you
can get surprising results when code changes: you can find problems in very
different pieces of code.

[Bug java/48417] -ffixed-regs option can't work in mips-elf-gcj compiler

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #5 from Mikael Pettersson  2011-05-17 
17:02:38 UTC ---
(In reply to comment #4)
> still hava this problem,please see the latest commit

See PR43700, which I suspect was fixed by r172616 on trunk.

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-05-17 
17:03:00 UTC ---
Needs to be guarded additionally with && gimple_debug_bind_has_value_p (stmt)
otherwise it doesn't get too far.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #14 from Paolo Carlini  2011-05-17 
16:43:01 UTC ---
Let's suspend this, for now. Thanks Gaby.

[Bug c/49016] always_inline causes references below the current stack pointer

[mikpe at it dot uu.se]

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

--- Comment #11 from Mikael Pettersson  2011-05-17 
16:58:02 UTC ---
(In reply to comment #10)
> And the compile (and the compile in the "rc" script here) is indeed specifying
> -mcmodel=kernel in the flags.

-mcmodel=kernel isn't enough, you're still failing to pass -mno-red-zone.

[Bug rtl-optimization/49028] New: Missed optimization of pointer arithmetic

[piotr.wyderski at gmail dot com]

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

   Summary: Missed optimization of pointer arithmetic
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com


The following examples come from x64, but I believe the problem
shows on other architectures too. 

I have implemented an object recycler based on a circular buffer of pointers
with a single cursor. N is the capacity of the buffer; powers of two are highly
preferred, so let we assume N = 16.


template  struct R {

void*  m_Data[N];
void** m_Cursor;

void xxx_release(void* p) __attribute__((__noinline__));
};

template  void R::xxx_release(void* p) {

m_Cursor = m_Data + ((m_Cursor + 1 - m_Data) % N);
*m_Cursor = p;
}

int main(int argc, char *argv[]) {  

R<16> rrr;
rrr.xxx_release(0);
return 0;
}

This generates (-O3 -msse -msse2 -msse4.2 -mfpmath=sse -march=core2
-mtune=core2):

0041a910 <_ZN1RILj16EE11xxx_releaseEPv>:
  41a910:48 8b 97 80 00 00 00 mov0x80(%rdi),%rdx
  41a917:48 83 c2 08  add$0x8,%rdx
  41a91b:48 29 fa sub%rdi,%rdx
  41a91e:48 89 d0 mov%rdx,%rax
  41a921:48 c1 fa 3f  sar$0x3f,%rdx
  41a925:48 c1 ea 3c  shr$0x3c,%rdx
  41a929:48 c1 f8 03  sar$0x3,%rax
  41a92d:48 01 d0 add%rdx,%rax
  41a930:83 e0 0f and$0xf,%eax
  41a933:48 29 d0 sub%rdx,%rax
  41a936:48 8d 14 c7  lea(%rdi,%rax,8),%rdx
  41a93a:48 89 34 c7  mov%rsi,(%rdi,%rax,8)
  41a93e:48 89 97 80 00 00 00 mov%rdx,0x80(%rdi)
  41a945:c3   retq   

The sequence is far from being optimal. The compiler should not move pointer
arithmetic to the type-independent integer domain (i.e. were (p + 1 - p) == 1),
but notice that the actual increment, whis is M = sizeof(void*), is a power of
2, in this case 8, so the final modulo result in integer domain for (p + 1) % N
will be the same as (((char*) p) + M) % (N * M). To cut a long story short:
instead of the above it should just generate:

0041a910 <_ZN1RILj16EE11xxx_releaseEPv>:
mov0x80(%rdi),%rdx
add$0x08, %rdx
sub%rdi, %rdx
and$0x7f, %rdx
add%rdi, %rdx
mov%rsi, (%rdx)
mov%rdx, 0x80(%rdi)
retq

I'm not sure I understand what is GCC trying to achieve with the shifts.
Secondly, my example above uses only simple addressing modes, but GCC
uses the most complex mode twice: in lea and in the subsequent mov.
Complex lea has 3 cycles of latency on SandyBridge, according to the
Intel Optimization Manual, p. 3.5.1.3, so it should best be avoided.

[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[xinliangli at gmail dot com]

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

--- Comment #14 from davidxl  2011-05-17 17:17:11 
UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #3)
> > > I have a patch that makes it fail on trunk as well.  IVOPTs generates
> > > 
> > >   for (p = &a; p != &a - 3; --p)
> > > *(p + 3) = ...
> > > 
> > > and alias analysis doesn't like this invalid pointer.
> > 
> > 
> > I wonder why ivopt does not select the iv candidate whose base is &a+3.
> 
> I think that one is not in the list of initial candidates.
> 
> I think for that sake we would want to add stripped &base + object size (+ 1?)
> (if we know it) as IV candidate iff iv->step is negative, iff iv->step is
> positive continue to add &base.
> 
> I don't like the alias oracle fixups too much, but I guess we have to
> benchmark both alternatives.

The candidate is actually there:

candidate 8
  var_before ivtmp.13
  var_after ivtmp.13
  incremented before exit test
  type long unsigned int
  base (long unsigned int) &MEM[(int *)&array][3]{lb: 0 sz: 4}
  step 0x0fffc
  base object (void *) &array

The following patch fixes the problem. Is it ok?

David


--- tree-ssa-loop-ivopts.c  (revision 173278)
+++ tree-ssa-loop-ivopts.c  (working copy)
@@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
  int *inv_expr_id)
 {
   tree ubase = use->iv->base, ustep = use->iv->step;
-  tree cbase, cstep;
+  tree cbase, cstep, cbase_strip;
   tree utype = TREE_TYPE (ubase), ctype;
   unsigned HOST_WIDE_INT cstepi, offset = 0;
   HOST_WIDE_INT ratio, aratio;
@@ -4026,6 +4026,13 @@ get_computation_cost_at (struct ivopts_d
   if (!constant_multiple_of (ustep, cstep, &rat))
 return infinite_cost;

+  cbase_strip = STRIP_NOPS (cbase);
+  /* Avoid confusing aliaser.  */
+  if (TREE_CODE (cbase_strip) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (cbase_strip, 0)) == VAR_DECL
+  && (HOST_WIDE_INT) cstepi < 0)
+return infinite_cost;
+
   if (double_int_fits_in_shwi_p (rat))
 ratio = double_int_to_shwi (rat);
   else

[Bug rtl-optimization/49028] Missed optimization of pointer arithmetic

[piotr.wyderski at gmail dot com]

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

--- Comment #1 from Piotr Wyderski  2011-05-17 
17:24:03 UTC ---
If I change the function to:

template  void R::xxx_release(void* p) {

char* q = reinterpret_cast(m_Cursor);
   char* b = reinterpret_cast(m_Data);

   q = ((q + sizeof(void*)) - b) % (N * sizeof(void*)) + b;
m_Cursor = reinterpret_cast(q);
*m_Cursor = p;
}

Then the generated code is:

0041a910 <_ZN1RILj16EE11xxx_releaseEPv>:
  41a910:48 8b 87 80 00 00 00 mov0x80(%rdi),%rax
  41a917:48 83 c0 08  add$0x8,%rax
  41a91b:48 29 f8 sub%rdi,%rax
  41a91e:83 e0 7f and$0x7f,%eax
  41a921:48 01 f8 add%rdi,%rax
  41a924:48 89 87 80 00 00 00 mov%rax,0x80(%rdi)
  41a92b:48 89 30 mov%rsi,(%rax)
  41a92e:c3   retq   

which is astonishingly close to my hand-made assembly...

[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.17 17:24:37
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2011-05-17 
17:24:37 UTC ---
slightly reduced, but boost/foreach.hpp still includes thousands of lines

in this version vector zeros its data member on destruction, so using it
after destruction is obvious

#include 

template
struct vector
{
typedef const T* const_iterator;

~vector() { data = T(); }

T data;

const_iterator begin() const { return &data; }
const_iterator end() const { return &data + 1; }
};

vector v = { 1 };

const vector
getv()
{
vector ret = { &v.data };
return ret;
}

int
main(int argc, char **argv)
{
BOOST_FOREACH(int *w, getv())
__builtin_printf("%d\n", *w);

return 0;
}

[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-05-17 
17:28:44 UTC ---
slightly more reduced

#include 

struct vector
{
typedef int* const* const_iterator;

~vector() { data = 0; }

int* data;

const_iterator begin() const { return &data; }
const_iterator end() const { return &data + 1; }
};

int v = 1;

const vector
getv()
{
vector ret = { &v };
return ret;
}

int
main(int argc, char **argv)
{
BOOST_FOREACH(int *w, getv())
__builtin_printf("%d\n", *w);

return 0;
}

[Bug target/49029] New: ICE in simplify_subreg, at simplify-rtx.c:5266

[rmansfield at qnx dot com]

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

   Summary: ICE in simplify_subreg, at simplify-rtx.c:5266
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com


$ cat ~/ice.i
#pragma pack(1)

struct S0
{
  volatile unsigned f0:11;
  signed f2:30;
};

struct S1
{
  volatile struct S0 f7;
};

struct S1 a, b;

void
bar ()
{
  foo (a.f7.f0) && foo (b.f7.f2);
}

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--disable-multilib
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.7.0 20110517 (experimental) [trunk revision 173832] (GCC) 

$ ./xgcc -B. ~/ice.i
/home/ryan/ice.i: In function 'bar':
/home/ryan/ice.i:19:29: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5266
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

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

[skunk at iskunk dot org]

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

--- Comment #28 from Daniel Richard G.  2011-05-17 
18:12:26 UTC ---
(In reply to comment #25)
> An upgrade to the AIX assembler has introduced a bug that can generate invalid
> object files.  The is an AIX bug, not a GCC bug.

I'm not yet convinced that this is the case. It could well be that the
assembler (or linker) is being more strict in how it interprets code.

Does anyone here have the IBM XL compiler? It would be interesting to compare
the assembly that it produces (I presume it can be made to generate assembly
even if it normally emits object code directly) for the minimal test case to
GCC's.

[Bug target/49029] ICE in simplify_subreg, at simplify-rtx.c:5266

[rmansfield at qnx dot com]

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

Ryan Mansfield  changed:

   What|Removed |Added

 Target||arm-unknown-linux-gnueabi
   Host||x86_64-linux-gnu
  Build||x86_64-linux-gnu

--- Comment #1 from Ryan Mansfield  2011-05-17 
18:20:32 UTC ---
Update host/target fields

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #12 from Lee Merrill  2011-05-17 
18:42:47 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > And the compile (and the compile in the "rc" script here) is indeed 
> > specifying
> > -mcmodel=kernel in the flags.
> 
> -mcmodel=kernel isn't enough, you're still failing to pass -mno-red-zone.

That works, thanks! It does seem odd to tell it not to use the red zone, in
order for it to um, properly use the red zone. :)

[Bug target/49026] [4.7 Regression] FAIL: gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution test at r173809 on x86_64-apple-darwin10

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2011-05-17 18:48:26 UTC ---
Before-and-after .s output might be useful.

[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay  2011-05-17 
18:57:39 UTC ---
Created attachment 24264
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24264
Proposed patch.

Proposed Patch (also compatible with older versions of GCC).

The insn needs at most 3 instructions and does not put pressure on d-regs.

* config/avr/avr.md ("*extzv"): New insn.

[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  2011-05-17 
19:00:05 UTC ---
Created attachment 24265
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24265
Assembler output from 4.7.0 (r173832) with patch applied.

Assembler output from 4.7.0 (r173832) with patch applied.

There's not much room for improvement left now.

[Bug target/49026] [4.7 Regression] FAIL: gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution test at r173809 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-05-17 
19:05:21 UTC ---
Created attachment 24267
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24267
assembly for r173809 (not working)

[Bug target/49030] New: ICE in get_arm_condition_code, at config/arm/arm.c:17180

[rmansfield at qnx dot com]

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

   Summary: ICE in get_arm_condition_code, at
config/arm/arm.c:17180
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
  Host: x86_64-linux-gnu
Target: arm-unknown-linux-gnueabi
 Build: x86_64-linux-gnu


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

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--disable-multilib
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.7.0 20110517 (experimental) [trunk revision 173832] (GCC) 
$ ./xgcc -B.  -O1 ~/ice.i
/home/ryan/ice.i: In function 'bar':
/home/ryan/ice.i:33:1: internal compiler error: in get_arm_condition_code, at
config/arm/arm.c:17180
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/49026] [4.7 Regression] FAIL: gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution test at r173809 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-05-17 
19:03:55 UTC ---
Created attachment 24266
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24266
assembly for r173808 (working)

[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[rakdver at kam dot mff.cuni.cz]

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

--- Comment #15 from rakdver at kam dot mff.cuni.cz  2011-05-17 19:26:18 UTC ---
Hi,

> The following patch fixes the problem. Is it ok?

as a heuristic, this probably makes sense.  Still, it does
not fix the problem, just masks it and makes it harder to reproduce,

Zdenek

> David
> 
> 
> --- tree-ssa-loop-ivopts.c  (revision 173278)
> +++ tree-ssa-loop-ivopts.c  (working copy)
> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>   int *inv_expr_id)
>  {
>tree ubase = use->iv->base, ustep = use->iv->step;
> -  tree cbase, cstep;
> +  tree cbase, cstep, cbase_strip;
>tree utype = TREE_TYPE (ubase), ctype;
>unsigned HOST_WIDE_INT cstepi, offset = 0;
>HOST_WIDE_INT ratio, aratio;
> @@ -4026,6 +4026,13 @@ get_computation_cost_at (struct ivopts_d
>if (!constant_multiple_of (ustep, cstep, &rat))
>  return infinite_cost;
> 
> +  cbase_strip = STRIP_NOPS (cbase);
> +  /* Avoid confusing aliaser.  */
> +  if (TREE_CODE (cbase_strip) == ADDR_EXPR
> +  && TREE_CODE (TREE_OPERAND (cbase_strip, 0)) == VAR_DECL
> +  && (HOST_WIDE_INT) cstepi < 0)
> +return infinite_cost;
> +
>if (double_int_fits_in_shwi_p (rat))
>  ratio = double_int_to_shwi (rat);
>else
> 
> -- 
> 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 debug/49032] New: -gstabs generates reference to deleted static variable

[arthur.j.odwyer at gmail dot com]

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

   Summary: -gstabs generates reference to deleted static variable
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24272
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24272
Output of "ajo-gcc -w -O1 -gstabs test.c -o a.out -v"

This reproduces for me with svn revision 173589 (2011-05-09). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.

cat >test.c 

[Bug target/42210] avr: optimizing assignment to a bit field

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-05-17 
19:16:45 UTC ---
Created attachment 24269
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24269
Patch against 4.7.0 (r173832)

See also

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02099.html

[Bug other/49031] New: powl() function gives wrong results in some situations

[eliasrudberg at gmail dot com]

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

   Summary: powl() function gives wrong results in some situations
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eliasrudb...@gmail.com


Created attachment 24270
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24270
The powlbug.i file generated by "gcc -v -save-temps -lm powlbug.c".

Hello!

There seems to be a bug in the powl() function in the gcc -lm library, as shown
by the following test program:

$ cat powlbug.c 

#include 
#include 
#include 
int main() {
 long double xx = 1e-20;
 printf("xx = %12.6Lg\n", xx);
 printf("powl(xx, 1.5) = %12.6Lg\n", powl(xx, 1.5));
 if(1) {
  long double a = 0.2;
  long double b;
  char chararr_b[16] = {1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, -16, 63};
  memcpy(&b, chararr_b, 16);
  printf("powl(a, b) = %9.4Lg\n", powl(a, b));
 }
 printf("powl(xx, 1.5) = %12.6Lg\n", powl(xx, 1.5));
 return 0;
}

$ gcc -lm powlbug.c 
$ ./a.out 
xx =1e-20
powl(xx, 1.5) =1e-30
powl(a, b) = 1
powl(xx, 1.5) = 0.353553

Since xx is set to 1e-20, the result of powl(xx, 1.5) should always be 1e-30.
It seems like the powl(a, b) call messes up something inside the math library,
so that the following call powl(xx, 1.5) gives 0.353553 which is very wrong.
If I change if(1) to if(0) the second call to powl(xx, 1.5) gives 1e-30 as it
should.

$ gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)

$ gcc -v -save-temps -lm powlbug.c 
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.5.1/cc1 -E -quiet -v powlbug.c
-mtune=generic -march=x86-64 -fpch-preprocess -o powlbug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.5.1/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.5.1/cc1 -fpreprocessed powlbug.i -quiet
-dumpbase powlbug.c -mtune=generic -march=x86-64 -auxbase powlbug -version -o
powlbug.s
GNU C (GCC) version 4.5.1 20100924 (Red Hat 4.5.1-4) (x86_64-redhat-linux)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.5.1 20100924 (Red Hat 4.5.1-4) (x86_64-redhat-linux)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ea394b69293dd698607206e8e43d607e
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 as -V -Qy --64 -o powlbug.o powlbug.s
GNU assembler version 2.20.51.0.7 (x86_64-redhat-linux) using BFD version
version 2.20.51.0.7-6.fc14 20100318
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/:/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.5.1/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.5.1/:/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.5.1/collect2 --build-id --no-add-needed
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux

[Bug target/33050] [avr] unnessary register save

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gjl at gcc dot gnu.org
  Known to work||4.7.0
 Resolution||WORKSFORME
   Target Milestone|--- |4.7.0
  Known to fail||

--- Comment #6 from Georg-Johann Lay  2011-05-17 
19:30:52 UTC ---
Closing this issue as resolved+worksforme. 4.7.0 generates reasonable code
without any overhead, see Attachement

http://gcc.gnu.org/bugzilla/attachment.cgi?id=24271

generated with -Os (-O1 and -O2) are same.

[Bug target/33050] [avr] unnessary register save

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2011-05-17 
19:28:11 UTC ---
Created attachment 24271
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24271
Assembler output with 4.7.0 r173649

This code is as you expected.

[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[xinliangli at gmail dot com]

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

--- Comment #16 from davidxl  2011-05-17 19:57:01 
UTC ---
This is not really heuristic -- it prevents compiler from generating code in
ivopt that violates the aliasing assumption. 

David

(In reply to comment #15)
> Hi,
> 
> > The following patch fixes the problem. Is it ok?
> 
> as a heuristic, this probably makes sense.  Still, it does
> not fix the problem, just masks it and makes it harder to reproduce,
> 
> Zdenek
> 
> > David
> > 
> > 
> > --- tree-ssa-loop-ivopts.c  (revision 173278)
> > +++ tree-ssa-loop-ivopts.c  (working copy)
> > @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
> >   int *inv_expr_id)
> >  {
> >tree ubase = use->iv->base, ustep = use->iv->step;
> > -  tree cbase, cstep;
> > +  tree cbase, cstep, cbase_strip;
> >tree utype = TREE_TYPE (ubase), ctype;
> >unsigned HOST_WIDE_INT cstepi, offset = 0;
> >HOST_WIDE_INT ratio, aratio;
> > @@ -4026,6 +4026,13 @@ get_computation_cost_at (struct ivopts_d
> >if (!constant_multiple_of (ustep, cstep, &rat))
> >  return infinite_cost;
> > 
> > +  cbase_strip = STRIP_NOPS (cbase);
> > +  /* Avoid confusing aliaser.  */
> > +  if (TREE_CODE (cbase_strip) == ADDR_EXPR
> > +  && TREE_CODE (TREE_OPERAND (cbase_strip, 0)) == VAR_DECL
> > +  && (HOST_WIDE_INT) cstepi < 0)
> > +return infinite_cost;
> > +
> >if (double_int_fits_in_shwi_p (rat))
> >  ratio = double_int_to_shwi (rat);
> >else
> > 
> > -- 
> > 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.