[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.

[fxcoudert at gcc dot gnu.org]

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

--- Comment #4 from Francois-Xavier Coudert  
2011-02-28 08:16:24 UTC ---
Author: fxcoudert
Date: Mon Feb 28 08:16:21 2011
New Revision: 170557

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170557
Log:
PR fortran/47894
* intrinsic.texi: Fix doc of the VERIFY intrinsic.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Francois-Xavier Coudert  
2011-02-28 08:17:59 UTC ---
Fixed again, thanks again!

Re: [Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver

[Jan Hubicka]

> That should work.  The error is a sanity check that profile information
> is sane.
Obviously given that sanity of profile can break for valid reasons, we should 
not ICE
when this happen.  I will try to look how it becomes insane here however.

Honza

[Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  2011-02-28 08:55:46 UTC 
---
> That should work.  The error is a sanity check that profile information
> is sane.
Obviously given that sanity of profile can break for valid reasons, we should
not ICE
when this happen.  I will try to look how it becomes insane here however.

Honza

[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  2011-02-28 
08:55:33 UTC ---
(In reply to comment #14)
> Jakub, what was logic for the current alias merging code?

Is that my code?  That would surprise me, I had to do something primarily with
same body ctors/dtors, enhancing it for thunks was something you've done.

[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program

[hubicka at ucw dot cz]

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

--- Comment #16 from Jan Hubicka  2011-02-28 08:58:39 
UTC ---
> > Jakub, what was logic for the current alias merging code?
> 
> Is that my code?  That would surprise me, I had to do something primarily with
> same body ctors/dtors, enhancing it for thunks was something you've done.

I think that bit was inherited from same body code (LTHUNK probably wants to be
same
body alias anyway).  I will investigate it more tonight.
Obviously merging it all together is not what happens in linker and we should
immidate
linker behaviour here.

Honza

[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2011-02-28 
09:14:18 UTC ---
For more on LTHUNK see http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02603.html
When merging you either should take all thunks and real definitions from one
object, or another one, not mix them, so I don't currently understand how you
could mix LTHUNK from different objects.  But you know, I'm not familiar with
LTO too much.

[Bug target/47920] New: strange code generated for expression (a+7)/8

[carrot at google dot com]

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

   Summary: strange code generated for expression (a+7)/8
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi


Compile the following code with options -mthumb -march=armv7-a -O2

int t08(int a)
{
  return (a+7)/8;
}

GCC 4.6 generates

t08:
addr3, r0, #14
addsr0, r0, #7
itmi
movmir0, r3
asrsr0, r0, #3
bxlr


Why not simply generate

addsr0, r0, #7
asrsr0, r0, #3
bxlr

[Bug tree-optimization/46639] [4.6 Regression] Missing optimization

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  2011-02-28 
09:25:28 UTC ---
There is no predictor predicting x > 1023 as unlikely, there is not much you
can easilly guess here ;(

[Bug c++/47873] [4.6 Regression] virtual Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-02-28 
09:31:32 UTC ---
(In reply to comment #8)
> Confirmed that this testcase runs fine with gcc 4.4.5/4.5.2
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47874 still fails on gcc
> 4.4.5/4.5.2

ah, I didn't realise it fails on different versions, sorry. I'll try to reduce
it and reopen Bug 47874

[Bug rtl-optimization/47899] [4.5/4.6 Regression] ICE in get_loop_body, at cfgloop.c:831

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-02-28 
09:39:52 UTC ---
Somewhat simplified testcase (still for -O -funroll-loops):

extern unsigned int a, b, c;
extern int d;

static int
foo (void)
{
lab:
  if (b)
for (d = 0; d >= 0; d--)
  if (a || c)
for (; c; c++)
  ;
  else
goto lab;
}

int
main ()
{
  foo ();
  return 0;
}

[Bug bootstrap/47907] Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'

[skunk at iskunk dot org]

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

--- Comment #1 from Daniel Richard G.  2011-02-28 
09:45:09 UTC ---
Much later in the bootstrap process, I get this, which may be related:

libtool: compile:  /tmp/gcc-4.5.2-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-4.5.2-build/./gcc -nostdinc++
-L/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include
-I/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.5.2/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -std=gnu++0x -c
/home/src/gcc-4.5.2/libstdc++-v3/src/mutex.cc  -DPIC -o mutex.o
In file included from
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:72:0,
 from
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/ratio:39,
 from
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/chrono:42,
 from
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/mutex:41,
 from /home/src/gcc-4.5.2/libstdc++-v3/src/mutex.cc:25:
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:36:11:
error: '::int8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:37:11:
error: '::int16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:38:11:
error: '::int32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:39:11:
error: '::int64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:41:11:
error: '::int_fast8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:42:11:
error: '::int_fast16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:43:11:
error: '::int_fast32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:44:11:
error: '::int_fast64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:46:11:
error: '::int_least8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:47:11:
error: '::int_least16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:48:11:
error: '::int_least32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:49:11:
error: '::int_least64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:51:11:
error: '::intmax_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:52:11:
error: '::intptr_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:54:11:
error: '::uint8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:55:11:
error: '::uint16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:56:11:
error: '::uint32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:57:11:
error: '::uint64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:59:11:
error: '::uint_fast8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:60:11:
error: '::uint_fast16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:61:11:
error: '::uint_fast32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:62:11:
error: '::uint_fast64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:64:11:
error: '::uint_least8_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:65:11:
error: '::uint_least16_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:66:11:
error: '::uint_least32_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:67:11:
error: '::uint_least64_t' has not been declared
/tmp/gcc-4.5.2-build/powerpc-ibm

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

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

--- Comment #18 from Onur Küçük  2011-02-28 09:50:51 
UTC ---
I have found that reverting r167492  [1] fixes the problem for me. Of course it
brings back PR46806 but at least it should give a hint where the problem is.

Attaching the change as a patch, in case anyone is interested.


[1] http://gcc.gnu.org/viewcvs?view=revision&revision=167492

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

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

--- Comment #19 from Onur Küçük  2011-02-28 09:51:50 
UTC ---
Created attachment 23488
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23488
revert 167492 patch

[Bug target/47920] strange code generated for expression (a+7)/8

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2011-02-28 
09:56:36 UTC ---
Presumably because arithmetic right-shift by 3 isn't the same as a division by
8 when (a+7) is negative.  Changing the types to unsigned gives the code you
want.

[Bug target/47920] strange code generated for expression (a+7)/8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-02-28 
10:09:25 UTC ---
Yeah, exactly.  Try for say a = -20.

[Bug libstdc++/47921] New: pbump will overflow when input n is larger than 2G-1

[RobertPython at 163 dot com]

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

   Summary: pbump will overflow when input n is larger than 2G-1
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: robertpyt...@163.com
Target: x86_64-redhat-linux
 Build: gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)


in function int basic_streambuf::pbump(int n), n is a int which is easily
overflow in 64bit environment, especially when it is called in overflow
function.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[RobertPython at 163 dot com]

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

--- Comment #1 from Robert Python  2011-02-28 
10:51:30 UTC ---
try below program in a 64bit environment with about 8G memory:

#include 
#include 
#include 

#define N 1
#define SIZE 40

using namespace std;

int main()
{
const char msg[SIZE] = "aaa";
strstreambuf *new_data = new strstreambuf();
for (int i = 0; i < N; ++i)
{
new_data->freeze(false);
new_data->sputn(msg, SIZE);
}

delete new_data;
return 0;
}

[Bug rtl-optimization/47918] [4.6 regression] noreturn discovery broke non local gotos on m68k

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #1 from Richard Guenther  2011-02-28 
10:56:33 UTC ---
This is probably related to PR47815.

Also y isn't really noreturn, is it?  Honza?  Shouldn't non-local gotos
also prevent noreturn?

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  2011-02-28 
11:13:55 UTC ---
Yes, but there is nothing we can do as libstdc++ project, this is the ISO
Standard: see 27.5.2.

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-02-28 
11:15:44 UTC ---
Thanks Marc, let me have a closer look to the code and some testing.

[Bug libobjc/47922] New: [4.6 Regression] libobjc crashes with garbage collection in any real-life program

[nicola at gcc dot gnu.org]

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

   Summary: [4.6 Regression] libobjc crashes with garbage
collection in any real-life program
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


>From Richard Frith-Macdonald (r...@gnu.org) --

> I enabled gc and built base using the new compiler runtime, but as soon as
> I start any program, it segfaults.
>
> It appears that a bug has crept in to the libobjc type encoding handling,
> so when you call class_ivar_set_gcinvisible() for any class, you get a crash.
>
> The crash is a divide by zero in objc_layout_structure_next_member()
> (at line 1278 desired_align is zero).
>
> I think the problem is that the exclamation mark denoting a weak variable
> is not being handled in the function.
> On line 1208 objc_skip_type_qualifiers() is not skipping past it, then
> on line 1211 objc_alignof_type() is returning zero.
>
> Looking at the ChangeLog, I think you broke this on 2010-09-26 changing 
> _C_GCINVISIBLE from '!' to '|' when parts of the code use a literal 
> exclamation mark rather than the symbolic constant.
>
> Is it too late to get this fixed?

gc.c line 427 replace three lines with:

 new_type[len++] = _C_GCINVISIBLE;
 strcpy (new_type + len, type);

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson  2011-02-28 
12:04:32 UTC ---
(In reply to comment #14)
> I'll try Kazu's patch in my next 4.4 bootstrap/regtest.

Kazu's patch appears to have been for a 4.2 code base.  I forward-ported it to
4.4.5, where it fixed the test case in a cross compiler, but unfortunately
broke native bootstrap:

gengtype-lex.c: In function 'yy_get_next_buffer':
gengtype-lex.c:1663: warning: old-style function definition
gengtype-lex.c: In function 'yy_get_previous_state':
gengtype-lex.c:1795: warning: old-style function definition
gengtype-lex.c: In function 'yylex':
gengtype-lex.c:1652: error: unrecognizable insn:
(insn 2783 2782 1738 243 gengtype-lex.c:1784 (set (mem:QI (reg:SI 1 %d1
[orig:121 yy_n_chars.68 ] [121]) [0 S1 A8])
(const_int 0 [0x0])) -1 (nil))
gengtype-lex.c:1652: internal compiler error: in extract_insn, at recog.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [build/gengtype-lex.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir44/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir44'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir44'
make: *** [bootstrap] Error 2

[Bug bootstrap/47923] New: Errors when installing GCC 4.5.2 on AIX 6.1

[mirko.chioldin at iside dot bcc.it]

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

   Summary: Errors when installing GCC 4.5.2 on AIX 6.1
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mirko.chiol...@iside.bcc.it


Created attachment 23489
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23489
Output commands configure and make

Hello,
I would like to install version 4.5.2 of GCC on AIX 6.1. This release allows me
to use optimizations for Power7.
I installed gcc, C++, cpp, libgcc, LIBGOMP, LIBMPC, M4, MPFR and GMP through
RPM.


After that I setted the environment variables:


export CONFIG_SHELL=/opt/freeware/bin/bash
export LDR_CNTRL=MAXDATA=0x5000
export LDR_CNTRL=MACDATA=0x3000
export CONFIG_SHELL
export PATH=/opt/freeware/bin:/users/app/gcc/bin:$PATH:.
export LIBPATH=/opt/freeware/lib:
export LD_LIBRARY_PATH=$LIBPATH



And I run the command configure:

../gcc-4.5.2/configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++ --prefix=/users/app/gcc-4.5.2
--mandir=/users/app/gcc/man --infodir=/users/app/gcc/share/info
--enable-version-specific-runtime-libs --disable-nls
--host=powerpc-ibm-aix6.1.0.0 --enable-static --enable-threads=aix
--enable-shared


During the "make" phase, I get the output that I attach.


What can I do?


Mirko

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-02-28 
12:36:28 UTC ---
We can't change the signature of pbump, but that doesn't mean we have to call
it with values that cause overflow. Could we add a safe_pbump(streamsize n)
which calls pbump in a loop so it doesn't call it with a value outside the
range of an int?

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-02-28 
12:37:42 UTC ---
I don't see any error with the attachment you made.  What is the problem you
are running into?

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[mirko.chioldin at iside dot bcc.it]

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

--- Comment #2 from Mirko  2011-02-28 
12:42:28 UTC ---
The make phase was stopper with this error:


if [ x"" != x ]; then \
  powerpc-ibm-aix6.1.0.0-gcc -c -DHAVE_CONFIG_H -g -O2  -I.
-I../.././libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic   ../.././libiberty/regex.c -o pic/regex.o; \
else true; fi
powerpc-ibm-aix6.1.0.0-gcc -c -DHAVE_CONFIG_H -g -O2  -I.
-I../.././libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  ../.././libiberty/regex.c -o regex.o
Assembler:
/tmp//ccq2Ddo4.s: line 6636: 1252-040 The specified expression is not valid.
Make sure that all symbols are defined.
Check the rules on symbols used in an arithmetic expression
concerning relocation.
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory
`/users/gcc/gcc-4.5.2/build-powerpc-ibm-aix6.1.0.0/libiberty'
make[2]: *** [all-build-libiberty] Error 2
make[2]: Leaving directory `/users/gcc/gcc-4.5.2'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/users/gcc/gcc-4.5.2'
make: *** [all] Error 2

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-02-28 
12:43:41 UTC ---
something like this (untested)

--- include/std/streambuf.orig  2011-02-28 12:40:44.559350898 +
+++ include/std/streambuf   2011-02-28 12:32:20.445685621 +
@@ -38,6 +38,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- include/bits/streambuf.tcc.orig 2011-02-28 12:40:35.554301020 +
+++ include/bits/streambuf.tcc  2011-02-28 12:42:30.761788519 +
@@ -91,6 +91,11 @@
  traits_type::copy(this->pptr(), __s, __len);
  __ret += __len;
  __s += __len;
+ while (__len > std::numeric_limits::max())
+   {
+ this->pbump(std::numeric_limits::max());
+ __len -= std::numeric_limits::max();
+   }
  this->pbump(__len);
}

--- src/strstream.cc.orig   2011-02-28 12:40:25.373244770 +
+++ src/strstream.cc2011-02-28 12:42:10.945712166 +
@@ -161,6 +161,11 @@
  }

setp(buf, buf + new_size);
+   while (old_size > INT_MAX)
+   {
+ this->pbump(INT_MAX);
+ old_size -= INT_MAX;
+   }
pbump(old_size);

if (reposition_get)

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  2011-02-28 12:57:30 
UTC ---
This is a problem with the host compiler (powerpc-ibm-aix6.1.0.0-gcc).  Try
using a different compiler or reducing the optimisation level.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  2011-02-28 
13:01:16 UTC ---
This is a different issue. Anyway, concentrating on basic_streambuf<>::xsputn
(I don't think we should fiddle that late with the deprecated strstream), note
that __len is smaller than __buf_len, and typically __buf_len ~= 8192. Thus I
would consider the problem rather minor. Anyway, I'm in favor of something like
your first hunk, with a comment before about streamsize == ptrdiff_t, and using
__gnu_cxx::__numeric_traits::__max instead (thus avoiding bringing in the
whole ).

Probably we used to be not careful enough in xsputn because streamsize is (was)
normally 32 bits on 32-bit machines (being ptrdiff_t).

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2011.02.28 13:09:00
 Resolution|INVALID |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

--- Comment #6 from Paolo Carlini  2011-02-28 
13:09:00 UTC ---
Ok, let me handle this, we have another couple unsafe on 64-bit uses in
sstream.tcc. Note, in general we can't rely on additional member functions
being available in basic_streambuf, can be specialized.

[Bug libobjc/47922] [4.6 Regression] libobjc crashes with garbage collection in any real-life program

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #1 from Nicola Pero  2011-02-28 13:13:19 
UTC ---
Fixed in trunk (4.6.0).

Thanks

[Bug middle-end/47917] snprintf(..., "const string") should be optimized into memcpy

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-02-28 
13:23:20 UTC ---
Created attachment 23490
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23490
gcc46-pr47917.patch

Untested patch.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-02-28 
14:11:39 UTC ---
Actually, fixing strstream too is easy, because it derives from
basic_streambuf, which can be assumed to have __safe_pbump

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-02-28 
14:32:09 UTC ---
Testing at my end went well. I guess I'm going to apply the patch for 4.6.0,
together with an handful of additional tests. I think the patch is small enough
to go in at your name without Copyright Assignment. Thanks again! Please, if
you notice something wrong over the next weeks, before the release of 4.6.0,
please let me know ASAP.

[Bug lto/47924] New: [4.6 Regression] Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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

   Summary: [4.6 Regression] Missed optimization with LTO
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


Created attachment 23491
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23491
Compile with -O2 -flto

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[marc.glisse at normalesup dot org]

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

--- Comment #4 from Marc Glisse  2011-02-28 
14:45:42 UTC ---
(In reply to comment #3)
> I think the patch is small enough
> to go in at your name without Copyright Assignment.

I believe I am supposed to have the paperwork in order now. Would you mind
checking so I don't write anything else if it is not the case?

[Bug lto/47924] [4.6 Regression] Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2011-02-28 14:47:26 UTC ---
Created attachment 23492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23492
Generated asm

[Bug lto/47924] [4.6 Regression] Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #2 from Dmitry Gorbachev  
2011-02-28 14:48:01 UTC ---
Created attachment 23493
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23493
Testcase #2

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-02-28 
14:51:08 UTC ---
Well, I can check, but if you sent already the form, it should be matter of 1-2
weeks max for you to get back via email the pdf of your assignment. When did
you send the form signed?

[Bug lto/47924] [4.6 Regression] Missed optimization with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.28 15:19:15
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-02-28 
15:19:15 UTC ---
Confirmed.

I'll have a looksee.

[Bug rtl-optimization/47925] New: delete_trivially_dead_insns mishandles volatile mems

[rsandifo at gcc dot gnu.org]

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

   Summary: delete_trivially_dead_insns mishandles volatile mems
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsand...@gcc.gnu.org


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

If we have a sequence like:

(set (reg A) ...)
(set (reg A) (mem/v (reg A)))

then a long-standing bug in delete_trivially_dead_insns will
cause it to delete the first instruction.  The attached testcase
fails on x86_64 at -O and above.

The bug is in old code, so the failure in the testcase seems to go
back to at least 4.1.  However, a combination of factors means that
it also shows up as a wrong-code regression in Qt using Linaro GCC 4.5.
I've not yet been able to find a specific testcase that regresses
in FSF GCC 4.5.

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[mirko.chioldin at iside dot bcc.it]

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

--- Comment #4 from Mirko  2011-02-28 
15:20:26 UTC ---
Hello,
using the command "make CFLAGS = '-O0' CXXFLAGS = '-O0' LIBCFLAGS = '-O0'
LIBCXXFLAGS = '-O0-fno-implicit-templates' bootstrap' seems to work better.

But the phase "make" stops anyway.


Mirko

[Bug rtl-optimization/47925] delete_trivially_dead_insns mishandles volatile mems

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.28 15:21:29
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[mirko.chioldin at iside dot bcc.it]

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

--- Comment #5 from Mirko  2011-02-28 
15:21:29 UTC ---
Created attachment 23495
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23495
New test to compile

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2011-02-28 
15:36:41 UTC ---
Author: jakub
Date: Mon Feb 28 15:36:37 2011
New Revision: 170565

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170565
Log:
PR middle-end/46790
* configure.ac (HAVE_LD_EH_GC_SECTIONS_BUG): New test.
* configure: Regenerated.
* config.in: Regenerated.
* varasm.c (default_function_section): Return NULL
if HAVE_LD_EH_GC_SECTIONS_BUG and decl has implicit
section name.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/varasm.c

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2011-02-28 
15:47:20 UTC ---
Author: jakub
Date: Mon Feb 28 15:47:18 2011
New Revision: 170566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170566
Log:
PR debug/47283
* cfgexpand.c (convert_debug_memory_address): Add AS parameter.
Use target address_mode and pointer_mode hooks instead of hardcoded
Pmode and ptr_mode.  Handle some simple cases of extending if
POINTERS_EXTEND_UNSIGNED < 0.
(expand_debug_expr) :
Call convert_debug_memory_address.
(expand_debug_expr) : Pass as to
convert_debug_memory_address.

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

[Bug lto/47924] [4.6 Regression] Missed optimization with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Richard Guenther  2011-02-28 
15:54:55 UTC ---
Hmm.  TYPE_CANONICAL seems to be broken (NULL) and we use alias-set 0 for both
int and short.  Probably because of

  /* Type merging will get confused by the canonical types as they
 are set by the middle-end.  */
  if (in_lto_p)
TYPE_CANONICAL (node) = NULL_TREE;
  *nodep = node = gimple_register_type (node);

we are missing to register the canonical type here.

I have a patch.

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

[richard.nolde at cybox dot com]

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

--- Comment #27 from Richard Nolde  2011-02-28 
15:57:00 UTC ---
On 02/25/2011 10:52 AM, dje at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #26 from David Edelsohn  2011-02-25 
> 17:52:21 UTC ---
> Richard,
>
> Did you look at the list of sites providing pre-built binaries for AIX listed
> on the GCC website:
>
> http://gcc.gnu.org/install/binaries.html
>
> There are multiple options who provide much newer versions of GCC than the 
> ones
> included in the AIX Toolbox.
>
> - David
>
>
David,
Yes, I gave up on the IBM site years ago. The versions of Gcc and 
other tools they provide are either hopelessly out-of-date or broken. 
Dr. Michael Perzl has a site, www.perzl.org, to which the GNU GCC entry 
points, for AIX builds and I use his builds whenever possible. He has 
just updated his gcc builds last Friday and I will try them today.  I do 
like to build from source when possible just to validate the build since 
GCC is about as demanding as anything I know of for the compiler suite.

Thanks,
Richard Nolde

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #18 from Jakub Jelinek  2011-02-28 
16:15:39 UTC ---
Should be fixed now.

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #18 from Jakub Jelinek  2011-02-28 
16:19:10 UTC ---
Fixed.

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  
2011-02-28 16:46:28 UTC ---
Author: paolo
Date: Mon Feb 28 16:46:23 2011
New Revision: 170567

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170567
Log:
2011-02-28  Paolo Carlini  

* testsuite/20_util/ratio/comparisons/comp3.cc: New.

2011-02-28  Marc Glisse  

PR libstdc++/42622
* include/std/ratio (ratio_less): Reimplement to never overflow.
* testsuite/20_util/ratio/comparisons/comp2.cc: Extend.

Added:
trunk/libstdc++-v3/testsuite/20_util/ratio/comparisons/comp3.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/ratio
trunk/libstdc++-v3/testsuite/20_util/ratio/comparisons/comp2.cc

[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini  2011-02-28 
16:48:57 UTC ---
Done.

[Bug target/46887] Invalid AIX linker flag '-bnoerok', it has to be '-bernotok'

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.28 16:50:45
 CC||dje at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2011-02-28 
17:05:10 UTC ---
Author: jakub
Date: Mon Feb 28 17:05:07 2011
New Revision: 170568

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170568
Log:
PR middle-end/47893
* rtl.h (ASLK_REDUCE_ALIGN, ASLK_RECORD_PAD): Define.
(assign_stack_local_1): Change last argument type to int.
* function.c (assign_stack_local_1): Replace reduce_alignment_ok
argument with kind.  If bit ASLK_RECORD_PAD is not set in it,
don't record padding space into frame_space_list nor
use those areas.
(assign_stack_local): Adjust caller.
(assign_stack_temp_for_type): Call assign_stack_local_1 instead
of assign_stack_local, pass 0 as last argument.
* caller-save.c (setup_save_areas): Adjust assign_stack_local_1
callers.

* gcc.dg/pr47893.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr47893.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/caller-save.c
trunk/gcc/function.c
trunk/gcc/rtl.h
trunk/gcc/testsuite/ChangeLog

[Bug target/47926] New: [x32] nested function pointer doesn't work

[hjl.tools at gmail dot com]

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

   Summary: [x32] nested function pointer doesn't work
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


[hjl@gnu-6 ilp32-25]$ cat x.c
void callme (void (*callback) (void));
int
tryme (void)
{
  int ok = 0;
  void callback (void) { ok = 1; }
  callme (&callback);
  return ok;
}
[hjl@gnu-6 ilp32-25]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O2 -g  x.c
x.c: In function ‘tryme’:
x.c:3:1: internal compiler error: in emit_move_insn, at expr.c:3355
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 ilp32-25]$

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Jakub Jelinek  2011-02-28 
17:11:29 UTC ---
Fixed.

[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)

[denisc at gcc dot gnu.org]

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

--- Comment #17 from denisc at gcc dot gnu.org 2011-02-28 17:13:16 UTC ---
Author: denisc
Date: Mon Feb 28 17:13:13 2011
New Revision: 170569

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170569
Log:
2011-02-28  Georg-Johann Lay  

   PR target/45261
   * config/avr/avr.c (avr_option_override): Use error on bad options.
   (avr_help): New function.
   (TARGET_HELP): Define.



Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/avr/avr.c

[Bug driver/47535] -mno-thumb option does not work on ARM compiler configured --with-mode=thumb

[lennox at cs dot columbia.edu]

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

--- Comment #2 from Jonathan Lennox  2011-02-28 
17:30:39 UTC ---
In arm.opt, marm is marked Undocumented, and mthumb is not marked
RejectNegative.

In invoke.texi, -marm isn't mentioned except in the "ARM options" list.

Should I open a options and/or documentation bug on these items?

[Bug driver/47535] -mno-thumb option does not work on ARM compiler configured --with-mode=thumb

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  2011-02-28 
17:37:21 UTC ---
(In reply to comment #2)
> In arm.opt, marm is marked Undocumented, and mthumb is not marked
> RejectNegative.
> 
> In invoke.texi, -marm isn't mentioned except in the "ARM options" list.
> 
> Should I open a options and/or documentation bug on these items?

Yep, sounds like these should be fixed.

[Bug driver/47927] New: GCC driver accepts bogus compiler options on assembly input

[hjl.tools at gmail dot com]

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

   Summary: GCC driver accepts bogus compiler options on assembly
input
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: js...@gcc.gnu.org


[intel64corei7@gnu-34 gcc]$ touch x.s
[intel64corei7@gnu-34 gcc]$ ./xgcc -B./ -mfoobar x.s -c
[intel64corei7@gnu-34 gcc]$

[Bug fortran/47928] New: Gfortran intrinsics documentation paragraph ordering illogical

[jb at gcc dot gnu.org]

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

   Summary: Gfortran intrinsics documentation paragraph ordering
illogical
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


IMHO the order of paragraphs in the intrinsics chapter of the manual is a bit
illogical. For instance, the description comes before the (strangely named)
syntax paragraph, so when the description refers to arguments it's a bit
backwards. Similarly, is the version of the standard where the intrinsic was
introduced really the second most important thing a user needs to know?

Looking at other documents (which are not 100% internally consistent, but
still), based on some googling and looking at man pages we have:

POSIX 2008: name, synopsis, description, return value, errors,
examples, application usage, rationale, future direction, see also,
changelog.

Linux manpages: name, synopsis, description, return value, (notes),
errors, files, conforming to, (notes), bugs, see also, (notes), (bugs)

FreeBSD manpages: name, library, synopsis, description, tuning,
environment, return values, debugging malloc problems, diagnostic
messages, errors, security considerations, notes, see also, standards,
history, authors, bugs

Fortran 2008: synopsis (title), description (short 1-line), class, arguments,
result characteristics (only functions), result value (only functions),
example.

Gfortran currently: title, description, standard, class, syntax,
arguments, example, specific names, see also


While F2008 is perhaps the one most relevant to gfortran, that description is
very terse and often lacks a description at all, so IMHO we shouldn't slavishly
follow that one either.

I'd suggest something like:

Title: name and a-few-words description. No change needed.

Synopsis: The current "Syntax" paragraph.

Description: Longer description.

Class.

Arguments.

Description, alternate placement? Comments?

Return value.

Example.

Notes

Standard

See also

[Bug debug/28047] DWARF output_file_names should really understand DOS pathnames

[ktietz at gcc dot gnu.org]

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

--- Comment #1 from Kai Tietz  2011-02-28 18:23:29 
UTC ---
Author: ktietz
Date: Mon Feb 28 18:23:25 2011
New Revision: 170570

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170570
Log:
2011-02-28  Kai Tietz  

PR debug/28047
* dwarf2out.c (file_table_eq): Use filename_cmp instead of strcmp.
(lookup_filename): Likewise.
* final.c (remap_debug_filename): Use filename_ncmp instead of
strncmp.

2011-02-28  Kai Tietz  

* filename_cmp.c (filename_ncmp): New function.
* functions.texi: Regenerated.

2011-02-28  Kai Tietz  

* filenames.h (filename_ncmp): New prototype.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/final.c
trunk/include/ChangeLog
trunk/include/filenames.h
trunk/libiberty/ChangeLog
trunk/libiberty/filename_cmp.c
trunk/libiberty/functions.texi

[Bug c++/47929] New: unclear "prototype for '...' does not match any in class" diagnostic for templates

[redi at gcc dot gnu.org]

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

   Summary: unclear "prototype for '...' does not match any in
class" diagnostic for templates
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Given the invalid code:

struct S
{
void f();
};

template
void S::f()
{
}

G++ complains:

x.cc:7:6: error: prototype for 'void S::f()' does not match any in class 'S'
x.cc:3:10: error: candidate is: void S::f()

The error message doesn't indicate that one of the signatures is a template, it
might be helpful if it did.

(I have just spent about a minute being dumb and confused because the line with
"template" was scrolled off the top of my editor window and I
couldn't see why the signatures didn't match!)

If the situation is reversed, so the declaration is a template but the
definition is not, the error message makes it obvious:

x.cc:7:6: error: prototype for 'void S::f()' does not match any in class 'S'
x.cc:4:12: error: candidate is: template void S::f()

[Bug debug/28047] DWARF output_file_names should really understand DOS pathnames

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Kai Tietz  2011-02-28 18:41:37 
UTC ---
Fixed on trunk.

[Bug target/47930] New: -marm is undocumented; driver accepts -mno-thumb

[lennox at cs dot columbia.edu]

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

   Summary: -marm is undocumented; driver accepts -mno-thumb
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: len...@cs.columbia.edu
Target: arm*-*-*


According to the resolution of Bug 47535, the opposite of -mthumb on ARM
platforms should be -marm, not -mno-thumb.

However, -marm is undocumented, both in the arm.opt file (it's marked as
Undocumented) and in invoke.texi (except in the "ARM Options" list.)

Moreover, the compiler accepts -mno-thumb (-mthumb is not marked RejectNegative
in arm.opt.)

[Bug driver/47535] -mno-thumb option does not work on ARM compiler configured --with-mode=thumb

[lennox at cs dot columbia.edu]

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

--- Comment #4 from Jonathan Lennox  2011-02-28 
18:42:20 UTC ---
(In reply to comment #3)
> Yep, sounds like these should be fixed.

Filed as Bug 47930.

[Bug lto/47669] bootstrap failure due to undefined references

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Kai Tietz  2011-02-28 19:12:04 
UTC ---
This bug should be already fixed beginning for gcc 4.6 after 12.2.2011. Please
update your sources and retry.
This is a duplicate of PR lto/47225.

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

[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||anhvofrcaus at gmail dot
   ||com

--- Comment #43 from Kai Tietz  2011-02-28 19:12:04 
UTC ---
*** Bug 47669 has been marked as a duplicate of this bug. ***

[Bug target/47926] [x32] nested function pointer doesn't work

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  2011-02-28 
19:12:24 UTC ---
Author: hjl
Date: Mon Feb 28 19:12:18 2011
New Revision: 170571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170571
Log:
Always use ptr_mode on address.

2011-02-28  H.J. Lu  

PR target/47926
* config/i386/i386.c (ix86_trampoline_init): Always use ptr_mode
on address.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c

[Bug c/47931] New: missing -Waddress warning for comparison with NULL

[msebor at gmail dot com]

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

   Summary: missing -Waddress warning for comparison with NULL
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mse...@gmail.com


The -Waddress option causes gcc to emit a warning for suspicious tests of
addresses of functions and objects. The patch that implemented the feature and
the current test for it indicate that the diagnostic is intended to include the
NULL pointer constant. However, gcc fails to diagnose the pointless comparison
against NULL in the test case below.

http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00972.html 
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/Walways-true-1.c 

I note that Wstring-literal-comparison-1.c test exercises the ability to
diagnose comparisons of string literals against 0 while at the same time
allowing such comparisons against null pointer constant. Perhaps this feature
conflicts with the ability to issue warnings for constants of other types.
Alternatively, it's possible that the ability to avoid a diagnostic when a null
pointer constant is used is deliberate.

This is a request to either issue the warning in all cases, or to document the
existing behavior so that it can be relied on with some assurance that it will
continue to work this way in future versions of gcc.

$ cat -n t.c && gcc -Waddress -c t.c
 1  #define NULL (void*)0
 2
 3  int i;
 4
 5  int f() { return &i != 0; }
 6  int g() { return &i != NULL; }
t.c: In function ‘f’:
t.c:5: warning: the address of ‘i’ will never be NULL

[Bug c/47931] missing -Waddress warning for comparison with NULL

[msebor at gmail dot com]

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

--- Comment #1 from Martin Sebor  2011-02-28 19:38:15 
UTC ---
To add a suggested solution to my report: Since many (most?) comparisons will
be against NULL which can be defined as either 0 or (void*)0 I think it would
be best to diagnose both forms. To make it possible to easily silence the
warning I suggest not diagnosing cases of comparison against a null pointer
constant of the same type. I.e., like so:

  int i;

  if (&i);   // warning
  if (&i == 0);  // warning
  if (&i == (void*)0);   // warning
  if (&i == (int*)0);// NO warning

[Bug c/47905] [trans-mem] ipa_tm_decrement_clone_counts ICE

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.28 19:43:38
 Ever Confirmed|0   |1

--- Comment #1 from Aldy Hernandez  2011-02-28 
19:43:38 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01747.html
pending approval

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[th.r.klein at web dot de]

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

--- Comment #10 from th.r.klein at web dot de 2011-02-28 19:52:12 UTC ---
If you can't imagine how to get a usable C++ compiler without libstdc++-v3 (and
libc), please stop wasting your time in thinking about it.
Here is no C++ problem at all.
If it helps you, think the C compiler will be build with --enable-languages=c
switch instead.
Assume there will be no libc for the target architecture.
Especially there is no malloc or free, nor any kind of the other useful toys.
How ever, there will be functions doing similar things, but with different
names and different interfaces.
In this situation it is currently impossible for gcc to build the target-zlib
or the target-libiberty library.

Again, in 4.6 the generation of those libraries is now enabled per default
(previously disabled per default).
On most targets this might make sense, but there must be a way to disable the
generation of those libraries, too.

If you think there is already such a mechanism, then this mechanism did not
work.

[Bug bootstrap/47902] Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers

[skunk at iskunk dot org]

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

--- Comment #3 from Daniel Richard G.  2011-02-28 
20:01:51 UTC ---
I played around with this a bit, and found something rather amusing:

sizeof(pid_t) . compiles just fine
sizeof((pid_t)) ... parse error before `)'

The extra parens do it in. And this is with (an older version of) GCC:

% gcc -v
Reading specs from
/usr/bin/../lib/gcc-lib/powerpc-ibm-aix4.3.3.0/2.9-aix51-020209/specs
gcc version 2.9-aix51-020209

This quirk might also be the cause of bug #47907.

[Bug target/47685] Tail call doesn't work for thumb2

[alexandre.nunes at gmail dot com]

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

--- Comment #3 from Alexandre Pereira Nunes  
2011-02-28 20:25:50 UTC ---
Created attachment 23496
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23496
Patch from the trunk, which I'm testing against 4.5.x

[Bug target/47685] Tail call doesn't work for thumb2

[alexandre.nunes at gmail dot com]

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

--- Comment #4 from Alexandre Pereira Nunes  
2011-02-28 20:27:00 UTC ---
(In reply to comment #2)
> This has been fixed on trunk and will be in the 4.6.0 release. 
> 
> With this commit
> 
> http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00725.html
> 
> cheers
> Ramana


Thanks,

These changes were non-intrusive, so I've applied them to my 4.5.2 toolchain
and it simply "works for me".

Cheers,

Alexandre

[Bug rtl-optimization/47918] [4.6 regression] noreturn discovery broke non local gotos on m68k

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2011-02-28 20:28:27 UTC ---
On Mon, 28 Feb 2011, rguenth at gcc dot gnu.org wrote:

> Also y isn't really noreturn, is it?  Honza?  Shouldn't non-local gotos
> also prevent noreturn?

noreturn means a function does not return to its caller in the ordinary 
way; it says nothing about other control flow from that function 
(non-local gotos, longjmp, throwing exceptions).

[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active

[alexandre.nunes at gmail dot com]

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

--- Comment #6 from Alexandre Pereira Nunes  
2011-02-28 20:30:24 UTC ---
(In reply to comment #5)
> There's a lot of debate about whether the ARM behaviour is a good thing or 
> not.
>  Not pushing the return address means that the debugger cannot generate a
> back-trace in the event that the no-return function is something like abort();
> however, we could avoid pushing most of the other registers.

In a hosted environment, the tradeoff is clear. On a more constrained one, it
would depend on whether or not debugging is an option and if not, there's just
wasted stack. -f(no)omit-frame-pointer could be respected by the port, imho.

[Bug driver/47927] GCC driver accepts bogus compiler options on assembly input

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2011-02-28 20:35:15 UTC ---
This (the general issue of invalid options being accepted because some 
spec passes them down to some subprocess or otherwise accepts them) is 
what my 4.7 patch 
 is intended to 
fix.

[Bug other/42560] include-fixed incomplete when srcdir=builddir

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.28 20:57:37
 CC||rwild at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Ralf Wildenhues  2011-02-28 
20:57:37 UTC ---
I think this bug is a duplicate of PR 35619, and thus fixed in trunk since
revision 151880.  If you could recheck, that would be lovely.  Thanks!

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle  2011-02-28 
21:19:35 UTC ---
New patch which passes Programmatic test case has been submitted for approval.

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

   Keywords||patch
 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  2011-02-28 
21:22:39 UTC ---
Fixed if one adds the code below (copied from gfc_conv_array_parameter).
I'm afraid this could change a memory leak into a double free (see PR 40850).
Also, not quite right (even if the middle-end optimizers are likely to fix it)
because it adds cleanup code to both foo and bar.

diff --git a/trans-expr.c b/trans-expr.c
index d6c1f9f..3919870 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -4900,6 +4900,19 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr)

   /* Take the address of that value.  */
   se->expr = gfc_build_addr_expr (NULL_TREE, var);
+  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+  && expr->ts.u.derived->attr.alloc_comp
+  && expr->expr_type != EXPR_VARIABLE)
+{
+  tree tmp;
+
+  tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+  tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+  
+  /* The components shall be deallocated before
+ their containing entity.  */
+  gfc_prepend_expr_to_block (&se->post, tmp);
+}
 }

[Bug c++/47873] [4.6 Regression] virtual Inheritance - Covariant Virtual Function - Segfault

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  2011-02-28 
21:41:24 UTC ---
Author: jason
Date: Mon Feb 28 21:41:21 2011
New Revision: 170576

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170576
Log:
PR c++/47873
* class.c (update_vtable_entry_for_fn): Check BINFO_LOST_PRIMARY_P
after checking for a non-thunk.

Added:
trunk/gcc/testsuite/g++.dg/inherit/covariant18.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/47902] Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers

[skunk at iskunk dot org]

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

--- Comment #4 from Daniel Richard G.  2011-02-28 
21:59:28 UTC ---
Okay, did some more digging.

So I see that the ac_fn_c_check_type function actually tries a test compilation
first with sizeof(foo_t), and then sizeof((foo_t)), and the test succeeds only
if the first succeeds and the latter fails. So this is actually working as it
should---I'd missed that the test log I pasted in shows pid_t being found
successfully.

The real test failure in config.log is as follows:

configure:5203: checking for pid_t
configure:5203:  /tmp/gcc-4.5.2-build/./prev-gcc/xgcc
-B/tmp/gcc-4.5.2-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-c -g -O2  conftest.c >&5
In file included from conftest.c:71:0:
/tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:72:29: error: conflicting
types for 'int_fast16_t'
/usr/include/sys/inttypes.h:143:18: note: previous declaration of
'int_fast16_t' was here
/tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:75:29: error: conflicting
types for 'uint_fast8_t'
/usr/include/sys/inttypes.h:145:18: note: previous declaration of
'uint_fast8_t' was here
/tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:76:30: error: conflicting
types for 'uint_fast16_t'
/usr/include/sys/inttypes.h:146:18: note: previous declaration of
'uint_fast16_t' was here
configure:5203: $? = 1

Which is basically bug #47907.

I notice that the test for pid_t fails if HAVE_STDINT_H is #defined, and
succeeds otherwise.

[Bug c/47905] [trans-mem] ipa_tm_decrement_clone_counts ICE

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  2011-02-28 
23:25:00 UTC ---
Author: aldyh
Date: Mon Feb 28 23:24:57 2011
New Revision: 170578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170578
Log:
PR 47905
* trans-mem.c (ipa_tm_propagate_irr): Do not propagate to blocks
outside of a TM region.


Added:
branches/transactional-memory/gcc/testsuite/gcc.dg/tm/pr47905.c
Modified:
branches/transactional-memory/gcc/ChangeLog.tm
branches/transactional-memory/gcc/trans-mem.c

[Bug c/47905] [trans-mem] ipa_tm_decrement_clone_counts ICE

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

[Bug lto/47669] bootstrap failure due to undefined references

[anhvofrcaus at gmail dot com]

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

--- Comment #2 from Anh Vo  2011-02-28 23:50:00 
UTC ---
It is agreed that this problem has been fixed. In fact, rebuilding the
gcc-4.6-20110226 snapshot, this problem went away.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  
2011-02-28 23:51:02 UTC ---
Author: paolo
Date: Mon Feb 28 23:50:57 2011
New Revision: 170579

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170579
Log:
2011-02-28  Paolo Carlini  

PR libstdc++/47921
* include/std/streambuf (basic_streambuf<>::__safe_gbump,
__safe_pbump): Add.
* include/bits/streambuf.tcc (basic_streambuf<>::xgetn,
xputn): Use the latter.
* include/bits/streambuf_iterator.h: Likewise.
* src/strstream.cc: Likewise.
* src/streambuf.cc: Likewise.
* src/compatibility.cc: Likewise.
* src/istream.cc: Likewise.
* include/bits/fstream.tcc (basic_filebuf<>::xsgetn): Use setg
instead of gbump.
* include/std/sstream (basic_stringbuf<>::_M_pbump): Add.
* include/bits/sstream.tcc (basic_stringbuf<>::seekoff,
seekpos, _M_sync): Use setg, setp, and _M_pbump.
* config/abi/pre/gnu.ver: Tweak.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/bits/fstream.tcc
trunk/libstdc++-v3/include/bits/sstream.tcc
trunk/libstdc++-v3/include/bits/streambuf.tcc
trunk/libstdc++-v3/include/bits/streambuf_iterator.h
trunk/libstdc++-v3/include/std/sstream
trunk/libstdc++-v3/include/std/streambuf
trunk/libstdc++-v3/src/compatibility.cc
trunk/libstdc++-v3/src/istream.cc
trunk/libstdc++-v3/src/streambuf.cc
trunk/libstdc++-v3/src/strstream.cc

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #9 from Paolo Carlini  2011-02-28 
23:54:34 UTC ---
Fixed for 4.6.0.

[Bug c++/47874] Multiple Inheritance - Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |

--- Comment #5 from Jonathan Wakely  2011-03-01 
01:19:41 UTC ---
PR 47873 is fixed but this still crashes, so not a dup

[Bug c++/47874] Multiple Inheritance - Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID

--- Comment #6 from Jonathan Wakely  2011-03-01 
01:30:28 UTC ---
BugReport::Tier2::Entity::m_Body is null when dereferenced

[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||

--- Comment #11 from Jonathan Wakely  2011-03-01 
01:32:26 UTC ---
FWIW clang++ accepts this

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #29 from Jerry DeLisle  2011-03-01 
02:24:52 UTC ---
Author: jvdelisle
Date: Tue Mar  1 02:24:50 2011
New Revision: 170585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170585
Log:
2011-02-28  Jerry DeLisle  

PR libgfortran/47567
* io/write_float.def (output_float): Move handling of w = 0 to after
output rounding. Check for zero and set zero_flag accordingly. Set
width according to zero_flag. Add better comments.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #30 from Jerry DeLisle  2011-03-01 
02:28:04 UTC ---
Author: jvdelisle
Date: Tue Mar  1 02:28:02 2011
New Revision: 170586

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170586
Log:
2011-02-28  Jerry DeLisle  

PR libgfortran/47567
* gfortran.dg/fmt_fw_d.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_fw_d.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #31 from Jerry DeLisle  2011-03-01 
02:29:43 UTC ---
Thomas, can this be closed yet?

[Bug c/47932] New: __typeof__ prevents VLA from being evaluated

[msebor at gmail dot com]

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

   Summary: __typeof__ prevents VLA from being evaluated
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mse...@gmail.com


The program below shows that the __typeof__ macro prevents the evaluation of
the variable-length array in a context where one would expect it to be
evaluated according to the documentation:

The operand of typeof is evaluated for its side effects if and only if it
is an expression of variably modified type or the name of such a type. 

$ cat <

[Bug fortran/47933] New: [4.6 Regression] FAIL: gfortran.dg/fmt_fw_d.f90

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FAIL: gfortran.dg/fmt_fw_d.f90
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 170586 gave

FAIL: gfortran.dg/fmt_fw_d.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (test for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O3 -fomit-frame-pointer -funroll-loops  (test
for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/fmt_fw_d.f90  -Os  (test for excess errors)

Revision 170579 is OK.

[Bug fortran/47933] [4.6 Regression] FAIL: gfortran.dg/fmt_fw_d.f90

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  2011-03-01 
05:59:11 UTC ---
Author: jvdelisle
Date: Tue Mar  1 05:59:07 2011
New Revision: 170587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170587
Log:
2011-02-28  Jerry DeLisle  

PR libgfortran/47933
* gfortran.dg/fmt_fw_d.f90: Fix test by adding dg-options to avoid
compile errors from older code form.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_fw_d.f90

[Bug fortran/47933] [4.6 Regression] FAIL: gfortran.dg/fmt_fw_d.f90

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jvdelisle at gcc dot
   ||gnu.org
 Resolution||FIXED

--- Comment #2 from Jerry DeLisle  2011-03-01 
06:01:20 UTC ---
Fixed, I ran the test in my local directory and forgot to run in the test
suite.

Mea Culpa.