[Bug c++/48872] [C++0x][noexcept] Placement-new problem with non-empty arguments

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  
2011-05-05 07:15:12 UTC ---
(In reply to comment #1)

More information by a different example: It seems that the problem case reacts
very sensitive to minor modifications of the class. The following provides a
slightly different version of the previous example:

//---
#include 

//#define ADD_CTOR

struct U2 {
#ifdef ADD_CTOR
  U2(int) noexcept;
#endif
  ~U2() noexcept(false);
};

template
T&& create() noexcept;

const bool b = noexcept(::new (((void*) 0)) U2(create()));
static_assert(b, "Ouch"); // #
//---

As written, the same static assert violation occurs as in the example provided
by comment 1. But if the line

//#define ADD_CTOR

is uncommented *without any further changes* the program becomes accepted.
Somehow the addition of the user-provided constructor - even though it is not
used here - influences the evaluation of the noexcept expression.

[Bug c++/48873] [C++0x][noexcept] Placement-new problem with deleted destructors

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  
2011-05-05 07:31:21 UTC ---
More information after some analysis: The problem occurs in other unevaluated
contexts as well and it is similarly sensitive to very small modifications of
the class definition as has been demonstrated in bug 48872. Consider the
following alternative test case involving decltype:

//
#include 

//#define ADD_CTOR

struct D {
#ifdef ADD_CTOR
  D();
#endif
  ~D() = delete;
};

template
T&& create();

typedef decltype(::new (((void*) 0)) D(create())) type; // #
//

As written, we get the same error message as before,

"error: use of deleted function 'D::~D()'"

but if we uncomment the line

//#define ADD_CTOR

the program becomes accepted. The user-declared constructor can also be a
non-special member of the class as has been shown in bug 48872. A defaulted
special member again shows the original buggy behaviour.

[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn

[irar at gcc dot gnu.org]

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

--- Comment #6 from irar at gcc dot gnu.org 2011-05-05 07:35:03 UTC ---
Author: irar
Date: Thu May  5 07:34:59 2011
New Revision: 173417

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

Backport from mainline:
2011-04-18  Ulrich Weigand  
Ira Rosen  

PR target/48252
* config/arm/arm.c (neon_emit_pair_result_insn): Swap arguments
to match neon_vzip/vuzp/vtrn_internal.
* config/arm/neon.md (neon_vtrn_internal): Make both
outputs explicitly dependent on both inputs.
(neon_vzip_internal, neon_vuzp_internal): Likewise.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/arm/pr48252.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/arm/arm.c
branches/gcc-4_5-branch/gcc/config/arm/neon.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c/48880] New: regression when performing __builtin_object_size in deep inline chain

[baryluk at smp dot if.uj.edu.pl]

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

   Summary: regression when performing __builtin_object_size in
deep inline chain
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bary...@smp.if.uj.edu.pl


Created attachment 24188
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24188
minimized test case

Hi. My first bug report to gcc :)

$ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6.1/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-6'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6) 


linux (2.6.38) kernel fails to compile when using gcc 4.6. It fails on
binfmt_misc.o compilation.

Minimized test case attached (from 780703 bytes, down to 471  bytes, thanks to
delta)

gcc 4.5.3 works without problem.

gcc 4.6.1 gives:

$ gcc-4.6 -O2 -c binfmt_misc_ultramini.i
binfmt_misc_ultramini.i: In function ‘p.part.0’:
binfmt_misc_ultramini.i:8:14: error: call to ‘c_overflow’ declared with
attribute error: c() buffer size is not provably correct
$

Regression dissapear when i use -O3 or -finline-functions optimization. Also
problem disapears when i subtelly change minimized test case. Thus it is
problem with inliner.


Regards,
Witek

[Bug c/48880] regression when performing __builtin_object_size in deep inline chain

[baryluk at smp dot if.uj.edu.pl]

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

--- Comment #1 from Witold Baryluk  2011-05-05 
08:16:54 UTC ---
In original source a c function have this signature:

static inline __attribute__((always_inline)) unsigned long
__attribute__((warn_unused_result)) copy_from_user(void *to, const void *from,
unsigned long n)

but putting back inline or __attribute__((always_inline)) (or both) do not
change anything.

[Bug c++/48879] Compilation cannot find file asm/errno.h

[mancilla at cse dot unsw.edu.au]

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

--- Comment #1 from Blanca Mancilla  
2011-05-05 08:48:29 UTC ---
I succeeded in compiling by serring the following environment variables:

export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/x86_64-linux-gnu

is this the right way?

Blanca

(In reply to comment #0)
> Hi,
> I recently upgraded from Ubuntu 10.10 to 11.04, and upon the first attempted
> compilation of 4.7.0, it crashed complaining of:
> 
> --
> In file included from /usr/include/bits/errno.h:25:0,
>  from /usr/include/errno.h:36,
>  from
> /home/mancilla/current/soft/src/gcc-build-latest/../gcc-svn/libgcc/../gcc/tsystem.h:93,
>  from
> /home/mancilla/current/soft/src/gcc-build-latest/../gcc-svn/libgcc/../gcc/libgcc2.c:29:
> /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or
> directory
> compilation terminated.
> ake[3]: *** [_muldi3.o] Error 1
> make[3]: Leaving directory
> `/home/mancilla/current/soft/src/gcc-build-latest/x86_64-unknown-linux-gnu/libgcc'
> make[2]: *** [all-stage1-target-libgcc] Error 2
> make[2]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make: *** [all] Error 2
> 
> ---
> 
> After much browsing mailing lists and bug reports everywhere, it seems that 
> the
> problem lies on the linux headers (?). The directory in question used to be
> /usr/include/linux and in my case it is now /usr/include/x86_64-linux-gnu.
> After following sugestions, I tried setting CPPFLAGS, CFLAGS and CXXFLAGS to
> -I/usr/include/x86_64-linux-gnu and then "-isystem
> /usr/include/x86_64-linux-gnu" when calling configure and the result was: at
> first CPPFLAGS was ignored and the same error accurred (setting CPPFLAGS). 
> Then
> stage 1 completed and the same error occurred at the begining of stage 2
> (setting just CFLAGS). Setting both CFLAGS nad CXXFLAGS got the compilation
> further, but still a similar error. In this last attempt, it did not make a
> difference whether
> it was -I or -isystem:
> 
> 
> 
> In file included from /usr/include/bits/errno.h:25:0,
>  from /usr/include/errno.h:36,
>  from
> /home/mancilla/current/soft/src/gcc-build-latest/../gcc-svn/libiberty/fnmatch.c:46:
> /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or
> directory
> compilation terminated.
> make[3]: *** [fnmatch.o] Error 1
> make[3]: Leaving directory
> `/home/mancilla/current/soft/src/gcc-build-latest/libiberty'
> make[2]: *** [all-stage2-libiberty] Error 2
> make[2]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make: *** [all] Error 2
> 
> -
> 
> I'm not too sure it this is the right place for reporting this. But it seems
> that the compilation needs to know where is errno.h. Please let me know if it
> is necessary to attach the full log of the build.
> 
> Any advice would be greatfully appreciated. 
> 
> Regards,
> Blanca

[Bug c/48880] regression when performing __builtin_object_size in deep inline chain

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.05 08:49:13
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-05-05 
08:49:13 UTC ---
The testcase is quite questionable, and the reason it "fails" with gcc 4.6 is
partial inlining.  Related to PR46639, again being able to run VRP through the
body of the partially inlined fn before handling the p.part.0 VRP would fix
this.
In *.fnsplit p is:
p (unsigned int n)
{
  int D.2699;
:
  if (n_2(D) == 0)
goto ;
  else
goto ;
:
  if (n_2(D) > 3)
goto ;
  else
goto ;
:
  D.2699_9 = p.part.0 (n_2(D));
:
  # D.2699_1 = PHI <0(2), -22(3), D.2699_9(4)>
  return D.2699_1;
}
so if VRP would figure out that p.part.0's first argument has range [1, 3], it
could optimize away the test in p.part.0.

[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn

[irar at gcc dot gnu.org]

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

--- Comment #7 from irar at gcc dot gnu.org 2011-05-05 08:39:47 UTC ---
Author: irar
Date: Thu May  5 08:39:40 2011
New Revision: 173418

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

Backport from mainline:
2011-04-18  Ulrich Weigand  
Ira Rosen  

PR target/48252
* config/arm/arm.c (neon_emit_pair_result_insn): Swap arguments
to match neon_vzip/vuzp/vtrn_internal.
* config/arm/neon.md (neon_vtrn_internal): Make both
outputs explicitly dependent on both inputs.
(neon_vzip_internal, neon_vuzp_internal): Likewise.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr48252.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.c
branches/gcc-4_6-branch/gcc/config/arm/neon.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Ira Rosen  2011-05-05 08:40:53 UTC 
---
Fixed on 4.5, 4.6 and 4.7.

[Bug c++/48879] Compilation cannot find file asm/errno.h

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-05-05 
09:11:44 UTC ---
Shouldn't this be Component=bootstrap not c++ ?

I assume the linux-libc-dev package is installed? That provides asm/errno.h

What compiler are you using to bootstrap? If it's the standard system compiler
it should know to look in /usr/include/x86_64-linux-gnu, if not then it's a bug
in the Ubuntu gcc package

What is the output of "gcc -v -x c /dev/null -c" ?

[Bug libstdc++/48881] New: Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[astrand at cendio dot se]

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

   Summary: Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll
produces broken binaries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: astr...@cendio.se


We have been using GCC 4.4.3 with MinGW, producing binaries for Win32,
with good results. After upgrading to 4.5.2, libstdc++-6.dll and
libgcc_s_sjlj-1.dll have been added, but linking dynamically to these
does not work: All binaries crashes immediately at startup. Simply
deleting the DLL files from the build environment avoids the dynamic
link, and the binaries works. We are configuring gcc with:

./configure \
--prefix=/usr --mandir=/usr/share/man \
--target=i686-pc-mingw32 --disable-multilib \
--with-sysroot=/usr/i686-pc-mingw32/sys-root \
--disable-nls --disable-win32-registry \
--without-included-gettext \
--with-gnu-as --with-gnu-ld \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-threads=win32 --enable-languages=c,c++

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[ramana at gcc dot gnu.org]

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

--- Comment #10 from Ramana Radhakrishnan  
2011-05-05 09:52:18 UTC ---
Author: ramana
Date: Thu May  5 09:52:12 2011
New Revision: 173421

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

For Michael Hope.

2011-05-05  Michael Hope  

   PR pch/45979
   * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for
   __ARM_EABI__ hosts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/host-linux.c

[Bug c/48880] regression when performing __builtin_object_size in deep inline chain

[baryluk at smp dot if.uj.edu.pl]

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

--- Comment #3 from Witold Baryluk  2011-05-05 
09:55:25 UTC ---
In my case it only happens if I have two independent calls with different
arguments. I do not understand some aspects, but removing some semingly
unrelated things or adding some dummy variable write, make bug disapear. 

It shouldn't matter, but maybe VRP information is somehow cached for each
block, and this caching do not takes into accout some additional informations?

It looks very similar to PR46639 - in original test case I even had program
with structure somehow similar to one from PR46639 (assigning a pointer
function to the static global variable), but after minimizing it further I
removed it and failure still occurs.

As of figuring out that at  a n_2(D) is in range [1, 3] isn't hard. It
can be done both in forward as well a backward manner. (but of course VRP works
by propgating forward, but does it consider separetly all data paths?)

I know it isn't bug, but is regression and gcc isn't doing properly VRP or
inlineing somewhere probably. I reported it only because kernel failed to
compile :) And AFAIK linux kernel uses extensively static checks for things
like memset, memcpy, copy_from_user, etc., to make sure all calls call them
with legth/count/size not bigger than actual buffer size to which they are
writing or reading. I of course can compile linux kernel by unseting proper
CONFIG_* in kernel configuration.

It is also quite important as it could remove significant amount of dead code
after partial inlineing.

[Bug c/42544] Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  2011-05-05 
10:27:04 UTC ---
Fixed for 4.6+.

[Bug c++/48870] operator== overload of vector types

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2011-05-05 
10:27:32 UTC ---
No, it can't be fixed.  You have to provide a wrapper yourself.

[Bug c++/48871] gcc doesn't accept null pointer value as a template non-type argument

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-05-05 
10:29:50 UTC ---
.

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

[Bug c++/10541] [DR 354] Is NULL a valid pointer-type template argument?

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||boostcpp at gmail dot com

--- Comment #10 from Richard Guenther  2011-05-05 
10:29:50 UTC ---
*** Bug 48871 has been marked as a duplicate of this bug. ***

[Bug debug/48843] ICE in dwarf2out_var_location, at dwarf2out.c:22585 with pragma GCC optimize

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Target||mips-linux-gnu
 CC||echristo at apple dot com,
   ||rdsandiford at googlemail
   ||dot com

--- Comment #1 from Bernhard Reutner-Fischer  
2011-05-05 10:33:28 UTC ---
jakub: most likely mips backend reshuffles stuff after var-tracking; if it does
so, it needs to be fixed not to insert anything in between a call and following
call arg note
jakub: see http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171156 for
corresponding s390 fix, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171185
for sh, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171193 for arm fix

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2011-05-05 
10:27:16 UTC ---
Fixed for 4.6+.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

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

--- Comment #51 from Lionel GUEZ  
2011-05-05 10:46:21 UTC ---
> It is PR48787 and a patch has been submitted for approval. It is fixed on my 
> development trunk.

Hello. I do not understand: you say that there is a patch submitted for
approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5.

[Bug c++/48879] Compilation cannot find file asm/errno.h

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther  2011-05-05 
10:43:54 UTC ---
This is an Ubuntu packaging issue (or you lack some package), not a GCC issue,
as errno.h is a standard header.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

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

--- Comment #50 from Lionel GUEZ  
2011-05-05 10:42:31 UTC ---
> Can you please provide a short example program, and what version of GFortran
> you are using?
> 
> I cannot reproduce the described bug with GFortran 4.4.5 nor with 
> 4.7-20110430.
> Your expected result is correctly produced by the program:
> 
> print "(1pg7.1)", 0.96
> end
> 
> => 1.

Here is the test on my machine:

$ gfortran --version
GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

$ cat short_test.f90 
print "(1pg7.1)", 0.96
end

$ gfortran short_test.f90 

$ a.out
 0.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

[thenlich at users dot sourceforge.net]

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

--- Comment #13 from Thomas Henlich  
2011-05-05 10:57:33 UTC ---
G95 is actually using this method for list-directed output.

print *, .3, .33, .333, ., .3, .33, .333
g95 =>  0.3 0.33 0.333 0. 0.3 0.33 0.333
gfortran => 0.30012 0.33013 0.33304 0.33324 0.30005
0.32986 0.33313

From ftoa.c:


/* All software © 1996 Robert G. Burger.  Permission is hereby granted,
...
 * This code is described in an article by Robert G. Burger and
 * R. Kent Dybvig in "Proceedings of the ACM SIGPLAN '96 Conference on
 * Programming Language Design and Implementation", pages 108-116, May
 * 1996.
 *
 * Modified for use with g95 by Andy Vaught.  Thanks Bob!
 */

[Bug tree-optimization/46639] [4.6/4.7 Regression] Missing optimization due to function splitting and redundant conditionals

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-05-05 
11:03:23 UTC ---
Another testcase:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=24188
Richard suggests running pass_vrp_early instead of (or in addition to) pass_ccp
with some more expensive parts of VRP disabled.

[Bug tree-optimization/48880] regression when performing __builtin_object_size in deep inline chain

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|c   |tree-optimization
 Resolution||DUPLICATE

--- Comment #4 from Jakub Jelinek  2011-05-05 
10:56:28 UTC ---
Dup of PR46639

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

[Bug tree-optimization/46639] [4.6/4.7 Regression] Missing optimization due to function splitting and redundant conditionals

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||baryluk at smp dot
   ||if.uj.edu.pl

--- Comment #7 from Jakub Jelinek  2011-05-05 
10:56:28 UTC ---
*** Bug 48880 has been marked as a duplicate of this bug. ***

[Bug c++/48875] Segmentation fault in maybe_clone_body with -fsyntax-only

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.05 10:35:35
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-05-05 
10:35:35 UTC ---
Confirmed.  I think similar to the caller maybe_clone_body should guard
output related stuff with !flag_synatx_only.

[Bug c++/48882] New: ?: ternary operator fails in certain contexts - compile error

[adele.schmidthammer at yahoo dot de]

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

   Summary: ?: ternary operator fails in certain contexts -
compile error
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adele.schmidtham...@yahoo.de


#include // std::max  std::min
#include

int main() {
   int a = 1000;
   int b = 2000;
   bool even = true;
   const int& (*fp)(const int&, const int&);
   fp = even ? std::max : std::min;  /* does not compile! */
   std::cout << fp(a,b) << std::endl;
}

Error message: insufficient contextual information to determine type

however
 if(even) fp = std::max;
 else fp = std::min;

works as expected:

Output of compilation:
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=/home/me/programme/gcc47/bin/g++
COLLECT_LTO_WRAPPER=/home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Ziel: i686-pc-linux-gnu
Konfiguriert mit: ./configure --prefix=/home/me/programme/gcc47
Thread-Modell: posix
gcc-Version 4.7.0 20110430 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 /home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/cc1plus -E -quiet
-v -D_GNU_SOURCE bug1.cpp -mtune=generic -march=pentiumpro -std=c++0x -Wall
-fpch-preprocess -o bug1.ii
nicht vorhandenes Verzeichnis
»/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../i686-pc-linux-gnu/include«
wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/i686-pc-linux-gnu

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/include
 /usr/local/include
 /home/me/programme/gcc47/include
 /home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/include-fixed
 /usr/include
Ende der Suchliste.
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 /home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/cc1plus
-fpreprocessed bug1.ii -quiet -dumpbase bug1.cpp -mtune=generic
-march=pentiumpro -auxbase bug1 -Wall -std=c++0x -version -o bug1.s
GNU C++ (GCC) Version 4.7.0 20110430 (experimental) (i686-pc-linux-gnu)
kompiliert von GNU-C-Version 4.7.0 20110430 (experimental), GMP-Version
5.0.1, MPFR-Version 3.0.0-p3, MPC-Version 0.8.2.
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) Version 4.7.0 20110430 (experimental) (i686-pc-linux-gnu)
kompiliert von GNU-C-Version 4.7.0 20110430 (experimental), GMP-Version
5.0.1, MPFR-Version 3.0.0-p3, MPC-Version 0.8.2.
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c95befb475332395eb1695ad61c47f68
bug1.cpp: In Funktion »int main()«:
bug1.cpp:19:38: Fehler: insufficient contextual information to determine type
bug1.cpp:19:38: Fehler: insufficient contextual information to determine type

[Bug c++/48883] New: ?: ternary operator fails in certain contexts - link error

[adele.schmidthammer at yahoo dot de]

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

   Summary: ?: ternary operator fails in certain contexts - link
error
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adele.schmidtham...@yahoo.de


probably there is a relation to bug 48882

I do not attach the precompiled file (.ii), because it is too big.

#include // std::max  std::min
#include

template
const T& myMin(const T& a, const T& b) {
   if(a < b) return a;
   return b;
}
template
const T& myMax(const T& a, const T& b) {
   if(a > b) return a;
   return b;
}

int main() {
   int a = 1000;
   int b = 2000;
   bool even = true;
   const int& (*fp)(const int&, const int&);
   fp = even ? myMax : myMin;   /* yields link error */
std::cout << fp(a,b) << std::endl;
}

does not link. Output :

Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=/home/me/programme/gcc47/bin/g++
COLLECT_LTO_WRAPPER=/home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Ziel: i686-pc-linux-gnu
Konfiguriert mit: ./configure --prefix=/home/me/programme/gcc47
Thread-Modell: posix
gcc-Version 4.7.0 20110430 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 /home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/cc1plus -E -quiet
-v -D_GNU_SOURCE bug2.cpp -mtune=generic -march=pentiumpro -std=c++0x -Wall
-fpch-preprocess -o bug2.ii
nicht vorhandenes Verzeichnis
»/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../i686-pc-linux-gnu/include«
wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/i686-pc-linux-gnu

/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/include
 /usr/local/include
 /home/me/programme/gcc47/include
 /home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/include-fixed
 /usr/include
Ende der Suchliste.
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 /home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/cc1plus
-fpreprocessed bug2.ii -quiet -dumpbase bug2.cpp -mtune=generic
-march=pentiumpro -auxbase bug2 -Wall -std=c++0x -version -o bug2.s
GNU C++ (GCC) Version 4.7.0 20110430 (experimental) (i686-pc-linux-gnu)
kompiliert von GNU-C-Version 4.7.0 20110430 (experimental), GMP-Version
5.0.1, MPFR-Version 3.0.0-p3, MPC-Version 0.8.2.
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) Version 4.7.0 20110430 (experimental) (i686-pc-linux-gnu)
kompiliert von GNU-C-Version 4.7.0 20110430 (experimental), GMP-Version
5.0.1, MPFR-Version 3.0.0-p3, MPC-Version 0.8.2.
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c95befb475332395eb1695ad61c47f68
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 as --32 -o bug2.o bug2.s
COMPILER_PATH=/home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/:/home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/:/home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/:/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/:/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/:/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
 /home/me/programme/gcc47/libexec/gcc/i686-pc-linux-gnu/4.7.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/crtbegin.o
-L/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0
-L/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/../../.. bug2.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/me/programme/gcc47/lib/gcc/i686-pc-linux-gnu/4.7.0/crtend.o
/usr/lib/crtn.o
bug2.o: In function `main':
bug2.cpp:(.text+0x26): undefined reference to `int const& myMax(int
const&, int const&)'
bug2.cpp:(.text+0x2d): undefined reference to `int const& myMin(int
const&, int const&)'
collect2: ld gab 1 als Ende-Status zurück

[Bug c++/48882] ?: ternary operator fails in certain contexts - compile error

[adele.schmidthammer at yahoo dot de]

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

--- Comment #1 from Adele Schmidt  
2011-05-05 11:37:33 UTC ---
no attachment, because precompiled file (extension .ii) was too big

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  2011-05-05 
11:54:12 UTC ---
I think the problem is that the debug stmts are being expanded into debug insns
*before* the code that should precede them.  If we expanded the stmts in the
natural, expended order, we'd get the variables bound to simpler expressions. 
That said, I'm not sure this will avoid the cselib slowdown, for we will likely
end up having to use the mems as a location.  Investigating...

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[adele.schmidthammer at yahoo dot de]

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

--- Comment #1 from Adele Schmidt  
2011-05-05 11:49:25 UTC ---
However

 if(even) fp = myMax;
 else fp = myMin;

does work as expected.

[Bug c++/48884] New: decltype's operand doesn't consider friend declaration

[boostcpp at gmail dot com]

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

   Summary: decltype's operand doesn't consider friend declaration
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com


decltype's operand doesn't consider friend declaration if it's used as a return
type of the function.
Following code failed.

class X
{
int value ;
friend class Y ;
} ;

class Y
{
public :
template < typename T >
static auto f(T t) -> decltype( t.value )
{
return t.value ; // OK. Y is a friend of X.
}
} ;

int main()
{
X x ;
Y::f(x) ; // gcc issues error
}

The error message is 

In function 'int main()':
error: 'int X::value' is private
 error: within this context

It looks like access checking is done in the main rather than Y::f.

[Bug rtl-optimization/48381] [4.7 Regression] internal compiler error: in check_allocation, at ira.c:2094

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-05-05 
12:05:48 UTC ---
Author: jakub
Date: Thu May  5 12:05:42 2011
New Revision: 173427

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173427
Log:
PR rtl-optimization/48381
* gcc.c-torture/compile/pr48381.c: New test.

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

[Bug rtl-optimization/48381] [4.7 Regression] internal compiler error: in check_allocation, at ira.c:2094

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |vmakarov at gcc dot gnu.org
   |gnu.org |

--- Comment #6 from Jakub Jelinek  2011-05-05 
12:09:16 UTC ---
Fixed.

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.05 12:15:05
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2011-05-05 
12:15:05 UTC ---
reduced:

template
T myMax(T a, T b) {
   if(a < b) return a;
   return b;
}

int main() {
   bool even = true;
   int (*fp)(int, int);
   fp = even ? myMax : myMax;   /* yields link error */
}


The function template specialization should be implicitly instantiated

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  2011-05-05 12:11:02 
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > neither 0PFw.d nor 1PEw.dEe allow it). However, AFAICS leading blanks are 
> > still
> > allowed as they are part of the real parts, the prohibition against embedded
> > blanks in the complex output refer only to blanks other than the ones 
> > present
> > in the real fields, no?
> 
> As much as I'd like to, I cannot agree:
> 
> "The only embedded blanks permitted within a complex constant are between the
> separator and the end of a record and one blank at the beginning of the next
> record."
> 
> An "embedded blank within a complex constant" is any blank which neither leads
> the complex constant nor trails it; in other words, any space between the left
> and the right parenthesis. It is not permitted, except around record breaks.

Thinking about this some more, I think you're right. If not, the processor
could after all choose w such that any amount of leading blanks are present,
thus rendering more or less the entire rule forbidding embedded blanks (except
at those 2 specified locations if the constant straddles a record boundary)
meaningless.

I asked c.l.f, lets see if someone knowledgeable disagrees..

> If it is important, we can still ensure the tabular alignment of complex 
> fields
> by right-flushing them in a field of width 2*w+3, where w is the width for a
> real constant.

Yes, I suppose this is what must be done.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at frontier dot com]

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

--- Comment #6 from jvdelisle at frontier dot com 2011-05-05 12:28:01 UTC ---
On 05/05/2011 12:04 AM, thenlich at users dot sourceforge.net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
---snip---
> As much as I'd like to, I cannot agree:
>
> "The only embedded blanks permitted within a complex constant are between the
> separator and the end of a record and one blank at the beginning of the next
> record."

I am a little concerned.  The above says 'constant'.  Does this mean a complex 
'variable' is output differently? Right now, the runtime libarary has no way to 
know the difference. We do have a control bit we can set before and after the 
transfer and we could have the frontend insert this for a complex constant.  It 
just seems odd that one would treat a constant differently from a variable so I 
am seeking clarity here.

Also, See below.  Does this give the expected output?

print *, (1.0, 0.0)
end

$ ./a.out
  (1.,.)

Index: write.c
===
--- write.c(revision 173411)
+++ write.c(working copy)
@@ -1509,15 +1509,15 @@
  {
char semi_comma =
  dtp->u.p.current_unit->decimal_status == DECIMAL_POINT ? ',' : ';';
-
if (write_char (dtp, '('))
  return;
+  dtp->u.p.g0_no_blanks = 1;
write_real (dtp, source, kind);

if (write_char (dtp, semi_comma))
  return;
write_real (dtp, source + size / 2, kind);
-
+  dtp->u.p.g0_no_blanks = 0;
write_char (dtp, ')');
  }

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #52 from jvdelisle at frontier dot com 2011-05-05 12:30:38 UTC ---
On 05/05/2011 04:01 AM, ebay.20.tedlap at spamgourmet dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
>
> --- Comment #51 from Lionel GUEZ  
> 2011-05-05 10:46:21 UTC ---
>> It is PR48787 and a patch has been submitted for approval. It is fixed on my
>> development trunk.
>
> Hello. I do not understand: you say that there is a patch submitted for
> approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5.
>
I thought what you were seeing was part of what we have just been fixing.  It
is 
possible that it is an old bug we fixed a while back.

[Bug c++/48884] decltype's operand doesn't consider friend declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.05 12:35:32
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-05-05 
12:35:32 UTC ---
confirmed

if Y::f is not a template then access checking succeeds

here's a C++03 version, which fails in the same way:

class X
{
int value ;
friend class Y ;
} ;

template  struct Int { };

class Y
{
public :
template < typename T >
static Int f(T t)
{
return Int();
}
} ;

int main()
{
X x ;
Y::f(x) ; // gcc issues error
}

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #53 from Jerry DeLisle  2011-05-05 
12:35:46 UTC ---
The test:

print "(1pg7.1)", 0.96
end


Fails in 4.4 and works in 4.5, so this confirms it was fixed quite a while ago.
 I strongly suggest you upgrade your gfortran.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist  2011-05-05 12:44:42 
UTC ---
(In reply to comment #6)
> On 05/05/2011 12:04 AM, thenlich at users dot sourceforge.net wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
> ---snip---
> > As much as I'd like to, I cannot agree:
> >
> > "The only embedded blanks permitted within a complex constant are between 
> > the
> > separator and the end of a record and one blank at the beginning of the next
> > record."
> 
> I am a little concerned.  The above says 'constant'.  Does this mean a 
> complex 
> 'variable' is output differently? Right now, the runtime libarary has no way 
> to 
> know the difference. We do have a control bit we can set before and after the 
> transfer and we could have the frontend insert this for a complex constant.  
> It 
> just seems odd that one would treat a constant differently from a variable so 
> I 
> am seeking clarity here.

I was a bit confused by this as well, but it seems it's just a strangely named
term the standard uses for "the character representation of the IO list element
in the unit the data transfer statement refers to", or something like that. So
it doesn't have anything to do with what one would ordinarily consider a
constant in a programming language (in Fortran, PARAMETER).

> Also, See below.  Does this give the expected output?
> 
> print *, (1.0, 0.0)
> end
> 
> $ ./a.out
>   (1.,.)
> 
> Index: write.c
> ===
> --- write.c(revision 173411)
> +++ write.c(working copy)
> @@ -1509,15 +1509,15 @@
>   {
> char semi_comma =
>   dtp->u.p.current_unit->decimal_status == DECIMAL_POINT ? ',' : ';';
> -
> if (write_char (dtp, '('))
>   return;
> +  dtp->u.p.g0_no_blanks = 1;
> write_real (dtp, source, kind);
> 
> if (write_char (dtp, semi_comma))
>   return;
> write_real (dtp, source + size / 2, kind);
> -
> +  dtp->u.p.g0_no_blanks = 0;
> write_char (dtp, ')');
>   }

This looks like a good start, I was thinking of something similar myself.  As
Thomas says, we might want to right-justify this in a field of (per type/kind)
constant width in order to guarantee aligned columns, like we do for other
types.

[Bug c/48885] New: missed optimization with restrict qualifier?

[jerome.frgacic at yahoo dot fr]

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

   Summary: missed optimization with restrict qualifier?
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jerome.frga...@yahoo.fr


Hello,

I recently experiment the optimizations obtained by using the restrict
qualifier introduced by the C99 standard. In this purpose, I used this trivial
exemple:

#include 
#include 


void
test (int *a, int *b, int * restrict v)
{
*a = *v;
*b = *v;
}


int
main (void)
{
int a;
int b;
int v = 10;

test (&a, &b, &v);
return EXIT_SUCCESS;
}

If i compiled it with the -S and -O2 options, I obtained for the "test"
function:

movl(%rdx), %eax
movl%eax, (%rdi)
movl(%rdx), %eax
movl%eax, (%rsi)

However, if I had correctly understand the meaning of a restrict pointer, we
can normally expect in the "test" function that the object pointed to by "v"
cannot be changed through "a" or "b"; and therefore perform only one load, like
this:

movl(%rdx), %eax
movl%eax, (%rdi)
movl%eax, (%rsi)

But, the optimization only operate if all the pointers are restrict qualified.
Why?


PS: I compile with GCC 4.6 (Debian amd64 unstable package).

[Bug debug/48886] VTA issues with > word size integers

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-05-05 
12:58:33 UTC ---
s/27/28/ of course, sorry.

[Bug libfortran/48878] Default I/O rounding on output should be round to nearest

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #1 from Jerry DeLisle  2011-05-05 
12:51:49 UTC ---
"A processor is free to select any I/O rounding mode for the default mode. The
mode might correspond to UP, DOWN, ZERO, NEAREST, or COMPATIBLE; or it might be
a completely different I/O rounding mode.'

I think the standard has a funny way of telling people not to rely on default
rounding modes, i.e. be explicit if it matters. This will do it.  I am OK with
nearest

Index: write_float.def
===
--- write_float.def(revision 173411)
+++ write_float.def(working copy)
@@ -236,6 +236,8 @@
 if (!sign_bit)
   goto skip;
 goto updown;
+  case ROUND_PROCDEFINED:
+  case ROUND_UNSPECIFIED:
   case ROUND_NEAREST:
 /* Round compatible unless there is a tie. A tie is a 5 with
all trailing zero's.  */
@@ -263,8 +265,6 @@
   }
   }
  /* Fall through.  */ 
-  case ROUND_PROCDEFINED:
-  case ROUND_UNSPECIFIED:
   case ROUND_COMPATIBLE:
 rchar = '5';
 goto do_rnd;

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  2011-05-05 
12:59:35 UTC ---
Created attachment 24189
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24189
Patch that works around the problem

It is TER that considers the loads as replaceable and ends up moving the entire
computation past the debug stmts.  Considering that MEMs are the reason for the
inefficiency in cselib, and I don't think replacing loads into addresses of
other loads brings us much (any?) benefit, I came up with this hack that fixes
the problem.

We can't really use the incoming argument for debug info very long: it dies at
the first use.  So, even though this patch keeps the debug insns at the
expected place, and we bind the user variables properly, the binding of y
doesn't survive: the value stored in it dies at the first use, on the next
insn, and we can't construct an expression based on a chain of MEMs because (as
mentioned above) the incoming argument, which held the address of the first
MEM, is already dead.

With this patch, the expression stored in z is still regarded as replaceable,
so the debug insn is bound to a MEM before the load, but after var-tracking,
another location expression is emitted with the REG into which the MEM is
loaded.

[Bug debug/48886] New: VTA issues with > word size integers

[jakub at gcc dot gnu.org]

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

   Summary: VTA issues with > word size integers
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org, tro...@gcc.gnu.org


The http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00403.html
typeddwarf.c testcase is going to fail on i?86 with gdb supporting typed DWARF
stack.  The above mentioned patch should fix the 3 vars in f4, but n and o vars
in f2 still have no location info.  More detailed testcase:
/* { dg-options "-g" } */

volatile int vv;
volatile long long vv2;

__attribute__((noinline, noclone)) void
foo (long long x)
{
  float f = x;
  vv = x;/* { dg-final { gdb-test 10 "f" "7" } } */
}

__attribute__((noinline, noclone)) void
bar (long long x)
{
  float f = x;
  vv = x;/* { dg-final { gdb-test 17 "f" "7" } } */
  vv2 = x * 2;
  vv = x;/* { dg-final { gdb-test 19 "f" "7" } } */
}

__attribute__((noinline, noclone)) void
baz (long long x)
{
  float f = x;
  vv = x;/* { dg-final { gdb-test 26 "f" "7" } } */
  vv2 = x * 2;
  vv++;/* { dg-final { gdb-test 27 "f" "7" } } */
}

int
main ()
{
  foo (7LL);
  bar (7LL);
  baz (7LL);
  return 0;
}

Here the parameter isn't completely unused (happens much more often in
real-world).  So, the references to the long long parameter where sizeof (long
long) > sizeof (word) are initially DImode pseudos which is loaded from DImode
MEM (DECL_INCOMING_RTL). During jump and its delete_trivially_dead_in nothing
relevant is deleted, then comes subreg1 pass and splits the DImode load into
two SImode loads and leaves (concatn:DI [(reg:SI x) (reg:SI y)]) in the
debug_insn.
During CSE1 or so fast DCE is performed and just removes the second load to
(reg:SI y), as that register is unused.  Later on DF resets the debug insn
because (reg:SI y) is mentioned just in debug insns and nowhere else.

To fix foo, we could either call delete_trivially_dead_insns at the end of
subreg1 pass if it did any work (tried that and works), or perhaps teach fast
DCE to also create debug temporaries like delete_trivially_dead_insns (not sure
how hard that would be).  That still isn't enough to fix foo (and n/o vars in
f2 from typeddwarf.c), we'd also need to handle CONCATN in mem_loc_descriptor,
at least the easy case where it has MODE_INT mode twice as big as MODE_INT
modes of the parts and the parts are at least word sized, then we could expand
it either to a left shift and plus/or, or in some special cases like in the
testcase two consecutive MEMs to just a single MEM or two consecutive regs to
just a single reg.  Consecutive would need to respect WORDS_BIG_ENDIAN I guess.

In baz it is even more problematic, the debug_insn references DImode %eax:%edx,
but as *.split2 pass splits the DImode %eax:%edx = mem:DI load into separate
loads into SImode %eax and %edx, var-tracking doesn't figure out that %eax:%edx
is the same value at that point as the mem:DI content which isn't modified.
So, when %eax:%edx DImode register is clobbered (during x * 2 computation), f
is said to be optimized out afterwards, while it is also live in the MEM.
Wonder if var-tracking shouldn't try to split 2 * word MODE_INT regs into
CONCATN (if dwarf2out handles it) or into shift + plus/ior.

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

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] SELECT TYPE:  Associate name shall not be a
pointer/allocatable
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org, do...@gcc.gnu.org


>From F2008, 16.5.1.6 Construct association:

"If the selector is allocatable, it shall be allocated; the associate name is
associated with the data object and does not have the ALLOCATABLE attribute.

"If the selector has the POINTER attribute, it shall be associated; the
associate name is associated with the target of the pointer and does not have
the POINTER attribute."


However, gfortran accepts the following, ifort and NAG don't.

It works if the associate name is explicitly given using "associate-name =>
selector"; however, it does not change the POINTER/ALLOCATABLE issue as: "The
associate name of a SELECT TYPE construct is the associate-name if specified;
otherwise it is the name that constitutes the selector."


type t
end type t
class(t), allocatable :: alloc
class(t), pointer :: ptr

select type(alloc)
type is (t)
  allocate(alloc) ! INVALID: "alloc" is not allocatable
end select

select type(ptr)
type is (t)
  nullify(ptr) ! INVALID: "ptr" is not a pointer
end select

end

For an longer example, see 
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/88b65a2c9024e95f

[Bug debug/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013

[rmansfield at qnx dot com]

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

--- Comment #4 from Ryan Mansfield  2011-05-05 
13:19:43 UTC ---
The issue with ARM/SH/S390 backends appears to be there was a literal pool
split happening in between a call insn and the NOTE_INSN_CALL_ARG_LOCATION. It
looks like on mips the issue, at least for my testcase, is the gp store in
mips_split_call is getting emitted in between the call insn and the note.

(call_insn 39 5 40 (parallel [
(set (reg:SI 2 $2)
(call (mem:SI (reg:SI 25 $25 [196]) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
(clobber (reg:SI 28 $28))
]) /home/ryan/ice.i:2 575 {call_value_split}
 (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 79 $fakec))
(expr_list:REG_DEP_TRUE (use (reg:SI 28 $28))
(nil

(insn 40 39 32 (set (reg:SI 28 $28)
(mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 16 [0x10])) [0 S4 A32])) /home/ryan/ice.i:2 280
{*movsi_internal}
 (nil))

(note 32 40 7 (expr_list:REG_DEP_TRUE (concat:SI (reg:SI 79 $fakec)
(reg:SI 79 $fakec))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 28 $28)
(reg:SI 28 $28))
(nil))) NOTE_INSN_CALL_ARG_LOCATION)

[Bug rtl-optimization/48888] New: Creating a copy variable simplify assembly - i686-pc-linux-gnu

[etienne_lorrain at yahoo dot fr]

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

   Summary: Creating a copy variable simplify assembly -
i686-pc-linux-gnu
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


Hello,

Compiling the following C code on GCC-4.6.0 with or without BAD defined leads
to a different
assembly generated, more specifically 
$ /home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S tmp.c -o
tmp.s -DBAD
generates near the end of tmp.s:
movlUI_function, %edx
movb%al, (%esp)
call*%edx
and compiling with:
$ /home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S tmp.c -o
tmp.s
generates the simplest assembly:
movb%al, (%esp)
call*UI_function
$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/etienne/projet/toolchain/bin/gcc
COLLECT_LTO_WRAPPER=/home/etienne/projet/toolchain/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c --with-gmp=/home/etienne/projet/toolchain
--disable-multilib --disable-threads --enable-tls
Thread model: single
gcc version 4.6.0 (GCC)

Unfortunately for me I need to post-process those "call *UI" to replace them by
"lcallw *UI",
and "lcallw *%edx" do not work - anyway I have the solution for those few
cases.
This problem is not new (seen at least in 4.5) and appears unfrequently, but it
seems that
something strange is going on, the two version should generate the same
assembly...

struct attribute_str {
unsigned char underline :1;
unsigned char reverse   :1;
unsigned char blink :1;
unsigned char other :5;
} __attribute__ ((packed)) UI_attributes_current;

struct user_interface_fct_str {
void (*setattribute) (struct attribute_str attr);
void (*putstr) (const char *str);
} UI_function;

extern unsigned UI_parameter_nbcol;

void print (const char *src, unsigned active, unsigned row, unsigned col)
  {
  char displayed[UI_parameter_nbcol], *dst = displayed;

  if (!src)
  return;
  for (;;) {
  if (!active && *src == '<')
  *dst++ = '(';
else
  *dst++ = *src;
  if (*src++ == '\0')
  break;
  }

  struct attribute_str saved_attr = UI_attributes_current;

  UI_function.putstr (displayed);

  if (memcmp (&saved_attr, &UI_attributes_current, sizeof (struct
attribute_str))) {
#ifdef BAD 
  UI_function.setattribute (saved_attr);
#else
  /* Write it this way else GCC-4.6.0 uses "movl
UI.function.setattribute,%edx ; call *%edx" */
  struct attribute_str newattr = saved_attr;
  UI_function.setattribute (newattr);
#endif
  }
  }

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

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

--- Comment #8 from Thomas Henlich  
2011-05-05 13:31:47 UTC ---
(In reply to comment #6)
> Also, See below.  Does this give the expected output?
> 
> print *, (1.0, 0.0)
> end
> 
> $ ./a.out
>   (1.,.)

I personally prefer the optional zero before the decimal separator to be
printed, because we have done so and still do for real numbers:
(1.,0.)

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-05-05 
13:54:18 UTC ---
Why are you changing TER for that though?  Won't that affect also real code
generation rather than just debug insns?  I mean there are targets e.g. with
MEM MEM addressing.  With SSA expansion I think you can decide whether you want
to use TER's advice or not during expansion, where you know if it is from debug
stmt or not.

[Bug fortran/48889] New: f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906

[wence at gmx dot li]

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

   Summary: f951: internal compiler error: in
gfc_is_constant_expr, at fortran/expr.c:906
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: we...@gmx.li


Created attachment 24190
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24190
Two module files plus f90 source

I'm attempting to compile fluidity
(http://amcg.ese.ic.ac.uk/index.php?title=Fluidity) with gfortran 4.6.0 and
have hit the above error.

The problem can be reproduced with the two module files and single test.f90
attached in a tarball.  Source for the module files is large, with many
dependencies.  If necessary I can try and reduce these to a minimal size as
well.

$uname -a
Linux xxx 2.6.18-194.3.1.el5 #1 SMP Fri May 7 01:43:09 EDT 2010 x86_64 x86_64
x86_64 GNU/Linux

Compile output:

$ gfortran -v -save-temps -O0 test.f90 

Driving: gfortran -v -save-temps -O0 test.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/lmitche4/Apps/gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/lmitche4/Apps/gcc-4.6.0 -C
--disable-gcj --enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.6.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O0' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/lmitche4/Apps/gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951
test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test
-O0 -version -fintrinsic-modules-path
/home/lmitche4/Apps/gcc-4.6.0/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude
-o test.s
GNU Fortran (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.1,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.1,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


e->symtree is NULL causing a failure of gcc_assert.  I do not understand why.

Cheers,

Lawrence

[Bug c/48885] missed optimization with restrict qualifier?

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-05-05 
14:50:48 UTC ---
Because the standard was interpreted that way when implementing restrict
support.
And also because otherwise pointers based on a restrict pointer cannot be
reliably tracked.

[Bug c++/48873] [C++0x][noexcept] Placement-new problem with deleted destructors

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-05-05 
14:53:44 UTC ---
Author: jason
Date: Thu May  5 14:53:35 2011
New Revision: 173433

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173433
Log:
PR c++/48873
* tree.c (stabilize_expr): Don't make gratuitous copies of classes.

Added:
trunk/gcc/testsuite/g++.dg/init/new32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/48844] [4.6/4.7 regression] ICE on assignment of aggregate with discriminated record type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug middle-end/48668] [4.6/4.7 regression] COMDAT Group signature not emitted in group

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-05-05 
15:30:32 UTC ---
Hi,
I am not 100% I understand the problem.  For 4.6 we indeed probably should go
with reverting to prevous order. 
We are trying to output both the function itself and its thunk into single
named comdat group. The difference is that before patch we first output the
function itself and then the thunk. With the patch we output stuff other way
around.
So the signature always come from the first symbol within the group and there
is no way to output the thunk first (since its symbol is different) and the
function later?
I don't see how the symbol is outside of the group given that both symbols came
into same comdat section.

Honza

[Bug c++/48749] [4.6/4.7 Regression] internal compiler error: tree check: expected field_decl

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jason Merrill  2011-05-05 
15:03:34 UTC ---
Fixed.

[Bug c++/48872] [C++0x][noexcept] Placement-new problem with non-empty arguments

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  2011-05-05 
15:29:03 UTC ---
Resolved by the same fix as 48873.

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

[Bug c++/48873] [C++0x][noexcept] Placement-new problem with deleted destructors

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-05-05 
15:29:03 UTC ---
*** Bug 48872 has been marked as a duplicate of this bug. ***

[Bug c++/48873] [C++0x][noexcept] Placement-new problem with deleted destructors

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #3 from Jason Merrill  2011-05-05 
15:27:11 UTC ---
Fixed.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2011-05-05 
15:48:22 UTC ---
Author: jakub
Date: Thu May  5 15:48:18 2011
New Revision: 173436

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173436
Log:
PR debug/48853
* dwarf2out.c (mem_loc_descriptor) : Pass mem_mode
instead of mode as 3rd argument to recursive call.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED, don't
emit DW_OP_GNU_regval_type if mode is Pmode and mem_mode is not
VOIDmode.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED,
don't give up if mode is Pmode and mem_mode is not VOIDmode.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED,
use int_loc_descriptor if mode is Pmode and mem_mode is not VOIDmode.

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

[Bug fortran/48889] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-05-05 16:28:11 UTC ---
Can you attach the Fortran code that is used to generated 
the *.mod file?  We can't use the *.mod file with trunk, so
we can't test whether the bug has already been fixed.

[Bug ada/48844] [4.6/4.7 regression] ICE on assignment of aggregate with discriminated record type

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2011-05-05 
16:27:09 UTC ---
Author: ebotcazou
Date: Thu May  5 16:27:03 2011
New Revision: 173443

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173443
Log:
PR ada/48844
* gcc-interface/gigi.h (get_variant_part): Declare.
* gcc-interface/decl.c (get_variant_part): Make global.
* gcc-interface/utils2.c (find_common_type): Do not return T1 if the
types have the same constant size, are record types and T1 has a
variant part while T2 doesn't.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/discr29.adb
  - copied unchanged from r173442, trunk/gcc/testsuite/gnat.dg/discr29.adb
branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/discr29.ads
  - copied unchanged from r173442, trunk/gcc/testsuite/gnat.dg/discr29.ads
branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/discr30.adb
  - copied unchanged from r173442, trunk/gcc/testsuite/gnat.dg/discr30.adb
Modified:
branches/gcc-4_6-branch/gcc/ada/ChangeLog
branches/gcc-4_6-branch/gcc/ada/gcc-interface/decl.c
branches/gcc-4_6-branch/gcc/ada/gcc-interface/gigi.h
branches/gcc-4_6-branch/gcc/ada/gcc-interface/utils2.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug ada/48844] [4.6/4.7 regression] ICE on assignment of aggregate with discriminated record type

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-05/msg00431.htm
   ||l
 Resolution||FIXED

--- Comment #6 from Eric Botcazou  2011-05-05 
16:29:33 UTC ---
On all affected branches.

[Bug ada/48844] [4.6/4.7 regression] ICE on assignment of aggregate with discriminated record type

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-05-05 
16:22:21 UTC ---
Author: ebotcazou
Date: Thu May  5 16:22:16 2011
New Revision: 173442

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173442
Log:
PR ada/48844
* gcc-interface/gigi.h (get_variant_part): Declare.
* gcc-interface/decl.c (get_variant_part): Make global.
* gcc-interface/utils2.c (find_common_type): Do not return T1 if the
types have the same constant size, are record types and T1 has a
variant part while T2 doesn't.

Added:
trunk/gcc/testsuite/gnat.dg/discr29.adb
trunk/gcc/testsuite/gnat.dg/discr29.ads
trunk/gcc/testsuite/gnat.dg/discr30.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/ada/gcc-interface/gigi.h
trunk/gcc/ada/gcc-interface/utils2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/31584] [DR502] nested enum not considered dependent

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|[DR502] ICE on probably |[DR502] nested enum not
   |invalid code|considered dependent
  Known to fail||4.4.3, 4.5.2, 4.6.0

--- Comment #11 from Jonathan Wakely  2011-05-05 
17:32:15 UTC ---
Summary changed, as there's no ICE now. This is 'accepts-invalid' because DR502
means C::Inner is dependent, and [temp.class.spec]/8 says specialized
non-type arguments shall not have dependent types.


Reduced:

template 
struct C
{
  enum Inner { c };

  template struct Dispatcher;

  template struct Dispatcher 
  { };

};

int main()
{
  C Test;
}

expected error would be something like:

error: type 'C::Inner' of template argument 'c' depends on a template
parameter

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

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||eres at il dot ibm.com

--- Comment #4 from Bernd Schmidt  2011-05-05 
18:45:59 UTC ---
Sounds like either ia64 must clear the disable-schedule flag on all basic
blocks, or sms must be fixed to set TImode on the insns as needed.

[Bug debug/48159] [4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -O -ftree-loop-distribution -fno-tree-ch -g

[zsojka at seznam dot cz]

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

--- Comment #5 from Zdenek Sojka  2011-05-05 18:43:43 
UTC ---
Created attachment 24191
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24191
reduced testcase from comment #2

$ gcc -O3 -g pr48159-2.c -fno-tree-loop-distribute-patterns -c
$ gcc -O3 -g pr48159-2.c
pr48159-2.c: In function 'foo':
pr48159-2.c:4:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Fails with both 4.7 and 4.6.1 (r173059).

[Bug fortran/48890] New: length of a character derived-type component

[mhp77 at gmx dot at]

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

   Summary: length of a character derived-type component
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mh...@gmx.at


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

Consider the following derived-type definition:

type ::  string_t
   character( len= 10 ) ::  str
end type string_t

In case of a variable of type string_t, e.g.

type( string_t ) ::  string1 =  string_t( "text" )

the length of the character component is—as expected—10. In case of a constant
of type string_t, e.g.

type( string_t ), parameter ::  string2 =  string_t( "text" )

the length of the character component is, however, as if it had been declared
with len= *.

$ gfortran-4.6 -v -o test test.f90 && ./test

Driving: gfortran-4.6 -v -o test test.f90 -l gfortran -l m -shared-libgcc

Using built-in specs.

COLLECT_GCC=gfortran-4.6

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-2'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --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.6 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-plugin --enable-gold --enable-ld=default --with-plugin-ld
--enable-objc-gc --with-arch-32=i586 --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.6.1 20110329 (prerelease) (Debian 4.6.0-2)

COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/usr/lib/gcc/x86_64-linux-gnu/4.6.1/f951 test.f90 -quiet -dumpbase test.f90
-mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/finclude -o /tmp/ccYXc4lM.s

GNU Fortran (Debian 4.6.0-2) version 4.6.1 20110329 (prerelease)
(x86_64-linux-gnu)
compiled by GNU C version 4.6.1 20110329 (prerelease), GMP version 5.0.1, MPFR
version 3.0.0-p8, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

GNU Fortran (Debian 4.6.0-2) version 4.6.1 20110329 (prerelease)
(x86_64-linux-gnu)
compiled by GNU C version 4.6.1 20110329 (prerelease), GMP version 5.0.1, MPFR
version 3.0.0-p8, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

as --64 -o /tmp/ccmkcGOj.o /tmp/ccYXc4lM.s

Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.6.1/libgfortran.spec

rename spec lib to liborig

COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/

LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/

COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/usr/lib/gcc/x86_64-linux-gnu/4.6.1/collect2 --build-id --no-add-needed
--eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o test
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.6.1
-L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../..
-L/usr/lib/x86_64-linux-gnu /tmp/ccmkcGOj.o -lgfortran -lm -lgcc_s -lgcc
-lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/crtn.o

text  10
text4

[Bug c++/48574] [4.6/4.7 Regression] ICE

[dodji at gcc dot gnu.org]

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

--- Comment #17 from Dodji Seketeli  2011-05-05 
20:14:09 UTC ---
I think the reduced test case below reflects the ICE of the original
test case.  It needs the -std=c++0x option.

struct A
{
  virtual int foo();
};

void baz (int);

template 
void
bar(T x)
{
  A &b = *x;
  baz (b.foo ());
}

void
foo()
{
  A a;
  bar(&a);
}

[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  2011-05-05 
20:51:00 UTC ---
Author: jason
Date: Thu May  5 20:50:57 2011
New Revision: 173451

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173451
Log:
PR c++/40975
* tree-inline.c (copy_tree_r): Use copy_statement_list.
(copy_statement_list): Don't recurse.
* stor-layout.c (copy_self_referential_tree_r): Don't allow
STATEMENT_LIST.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/tree-inline.c

[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  2011-05-05 
21:02:09 UTC ---
Author: jason
Date: Thu May  5 21:02:06 2011
New Revision: 173452

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173452
Log:
PR c++/40975
* tree-inline.c (copy_tree_r): Handle STATEMENT_LIST.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/new30.C
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-inline.c

[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  2011-05-05 
21:02:53 UTC ---
Author: jason
Date: Thu May  5 21:02:51 2011
New Revision: 173454

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173454
Log:
PR c++/40975
* tree-inline.c (copy_tree_r): Handle STATEMENT_LIST.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/init/new30.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-inline.c

[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  2011-05-05 
21:02:48 UTC ---
Author: jason
Date: Thu May  5 21:02:45 2011
New Revision: 173453

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173453
Log:
PR c++/40975
* tree-inline.c (copy_tree_r): Handle STATEMENT_LIST.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/init/new30.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-inline.c

[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.6   |4.4.7

--- Comment #15 from Jason Merrill  2011-05-05 
21:06:56 UTC ---
Fixed in 4.4-4.7 branches.  The patch doesn't fix the bug in the 4.3 branch, so
I'm going to leave it unfixed there.

[Bug c/48885] missed optimization with restrict qualifier?

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #2 from Marc Glisse  2011-05-05 
21:20:29 UTC ---
Note for comparison that suncc and icc both perform the optimization as soon as
'a' or 'v' is restrict.

[Bug libstdc++/13631] Problems in messages

[paolo.carlini at oracle dot com]

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

--- Comment #31 from Paolo Carlini  2011-05-05 
21:34:01 UTC ---
Created attachment 24194
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24194
Last patch re-diffed vs current mainline

[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support.

[alexis.menard at openbossa dot org]

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

--- Comment #1 from Alexis Menard  
2011-05-05 21:35:55 UTC ---
glibc 2.13-5.
binutils 2.21-7

Archlinux.

[Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support.

[alexis.menard at openbossa dot org]

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

   Summary: std functions conflicts with C functions when building
with c++0x support.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alexis.men...@openbossa.org


Created attachment 24193
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24193
Small test case.

Hello,

I'm not sure it's a real bug (though that example builds fine with gcc 4.5.0)
but at least perhaps I'll get help.

Consider :

#include 
#include 
#include 

using namespace std;

int main(int argc, char** argv)
{
double number = 0;
if (isnan(number))
{
printf("Nan\n");
}
return 0;
}

and build it with : g++ main.cpp -std=c++0x -std=gnu++0x -o test

It fails to compile : 

main.cpp: In function ‘int main(int, char**)’:
main.cpp:10:21: error: call of overloaded ‘isnan(double&)’ is ambiguous
main.cpp:10:21: note: candidates are:
/usr/include/bits/mathcalls.h:235:1: note: int isnan(double)
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/cmath:558:3:
note: bool std::isnan(long double)
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/cmath:554:3:
note: bool std::isnan(double)
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/cmath:550:3:
note: bool std::isnan(float)

If I deactivate the c++0x support it works.

The real issue is that the c++0x standard removes the prohibition on C++
headers declaring C names in the global namespace. The problem here is that
math.h is included therefore the declarations are in the global namespace.

I'm not really sure how the compiler can solve that but this new "feature" of
c++0x seems to be very annoying. I could solve it by not using namespace std
but let say the project is huge, it will requires lot of modifications.

Basically any time you use using namespace std, you may have conflicts with the
underlaying C libraries, it's even more annoying with your own namespace
because your functions can conflict with all the stuff in the global namespace
put by C libraries and it's very common in a cpp file to use "using namespace
foo;"

Any suggestions on how I could "workaround" that?

[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-05-05 
22:03:55 UTC ---
(In reply to comment #0)
> 
> and build it with : g++ main.cpp -std=c++0x -std=gnu++0x -o test

There's no point specifying two -std options, only the last one takes effect.

> If I deactivate the c++0x support it works.

Because in C++98 there is no std::isnan, so you only get the version in the
global namespace from 

> The real issue is that the c++0x standard removes the prohibition on C++
> headers declaring C names in the global namespace. The problem here is that
> math.h is included therefore the declarations are in the global namespace.

I don't think that's the problem, because libstdc++ has always declared the
names in the global namespace even though it wasn't valid in C++03 - we haven't
changed that for C++0x (all that happened is the standard was relaxed to
reflect the reality of actual implementations)


> I'm not really sure how the compiler can solve that but this new "feature" of
> c++0x seems to be very annoying. I could solve it by not using namespace std
> but let say the project is huge, it will requires lot of modifications.
> 
> Basically any time you use using namespace std, you may have conflicts with 
> the
> underlaying C libraries, it's even more annoying with your own namespace
> because your functions can conflict with all the stuff in the global namespace
> put by C libraries and it's very common in a cpp file to use "using namespace
> foo;"
> 
> Any suggestions on how I could "workaround" that?

Qualify isnan explicitly, by calling either ::isnan or std::isnan

[Bug bootstrap/48879] Compilation cannot find file asm/errno.h

[mancilla at cse dot unsw.edu.au]

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

Blanca Mancilla  changed:

   What|Removed |Added

  Component|c++ |bootstrap

--- Comment #5 from Blanca Mancilla  
2011-05-05 22:09:28 UTC ---
(In reply to comment #2)
> Shouldn't this be Component=bootstrap not c++ ?

Yes, sorry.

> I assume the linux-libc-dev package is installed? That provides asm/errno.h

Yes that is installed.

> What compiler are you using to bootstrap? If it's the standard system compiler
> it should know to look in /usr/include/x86_64-linux-gnu, if not then it's a 
> bug
> in the Ubuntu gcc package

4.5.2, which came with the distribution.

> What is the output of "gcc -v -x c /dev/null -c" ?

Is is attached.

A bug in the Ubuntu gcc package confirms the fact that problems started after
the upgrade. Thanks for clearing things out.

Regards,
Blanca

[Bug c++/48892] New: [C++0x] XFAILed bogus errors in constexpr-48089.C

[jason at gcc dot gnu.org]

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

   Summary: [C++0x] XFAILed bogus errors in constexpr-48089.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: g...@magfr.user.lysator.liu.se
Depends on: 48089


In the testcase for 48089, the R section should be accepted because even though
we're looking at the same complete object, it's ok to get the value of already
initialized subobjects.

[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)

[alexis.menard at openbossa dot org]

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

--- Comment #3 from Alexis Menard  
2011-05-05 22:17:36 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > 
> > and build it with : g++ main.cpp -std=c++0x -std=gnu++0x -o test
> 
> There's no point specifying two -std options, only the last one takes effect.
> 
> > If I deactivate the c++0x support it works.
> 
> Because in C++98 there is no std::isnan, so you only get the version in the
> global namespace from 

That explain.

> 
> > The real issue is that the c++0x standard removes the prohibition on C++
> > headers declaring C names in the global namespace. The problem here is that
> > math.h is included therefore the declarations are in the global namespace.
> 
> I don't think that's the problem, because libstdc++ has always declared the
> names in the global namespace even though it wasn't valid in C++03 - we 
> haven't
> changed that for C++0x (all that happened is the standard was relaxed to
> reflect the reality of actual implementations)
> 

Sorry for my ignorance.

> 
> > I'm not really sure how the compiler can solve that but this new "feature" 
> > of
> > c++0x seems to be very annoying. I could solve it by not using namespace std
> > but let say the project is huge, it will requires lot of modifications.
> > 
> > Basically any time you use using namespace std, you may have conflicts with 
> > the
> > underlaying C libraries, it's even more annoying with your own namespace
> > because your functions can conflict with all the stuff in the global 
> > namespace
> > put by C libraries and it's very common in a cpp file to use "using 
> > namespace
> > foo;"
> > 
> > Any suggestions on how I could "workaround" that?
> 
> Qualify isnan explicitly, by calling either ::isnan or std::isnan

Well that requires me to modify my entire project, namely WebKit :(. But the
more I'm stuck on that issue, the more it seems to be the only solution.

[Bug libstdc++/13631] Problems in messages

[mr...@courier-mta.com]

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

--- Comment #32 from Sam Varshavchik  2011-05-05 
22:25:50 UTC ---
Created attachment 24196
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24196
Sample test program

Here's a simple test program that I threw together.

It uses the message catalog from libc and gnupg, both of which should be widely
available, and both have extensive localization where anyone can find a good
test case in their native tongue, that they can verify. I've used the ru_RU
locale for testing purposes, but you can use any locale where the two sample
strings have been localized.

>From the trunk, the third string printed by the test program comes out
unlocalized. There's your breakage. The existing breakage is that open() sets
the domain globally, the second open() stomps all over the first one, and the
third call to get() ends up looking in the wrong domain.

After applying Paolo's rebased patch to the trunk, the third string from the
test program is now the same string as the first string, which is the expected
result.

That's all the testing I've done so far, but it looks good.

[Bug c++/48879] Compilation cannot find file asm/errno.h

[mancilla at cse dot unsw.edu.au]

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

--- Comment #4 from Blanca Mancilla  
2011-05-05 22:05:53 UTC ---
Created attachment 24195
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24195
output of "gcc -v -x c /dev/null -c"

[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-05-05 
22:46:39 UTC ---
Just wanted to add that the real reason the issue is more subtle now in C++0x
mode than it used to be (and still is) in C++03 mode as an extension, is that
we now provide the functions in namespace std with the mandated return type,
that is bool, whereas in C++03 mode, as an extension, the return type is int,
like in C99. Frankly, *given* the usual, well known, limits of our way of
dealing with the underlying *.h C headers (included as implementation detail
anyway), I don't see any reasonably simple way of solving this family of
problems.

Actually, anyway, modulo a C++ front-end issue I filed some time ago, I think
the  header isn't *that* far from dispensing with including math.h, the
most important blocking issue being the constants FP_NAN, FP_INFINITE,
FP_NORMAL, FP_SUBNORMAL, FP_ZERO, which, the last time I asked, Joseph, if I
remember correctly, said are very tricky to obtain outside math.h...

Anyway, given the different return types in C++0x and C99, the problem would
resurface quite unavoidably with:

#include 
#include 

using namespace std;

of course, if we only fix  still without fully controlling math.h. Don't
hold your breath ;)

[Bug middle-end/48893] New: [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477

[danglin at gcc dot gnu.org]

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

   Summary: [4.7 Regression] ICE in evaulate_conditions_for_edge
at ipa-inline-analysis.c:477
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa2.0w-hp-hpux11.00
Target: hppa2.0w-hp-hpux11.00
 Build: hppa2.0w-hp-hpux11.00


if [ x"-fPIC" != x ]; then \
  /xxx/gnu/gcc/objdir/./prev-gcc/xgcc -B/xxx/gnu/gcc/objdir/./prev-gcc/ 
-B/opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.00/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa2.0
w-hp-hpux11.00/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.00/lib/ -isystem
/
opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.00/include -isystem
/opt/gnu/gcc/gcc-4.6/
hppa2.0w-hp-hpux11.00/sys-include-c -DHAVE_CONFIG_H -g -O2  -I.
-I../../gcc/
libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes 
-pedantic  -fPIC ../../gcc/libiberty/pex-unix.c -o pic/pex-unix.o; \
else true; fi
../../gcc/libiberty/pex-unix.c:788:1: internal compiler error: vector
VEC(tree,b
ase) index domain error, in evaluate_conditions_for_edge at
ipa-inline-analysis.
c:577
Please submit a full bug report,

Revision 172431 was ok.

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.00
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.6
--with-gmp=/opt/gnu/gcc/gcc-4.6 --enable-debug=no --disable-nls
--enable-threads=posix --enable-languages=c,c++,objc,fortran,ada,obj-c++
Thread model: posix
gcc version 4.7.0 20110505 (experimental) [trunk revision 173407] (GCC) 

Seems to be HP-UX 11.00 specific.

[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2011-05-05 
23:13:43 UTC ---
Jakub, wrt my Comment #4, would it make sense in your opinion to implement a
mechanism requiring cooperation between glibc & libstdc++ similar to the
__CORRECT_ISO_CPP_STRING_H_PROTO mechanism you implemented for memchr & co back
in 2009-01-30?

[Bug fortran/48894] New: generic omp_get_ancestor_thread_num(l(i)) produces incorrect output

[longb at cray dot com]

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

   Summary: generic omp_get_ancestor_thread_num(l(i)) produces
incorrect output
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com


I wavered between "minor" and "trivial" on this one, but the OpenMP testers
came up with this end case.  It seems very unlikely to arise in a real program,
but is also probably easy to fix in the library code.

> cat test1.f90
!  derived from OpenMP test OMP3f/F03_3_2_17_1a.F90
!  See - OpenMP 3.0 API spec, p. 131, lines 2-9.
program F03_3_2_17_1a
   use omp_lib
   implicit none

   logical, parameter :: FALSE=.false.
   logical, parameter :: TRUE=.true.
   integer, parameter :: ZERO=0
   integer, parameter :: TWO=2
   integer*4, parameter :: ZERO4=0
   integer, parameter :: MHUGE4=-huge(ZERO4)
   integer :: level(10) =&
 (/-huge(ZERO), -huge(ZERO)+3, MHUGE4, -1, 0, 1, 2, 3, 4, huge(ZERO)/)

   integer :: i
   integer, dimension(10) :: expected_ancestor_thread_num,&
   actual_ancestor_thread_num = (/(-huge(i), i=1,10)/)

   call omp_set_dynamic( FALSE )
   call omp_set_nested( TRUE )
   call omp_set_max_active_levels(TWO) ! one inactive parallel region

   ! if the implementation supports nested parallelism, then expected value of
   ! omp_get_ancestor_thread(2) == 1, else 0
   if (omp_get_nested()) then
  expected_ancestor_thread_num = (/-1, -1, -1, -1, 0, 2, 1, 0, -1, -1/)
   else
  expected_ancestor_thread_num = (/-1, -1, -1, -1, 0, 2, 0, 0, -1, -1/)
   end if

   !$omp parallel num_threads(3)! nest level 1
   if (omp_get_thread_num() == 2) then ! ancestor thread num = 2 at this level
  !$omp parallel num_threads(2) ! nest level 2
  if ((omp_get_nested() .and. omp_get_thread_num() == 1) .or. &
  (omp_get_nested() .eqv. .false. .and. omp_get_thread_num() == 0))
then
 !$omp parallel ! nest level 3
 ! inactive parallel region due to max-active-level-var == 2,
 ! so should be executed by only one thread
 do i = 1, size(level)
actual_ancestor_thread_num(i)
=omp_get_ancestor_thread_num(level(i))
 end do
 !$omp end parallel
  end if 
  !$omp end parallel
   end if
   !$omp end parallel

   do i = 1, size(level)
   print *, 'level(i)=', level(i)
  if (actual_ancestor_thread_num(i) /= expected_ancestor_thread_num(i))
then
 print *, "FAIL - omp_get_ancestor_thread_num(", level(i), ")", &
  " == ", actual_ancestor_thread_num(i), " (expected ", & 
  expected_ancestor_thread_num(i), ")"
  end if 
   end do

end program F03_3_2_17_1a

> gfortran -fopenmp -fdefault-integer-8 -fdefault-real-8 test1.f90
> ./a.out 
level(i)= -9223372036854775807
 FAIL - omp_get_ancestor_thread_num( -9223372036854775807 ) == 
   2  (expected-1 )
 level(i)= -9223372036854775804
 level(i)=  -2147483647
 level(i)=   -1
 level(i)=0
 level(i)=1
 level(i)=2
 level(i)=3
 level(i)=4
 level(i)=  9223372036854775807
> 


>From the OpenMP spec from page 131, lines 2-5:

"The omp_get_ancestor_thread_num routine returns the thread number of the
ancestor at a given nest level of the current thread or the thread number of
the current thread. If the requested nest level is outside the range of 0 and
the nest level of the current thread, as returned by the omp_get_level routine,
the routine returns -1."

The routine omp_get_level() always returns a result that is 0 or a positive
integer. So any negative argument to omp_get_ancestor_thread_num that is
negative is outside the range 0..omp_get_level(), so the result should be -1.

I suspect what is happening here is that the computation inside
omp_get_ancestor_thread_num (n) involves a subtract of n - num_threads which
wraps around because the value of n is at the limit of representable integers.
Note that the second trial input is different by 3 (and num_threads is 3), so
it just barely avoids the wrap.

[Bug target/48895] New: config/vms/vms-ar.c:main: variable ‘cwd’ set but not used

[amylaar at gcc dot gnu.org]

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

   Summary: config/vms/vms-ar.c:main: variable ‘cwd’ set but not
used
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: r...@gnat.com, ging...@adacore.com
Blocks: 44756
Target: alpha-dec-vms


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber-I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber  
../../../gcc/gcc/config/vms/vms-ar.c -o vms-ar.o
../../../gcc/gcc/config/vms/vms-ar.c: In function ‘main’:
../../../gcc/gcc/config/vms/vms-ar.c:128:9: error: variable ‘cwd’ set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

[Bug middle-end/48893] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-05-05 23:33:46 UTC ---
Attached .i.  cc1 compile args are:

-fpreprocessed pex-unix.i -quiet -dumpbase pex-unix.c -auxbase-strip
pic/pex-unix.o -g -O2 -Wextra -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -version -fPIC -o pex-unix.s

Dave

[Bug target/48896] New: avr.o warnings

[amylaar at gcc dot gnu.org]

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

   Summary: avr.o warnings
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: eric.wedding...@atmel.com, ae...@pautinka.net
Blocks: 44756
Target: avr-elf, avr-rtems


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber\
../../../gcc/gcc/config/avr/avr.c -o avr.o
../../../gcc/gcc/config/avr/avr.c: In function ‘avr_function_value_regno_p’:
../../../gcc/gcc/config/avr/avr.c:6190:17: error: comparison between signed and
unsigned integer expressions [-Werror=sign-compare]
../../../gcc/gcc/config/avr/avr.c: In function ‘avr_function_value’:
../../../gcc/gcc/config/avr/avr.c:6214:20: error: initialization from
incompatible pointer type [-Werror]
../../../gcc/gcc/config/avr/avr.c: In function ‘avr_expand_unop_builtin’:
../../../gcc/gcc/config/avr/avr.c:6712:3: error: enum conversion when passing
argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat]
../../../gcc/gcc/expr.h:416:1: note: expected ‘enum expand_modifier’ but
argument is of type ‘int’
../../../gcc/gcc/config/avr/avr.c: In function ‘avr_expand_binop_builtin’:
../../../gcc/gcc/config/avr/avr.c:6753:3: error: enum conversion when passing
argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat]
../../../gcc/gcc/expr.h:416:1: note: expected ‘enum expand_modifier’ but
argument is of type ‘int’
../../../gcc/gcc/config/avr/avr.c:6754:3: error: enum conversion when passing
argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat]
../../../gcc/gcc/expr.h:416:1: note: expected ‘enum expand_modifier’ but
argument is of type ‘int’
../../../gcc/gcc/config/avr/avr.c: In function ‘avr_expand_builtin’:
../../../gcc/gcc/config/avr/avr.c:6846:9: error: enum conversion when passing
argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat]
../../../gcc/gcc/expr.h:416:1: note: expected ‘enum expand_modifier’ but
argument is of type ‘int’
cc1: all warnings being treated as errors

[Bug target/48897] New: mn10300.c:extract_bundle’: error: variable ‘s’ set but not used

[amylaar at gcc dot gnu.org]

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

   Summary: mn10300.c:extract_bundle’: error: variable ‘s’ set but
not used
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: aol...@gcc.gnu.org, l...@redhat.com
Blocks: 44756
Target: am33_2.0-linux


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber\
../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o
../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘extract_bundle’:
../../../gcc/gcc/config/mn10300/mn10300.c:2962:9: error: variable ‘s’ set but
not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

[Bug middle-end/48893] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from John David Anglin  2011-05-06 
00:02:53 UTC ---
Reproduces on i686-apple-darwin9.

(gdb) break ipa-inline-analysis.c:577
Breakpoint 1 at 0xb4a816: file ../../gcc/gcc/ipa-inline-analysis.c, line 577.
(gdb) r
Starting program: /Users/dave/gnu/gcc/objdir.1/gcc/cc1 -fpreprocessed
pex-unix.i -quiet -dumpbase pex-unix.c -auxbase-strip pic/pex-unix.o -g -O2
-Wextra -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
-version -fPIC -o pex-unix.s
Reading symbols for shared libraries . done
GNU C (GCC) version 4.7.0 20110505 (experimental) [trunk revision 173457]
(hppa2.0w-hp-hpux11.00)
compiled by GNU C version 4.3.3, GMP version 5.0.1, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.7.0 20110505 (experimental) [trunk revision 173457]
(hppa2.0w-hp-hpux11.00)
compiled by GNU C version 4.3.3, GMP version 5.0.1, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0113cf123100363743631cf864c51faa

Breakpoint 1, evaluate_conditions_for_edge (e=0xda4dc0, inline_p=1 '\001') at
../../gcc/gcc/ipa-inline-analysis.c:577
577  tree val = VEC_index (tree, known_vals, c->operand_num);
(gdb) bt
#0  evaluate_conditions_for_edge (e=0xda4dc0, inline_p=1 '\001') at
../../gcc/gcc/ipa-inline-analysis.c:577
#1  0x00b532d3 in estimate_callee_size_and_time (edge=0xda4dc0, inline_p=1
'\001', ret_size=0xbfffedb8, ret_time=0xbfffedbc) at
../../gcc/gcc/ipa-inline-analysis.c:1561
#2  0x00b54436 in do_estimate_edge_time (edge=0xda4dc0) at
../../gcc/gcc/ipa-inline-analysis.c:1858
#3  0x00b546f5 in do_estimate_edge_growth (edge=0xda4dc0) at
../../gcc/gcc/ipa-inline-analysis.c:1897
#4  0x00b54b05 in estimate_edge_growth (edge=0xda4dc0) at ipa-inline.h:207
#5  0x00b54a05 in estimate_size_after_inlining (node=0xd6b0a0, edge=0xda4dc0)
at ../../gcc/gcc/ipa-inline-analysis.c:1943
#6  0x00b43c2e in caller_growth_limits (e=0xda4dc0) at
../../gcc/gcc/ipa-inline.c:176
#7  0x00b4448e in can_inline_edge_p (e=0xda4dc0, report=1 '\001') at
../../gcc/gcc/ipa-inline.c:296
#8  0x00b4764e in inline_small_functions () at ../../gcc/gcc/ipa-inline.c:1267
#9  0x00b48587 in ipa_inline () at ../../gcc/gcc/ipa-inline.c:1600
#10 0x0068d934 in execute_one_pass (pass=0xd0d460) at
../../gcc/gcc/passes.c:1556
#11 0x0068ea13 in execute_ipa_pass_list (pass=0xd0d460) at
../../gcc/gcc/passes.c:1923
#12 0x00ba in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1822
#13 0x00b33475 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1857
#14 0x00b2fe8c in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1099
#15 0x00037dcc in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9846
#16 0x007b118c in compile_file () at ../../gcc/gcc/toplev.c:586
#17 0x007b3df4 in do_compile () at ../../gcc/gcc/toplev.c:1928
#18 0x007b3fd5 in toplev_main (argc=20, argv=0xb33c) at
../../gcc/gcc/toplev.c:2000
#19 0x001459bb in main (argc=20, argv=0xb33c) at ../../gcc/gcc/main.c:36

[Bug target/48898] New: i386/netware.c:i386_nlm_maybe_mangle_decl_assembler_name: ‘cvt’ undeclared

[amylaar at gcc dot gnu.org]

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

   Summary: i386/netware.c:i386_nlm_maybe_mangle_decl_assembler_na
me: ‘cvt’ undeclared
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: r...@gcc.gnu.org, j...@suse.cz, ubiz...@gmail.com
Blocks: 47093
Target: i586-netware --with-ld


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber-I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber   \
../../../gcc/gcc/config/i386/netware.c
../../../gcc/gcc/config/i386/netware.c: In function
‘i386_nlm_maybe_mangle_decl_assembler_name’:
../../../gcc/gcc/config/i386/netware.c:163:13: error: ‘cvt’ undeclared (first
use in this function)
../../../gcc/gcc/config/i386/netware.c:163:13: note: each undeclared identifier
is reported only once for each function it appears in
make[2]: *** [netware.o] Error 1

[Bug target/48900] New: unnecessary duplicate __tls_get_addr calls

[amodra at gmail dot com]

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

   Summary: unnecessary duplicate __tls_get_addr calls
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


This testcase when compiled with -fPIC generates two calls to __tls_get_addr.
extern __thread int i;
void foo (void) { i++; }

The regression was introduced with the fix for PR44266

[Bug target/48899] New: enum conversion initializing global_options_init.x_iq2000_tune

[amylaar at gcc dot gnu.org]

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

   Summary: enum conversion initializing
global_options_init.x_iq2000_tune
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: ni...@redhat.com
Blocks: 44433,44756
Target: iq2000-elf


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumberoptions.c -o options.o
options.c:292:3: error: enum conversion in initialization is invalid in C++
[-Werror=c++-compat]
options.c:292:3: error: (near initialization for
‘global_options_init.x_iq2000_tune’) [-Werror=c++-compat]
cc1: all warnings being treated as errors

[Bug rtl-optimization/48902] New: var-tracking.c fails to compile for PCC_STATIC_STRUCT_RETURN

[amylaar at gcc dot gnu.org]

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

   Summary: var-tracking.c fails to compile for
PCC_STATIC_STRUCT_RETURN
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Target: m68k-openbsd


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../../gcc/gcc/var-tracking.c -o var-tracking.o
../../../gcc/gcc/var-tracking.c: In function ‘prepare_call_arguments’:
../../../gcc/gcc/var-tracking.c:5650:8: error: ‘else’ without a previous ‘if’
make[2]: *** [var-tracking.o] Error 1

[Bug target/48901] New: lm32.md: ashlsi3: error: unused variable ‘one’

[amylaar at gcc dot gnu.org]

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

   Summary: lm32.md: ashlsi3: error: unused variable ‘one’
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: leker...@gcc.gnu.org
Blocks: 44756
Target: lm32-elf, lm32-rtems, lm32-uclinux


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumberinsn-emit.c -o insn-emit.o
../../../gcc/gcc/config/lm32/lm32.md: In function ‘gen_ashlsi3’:
../../../gcc/gcc/config/lm32/lm32.md:827:15: error: unused variable ‘one’
[-Werror=unused-variable]
cc1: all warnings being treated as errors