[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  
2010-10-04 08:51:36 UTC ---
On Mon, 4 Oct 2010, danglin at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
> 
> --- Comment #21 from John David Anglin  
> 2010-10-04 00:41:15 UTC ---
> Still have the following fails on hppa-unknown-linux-gnu:
> 
> FAIL: gcc.dg/pr27898.c (test for excess errors)
> FAIL: gcc.dg/pr28706.c (test for excess errors)
> FAIL: gcc.dg/pr28712.c (test for excess errors)
> FAIL: gcc.dg/pr34989-1.c (test for excess errors)
> 
> /home2/dave/opt/gnu/bin/ld: cannot find -lm

Yep - those are more "interesting" to fix.  I'll either move them
to the lto testsuite or remove them.

[Bug c++/45873] Parameter packs not expanding consistently in function return types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||4.4.3, 4.5.1, 4.6.0

--- Comment #1 from Jonathan Wakely  2010-10-04 
08:11:07 UTC ---
(You didn't say which version this PR is for, although it doesn't work with any
I tried)

Here's a self-contained testcase, with a fix so the workaround actually works
(it was missing the template argument on baz)

template
struct pair
{
template
pair(T1&& t, U1&& u) { }
};

template  class T, class ...Args>
auto foo(Args... args) -> T
{ return T(args...); }

template  class T, class ...Args>
auto bar(Args... args) -> T
{ return T(args...); }


// The following work-around seems to work:
template  class T, class ...Args> struct expand
{ typedef T type; };

template  class T, class ...Args>
auto baz(Args... args) -> typename expand::type
{ return T(args...); }


int main()
{
   // error: no matching function for call to 'foo(int, double)'
   foo(1, 2.0);
   bar(1, 2.0); // OK, returns pair
   baz(1, 2.0); // OK, returns pair
}


I think deduction fails for foo(1, 2.0), though I'm not sure if it
should.

For baz deduction succeeds, the template parameters appear in a
nested-name-specifier which is a non-deduced context.

[Bug target/45847] ICE in supportable_widening_operation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.04 13:59:21
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-10-04 
10:12:17 UTC ---
Well, what happens is that ObjC (not necessarily incorrectly) assumes that
an OBJ_TYPE_REF acts as a function type conversion.  Folding OTOH simply
replaces the called function with an indirect call (most probably due to
my fix for the segfault - we might want to keep the obj-type-ref untouched
instead) without re-instantiating the original type of the called function.

It is still on my (long) TODO list to make the function type of the called
function in a call explicit (and thus not rely on typing of pointers or
decls that eventually get propagated from some weird place).  Until then
function type conversions are not useless and thus need to be preserved
when doing obj-type-ref folding.

[Bug c/45881] New: bit offset of bitfields

[wek at host dot sk]

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

   Summary: bit offset of bitfields
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@host.sk


A (builtin) function, returning bit offset for bitfields within structs, could
be useful to pass bit "addresses" as function parameters.

In analogy to offsetof()/sizeof(), a similar function returning number of bits
of a bitfield could be created, too, although it would be less useful than the
offset.

[Bug tree-optimization/45572] [4.6 Regression] various ICEs with -finline-small-functions -findirect-inlining -finline-functions

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  2010-10-04 
10:15:16 UTC ---
Author: jamborm
Date: Mon Oct  4 10:15:10 2010
New Revision: 164930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164930
Log:
2010-10-04  Martin Jambor  

PR tree-optimization/45572
* ipa-prop.c (ipa_make_edge_direct_to_target): Call
ipa_check_create_node_params.
* ipa-inline.c (add_new_edges_to_heap): Do not insert inlined edges.

* testsuite/g++.dg/ipa/pr45572-1.C: New test.
* testsuite/g++.dg/ipa/pr45572-2.C: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr45572-1.C
trunk/gcc/testsuite/g++.dg/ipa/pr45572-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.04 07:32:12
 CC||hubicka at gcc dot gnu.org,
   ||iains at gcc dot gnu.org
Summary|Can't compile even a|[4.6 Regression] Can't
   |trivial ObjC program with   |compile even a trivial ObjC
   |-fexceptions -O2|program with -fexceptions
   ||-O2
 Ever Confirmed|0   |1

--- Comment #1 from Iain Sandoe  2010-10-04 07:32:12 
UTC ---
the change was:
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00090.html

this also applies to any method call compiled with -fnext-runtime  -O > 0.

I looked at the gimple out from a trivial program at O0 and O1 and didn't see
any material difference around the call construction - which implies that this
is not an optimization problem, but simply that the check doesn't get exercised
at O0).

The code in question is gcc/objc/objc-act.c:6645-6722 

It seems that, although we think we cast the function type in
build_method_call, something is not working (or perhaps the type information is
not set properly elsewhere).

 cc-ing Honza in case he has some ideas :-) ... 
.. (I discussed on irc with him and we came to the initial conclusion that this
is prob. a FE problem).

[Bug middle-end/45877] [4.6 Regression] invalid write in gimplify_and_update_call_from_tree

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2010-10-04 
08:50:40 UTC ---
Yeah.  I might as well take it then.

[Bug c++/45880] New: Template-Methode in Shared Object not resolved when compiled with -O2

[r.menges at nice2cu dot de]

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

   Summary: Template-Methode in Shared Object not resolved when
compiled with -O2
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r.men...@nice2cu.de


Compiling the application with -O2 crashes the application because of a
symbol-not-defined-error, while compiling without -O2 Option or using -g 
works.

Actually I am overloading and not specializing an template-methode, which is
propabily not the right way, but the example is trivial and because the
application crashes when compiled with -O2 and not when compiled with -g or
without the -O2 option i decided to send this bugreport.

System is 
uname -a
Linux dev 2.6.31-gentoo-r10 #1 SMP Mon Mar 8 21:00:17 CET 2010 i686 AMD
Athlon(tm) XP 3000+ AuthenticAMD GNU/Linux
and
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp
--with-arch=i686 --enable-languages=c,c++,java,treelang --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.1,
pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)

The tarBall contains the minimal-exmaple (source of shared libary and
executable), compiler output and short description

[Bug middle-end/45871] lto bootstrap miscompiles expmed.c

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  2010-10-04 
11:12:00 UTC ---
Author: hubicka
Date: Mon Oct  4 11:11:57 2010
New Revision: 164931

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

PR middle-end/45871
* tree-ssa-ccp.c (get_base_constructor): Take HOST_WIDE_INT offset;
use get_ref_base_and_offset to handle references.
(fold_const_aggregate_ref): Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug c++/45880] Template-Methode in Shared Object not resolved when compiled with -O2

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2010-10-04 
14:21:57 UTC ---
why are you using -shared to produce your executable?

[Bug target/45847] ICE in supportable_widening_operation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug target/45752] [4.5 regression] ICE in ix86_vectorize_builtin_vec_perm_ok

[irar at il dot ibm.com]

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

--- Comment #5 from Ira Rosen  2010-10-04 12:39:59 UTC 
---
Thanks, -m32 did the trick.

I am testing a patch.

Thanks,
Ira

[Bug tree-optimization/45622] Suboptimal code generation on arm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.04 09:15:04
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  2010-10-04 
09:15:04 UTC ---
(In reply to comment #0)
> Vorbis author, Timothy Terriberry, was complaining about gcc inefficiency on
> arm, so I asked him write it up in case it would be of use to gcc devs to
> improve gcc. Is this a useful?
> 

The description is rather useful but it would be good to have a copy of the
pre-processed file as HP says in Comment #2. It also helps so that the bug
report is self-consistent . 

What command line options are being used ? i.e. what are the architecture
specific flags ( -march= ? -mfpu= ? -mfloat-abi=? ? ) . If you use --save-temps
you can pickup the .i file .



> 
> This the result of using arm-none-linux-gnueabi-gcc (Gentoo 4.5.0 p1.1) 4.5.0
> with -O3 -fomit-frame-pointer -funroll-loops (this last makes a fairly big
> difference on x86, and so is part of the default flags for the library).

-fomit-frame-pointer is typically not required on ARM. It's one of the ABI's
that originally never had a frame pointer in normal functions and thus removing
the frame pointer doesn't make sense. 

cheers
Ramana

[Bug c++/45880] Template-Methode in Shared Object not resolved when compiled with -O2

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-04 
14:48:51 UTC ---
Please also show the error you're getting, as "crashes the application because
of a symbol-not-defined-error" is not very helpful

I don't think this has anything to do with using a template function, I think
you've just built it wrong

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  2010-10-04 09:25:18 
UTC ---
hm,  I made a very simple root object like this [omitting the cruft to declare
the types & routines for both NeXT and GNU runtimes].


@interface myRootObject {
@public
  Class isa;
  int var;
}

+ (id) initialize;
+(Class) class;
+ (id) alloc ;

- (id) init;
- (int) var;
@end

@implementation myRootObject

+initialize { return self;}
+(Class)class { return object_get_class(self);}
+ (id) alloc { return class_create_instance(self);}

- (id) init {return self;}
- (int) var {return var;}
@end

int main ()
{
  myRootObject *r = [[myRootObject alloc] init];
  r->var = 1;

  return [r var];
}


All is OK until we hit the [r var] line - which fails with the gimple int !=
struct objc_class * error.

however, stepping through the code  in build_objc_method_call() ... seems to
show that the cast is correctly installed.

Breakpoint 4, build_objc_method_call (loc=33157, super_flag=0,
method_prototype=0x41aa7bd0, lookup_object=0x41abe16c, selector=0x41ababa0,
method_params=0x41abc360) at /GCC/gcc-live-trunk/gcc/objc/objc-act.c:6719
6719  t = build3 (OBJ_TYPE_REF, sender_cast, method, lookup_object,
size_zero_node);
(gdb) call debug_tree(sender_cast)
 
unit size 
align 32 symtab 1101764720 alias set -1 canonical type 0x41a192a0
precision 32 min  max 
pointer_to_this >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x41abac00
arg-types 
chain 
chain >>>
pointer_to_this >
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41abac60>
(gdb) call debug_tree(method) 
 
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x41aa2cc0
arg-types 
chain >>
pointer_to_this >
unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x41abaa80>
constant
arg 0 
public external decl_6 QI file  line 0 col 0 align 8>
../tests/root-simple.m:93:3>
(gdb) call debug_tree(lookup_object)
  chain >
unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x41aa2780
pointer_to_this >
side-effects
arg 0 

arg 0 
used unsigned SI file ../tests/root-simple.m line 90 col 17 size
 unit size 
align 32 context  initial >>>
(gdb) next


6720  return build_function_call (loc,
(gdb) call debug_tree(t)
 
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x41abac00
arg-types 
chain 
chain >>>
pointer_to_this >
unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x41abac60>
side-effects
arg 0 
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41abaa80>
constant
arg 0 
public external decl_6 QI file  line 0 col 0 align 8>
../tests/root-simple.m:93:3>
arg 1 
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41aa2780
pointer_to_this >
side-effects
arg 0 
arg 0 >>
arg 2  constant 0>>
(gdb) 

after the function build:

(gdb) call debug_tree(retval)
 
unit size 
align 32 symtab 1101764720 alias set -1 canonical type 0x41a192a0
precision 32 min  max 
pointer_to_this >
side-effects
fn 
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41abac60>
side-effects
arg 0 
constant arg 0 
../tests/root-simple.m:93:3>
arg 1 
side-effects
arg 0 
arg 0 >>
arg 2 > arg 0 
arg 1 
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41aa2960>
static unsigned ignored SI file ../tests/root-simple.m line 93 col 3
size  unit size 
align 32 initial >
../tests/root-simple.m:93:3>

(gdb) call debug_tree(0x41abac00)
 
unit size 
align 32 symtab 1101764720 alias set -1 canonical type 0x41a192a0
precision 32 min  max 
pointer_to_this >
QI
size 
constant 8>
unit size  constant 1>
align 8 symtab 0 alias set -1 canonical type 0x41abac00
arg-types 
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x41aa2780
pointer_to_this >
chain 
chain >>>
pointer_to_this >

[Bug middle-end/45876] [4.6 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2010-10-04 
09:27:25 UTC ---
Created attachment 21955
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21955
gcc46-pr45876.patch

Untested fix.

[Bug debug/45882] New: No debug info for vars depending on unused parameter

[jakub at gcc dot gnu.org]

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

   Summary: No debug info for vars depending on unused parameter
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org


On the attached testcase, b, c, d and e vars unnecessarily don't have any
DW_AT_location information in the debug info.

[Bug middle-end/45876] [4.6 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-10-04 
15:49:18 UTC ---
Author: jakub
Date: Mon Oct  4 15:49:13 2010
New Revision: 164943

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164943
Log:
PR middle-end/45876
* fold-const.c (fold_binary_loc) : Use
arg0's type or its unsigned counterpart as utype.  Convert
arg1 to utype unconditionally.

* gcc.c-torture/compile/pr45876.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr45876.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/45880] Template-Methode in Shared Object not resolved when compiled with -O2

[r.menges at nice2cu dot de]

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

--- Comment #4 from r.menges at nice2cu dot de 2010-10-04 16:14:34 UTC ---
(In reply to comment #3)
> Please also show the error you're getting, as "crashes the application because
> of a symbol-not-defined-error" is not very helpful
> 
> I don't think this has anything to do with using a template function, I think
> you've just built it wrong

Actually i didn't write the makefile myself, it was generated by netbeans
(6.7.).
I am sorry, i was inexact about the error message: The symbol-not-defined
is the error i see when using the original-code, which is executed in an apache
context. The example simply crashes with an segfault.

But you are right, the option -share is what caused the segfault in this
example.
After i removed the -shared option manually from the generated makefile, the
example crashes no more.

The "real" applications runs as an extension to php5 in the context of apache,
it's an libary for c++-php-bridge we builded (so that c++-objects can be mapped
into the space of php). This is where undefined symbol errors crashes the
httpd-process with an error of undefined symbol, when using 

template void printMessage(MsgType msg);
void printMessage(const char *);

it misses the implemetation for std::string.

[Bug c++/45880] Template-Methode in Shared Object not resolved when compiled with -O2

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2010-10-04 
16:34:21 UTC ---
We need a self-contained testcase that reproduces the problem.

I suspect you just need an explicit instantiation of that template function in
the shared library, if nothing instantiates it explicitly then the symbol won't
be defined.

For your broken minimal example that would be done like this:

template void TestTemplateOpt::printMessage(std::string);

[Bug tree-optimization/45883] New: Incorrect store removal when compiling with -fstrict-aliasing

[vegorov at chromium dot org]

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

   Summary: Incorrect store removal when compiling with
-fstrict-aliasing
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vego...@chromium.org


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

When attached test case is compiled with -O1 -fstrict-aliasing GCC removes
store to the GlobalObject::ctx_ field. 

GCC seems to be confused by BitCast in the Handle::operator* but I see
no aliasing violation there.

[Bug c/45884] New: Incorrect removal of check for "less than zero" after adding value to (signed) long

[anders_jagd at yahoo dot com]

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

   Summary: Incorrect removal of check for "less than zero" after
adding value to (signed) long
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: anders_j...@yahoo.com


Created attachment 21959
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21959
Source (test.c), Makefile, Binaries, test.i, gcc -dumpspecs etc. See README.txt

When compiled with -O2, the below (val < 0) check is, under some conditions
(see attachment), optimized away:

...
long val10, val;
char *s;
...
if((*s >= '0') && (*s <= '9')) {
val10 = val * 10; // Skip overflow check, not the issue we are showing
val   = val10 + (*s - '0');

/** OPTIMIZED AWAY IN CASE OF -O2 **/
if(val < 0) {
/* Overflow */
return -1;
}
...
}

Build on ubuntu (2.6.32-25-generic)
gcc version 4.4.3-4ubuntu5
machine i486-linux-gnu

Attaching complete test case with:

   Makefile
   Source (test.c)
   Binaries
   Result from compiling with -save-temps (test.i)
   System configuration, gcc -dumpspecs, etc.

[Bug c++/45668] Request warning for mismatched declaration/definition attributes (instead of chances for an indirect error)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.04 18:01:38
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jason Merrill  2010-10-04 
18:01:38 UTC ---
Adding an aligned attribute shouldn't be a problem, since we don't know the
alignment of a type until it's complete anyway.

As previously mentioned, we need an actual testcase to work on this issue.

[Bug c/45884] Incorrect removal of check for "less than zero" after adding value to (signed) long

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-10-04 
18:01:46 UTC ---
Signed integer overflow is undefined so what GCC is doing is correct.  Use
-fwarpv if you want it to be defined to wrapping.

[Bug c++/45668] Request warning for mismatched declaration/definition attributes (instead of chances for an indirect error)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jason Merrill  2010-10-04 
18:03:07 UTC ---
Oh, I see there is a testcase in 45642; I'll just close this one.

[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  2010-10-04 
18:05:18 UTC ---
It shouldn't be necessary to declare the alignment until the point when we're
completing the class.

[Bug c/45884] Incorrect removal of check for "less than zero" after adding value to (signed) long

[anders_jagd at yahoo dot com]

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

--- Comment #2 from Anders Jagd  2010-10-04 
18:12:16 UTC ---
(In reply to comment #1)
> Signed integer overflow is undefined so what GCC is doing is correct.  Use
> -fwarpv if you want it to be defined to wrapping.

I acknowledge that ISO/IEC 9899 defines integer overflow to be undefined. What
GCC doing is thus "not incorrect". However, would this maybe be a bit too
aggressive optimization at -O2 ?

[Bug c/45884] Incorrect removal of check for "less than zero" after adding value to (signed) long

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2010-10-04 
18:13:15 UTC ---
See -fstrict-overflow too.

[Bug target/45885] New: ICE in arm_dbx_register_number, at config/arm/arm.c:22071

[rmansfield at qnx dot com]

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

   Summary: ICE in arm_dbx_register_number, at
config/arm/arm.c:22071
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com


$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.6.0 20101004 (experimental) [trunk revision 164952] (GCC) 


$ ./xgcc -B. -c -O3 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -g ~/ice.i
/home/ryan/ice.i: In function 'OVGTessellateFillPath':
/home/ryan/ice.i:80:16: warning: incompatible implicit declaration of built-in
function 'fabsf' [enabled by default]
/home/ryan/ice.i:103:2: warning: visibility attribute not supported in this
configuration; ignored [-Wattributes]
/home/ryan/ice.i:103:2: internal compiler error: in arm_dbx_register_number, at
config/arm/arm.c:22071
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

[nicolai.stange at zmaw dot de]

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

--- Comment #7 from Nicolai Stange  2010-10-04 
19:05:30 UTC ---
libgomp, libgcc and libssp are the shared libs of gcc.
(actually the correct libstdc++ and libgfortran are also found if the correct
libgcc is found as they never are linked in without it).
libgomp comes with an spec file that is installed into the lib dir.

I've added switches to gcc's configure to specify the link specs of these two
libs.

I've tested it and it works perfectly for me.

[Bug bootstrap/42474] SIGSEGV in linemap_lookup

[andrewbachmann at yahoo dot com]

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

--- Comment #2 from Andrew Bachmann  
2010-10-04 21:39:34 UTC ---
I have tried again in the 4.4.4 build, and I received the same error.  It seems
like this is related to precompiled headers somehow.  

So, a workaround is to not use precompiled headers.

[Bug debug/45849] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7336 with -O -g

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2010-10-04 
22:02:32 UTC ---
Author: jakub
Date: Mon Oct  4 22:02:28 2010
New Revision: 164962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164962
Log:
PR debug/45849
* var-tracking.c (strip_pointer_flags): New function.
(emit_note_insn_var_location): If rtx_equal_p check failed,
retry on locations simplified with simplify_replace_fn_rtx
and strip_pointer_flags as its callback.

* gcc.dg/debug/pr45849.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr45849.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug target/45886] New: [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice

[siarhei.siamashka at gmail dot com]

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

   Summary: [ARM] support for __ARM_PCS_VFP predefined symbol in
gcc 4.5.x would be very nice
   Product: gcc
   Version: 4.5.1
   URL: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02186.htm
l
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com
CC: rearn...@arm.com
  Host: arm-unknown-linux-gnueabi
Target: arm-unknown-linux-gnueabi
 Build: arm-unknown-linux-gnueabi


This is quite important for JIT code when we want so support all ABI variants
properly. Because now gcc 4.5.x supports -mfloat-abi=hard, being able to
identify its use is also needed.

[Bug debug/45849] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7336 with -O -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Jakub Jelinek  2010-10-04 
22:05:57 UTC ---
Fixed.

[Bug libgomp/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa-unknown-linux-gnu  |hppa*-*-*
   Host|hppa-unknown-linux-gnu  |hppa*-*-*
Summary|FAIL: libgomp.c/pr34513.c   |[4.6 Regression] FAIL:
   |execution test  |libgomp.c/pr34513.c
   ||execution test
  Build|hppa-unknown-linux-gnu  |hppa*-*-*

--- Comment #1 from John David Anglin  2010-10-04 
22:07:52 UTC ---
(gdb) r
Starting program:
/home/dave/gnu/gcc-4.6/objdir/hppa-linux/libgomp/testsuite/pr34513.xg 
[Thread debugging using libthread_db enabled]
[New Thread 0x41153440 (LWP 14854)]
[New Thread 0x41953440 (LWP 14855)]
[New Thread 0x42153440 (LWP 14856)]

Program received signal SIGABRT, Aborted.
0x4076487c in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
67../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x4076487c in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x40769228 in abort () at abort.c:92
#2  0x00010788 in main ()
at /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/pr34513.c:31

errors = 3

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  2010-10-04 
22:12:50 UTC ---
Thanks for the testcase.
  http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00059.html
seems to help with the testcase.  Does it also fix bootstrap?

[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin

[bernds at gcc dot gnu.org]

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

--- Comment #10 from Bernd Schmidt  2010-10-04 
22:13:12 UTC ---
Does
  http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00059.html
fix it?

[Bug tree-optimization/45883] Incorrect store removal when compiling with -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-10-04 
22:20:27 UTC ---
Looks related to PR42834 (-fno-builtin-memcpy fixes it)

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[siarhei.siamashka at gmail dot com]

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

--- Comment #2 from Siarhei Siamashka  
2010-10-04 22:59:56 UTC ---
(In reply to comment #1)
> So the compiler is correct not to be using vld1 for this code.  The memory
> format of int32x4_t is defined to be the format of a neon register that has
> been filled from an array of int32 values and then stored to memory using VSTM
> (or equivalent sequence).  The implication of all this is that int32x4_t does
> not (necessarily) have the same memory layout as int32_t[4].

Could you elaborate on this? Specifically about the case when memory format for
VSTM and VST1 may differ.

I thought that VST1 instruction could be always used as a replacement for VSTM,
it is just a little bit less convenient in some cases because it is lacking
some more advanced addressing modes. Moreover, VSTM is VFP instruction and VST1
is NEON one. So I guess mixing VSTM with true NEON instructions may be
additionally a bad idea (for performance reasons on Cortex-A9 or other
processors?).

There also used to be FLDMX/FSTMX instructions, but they are deprecated now. I
believe they existed specifically to reserve the use of normal VFP load/store
instructions for floating point data formats only, but later this turned out to
be unnecessary.

> arm_neon.h provides intrinsics for filling neon registers from arrays in
> memory, and in this case I think you should be using these directly.  That is,
> your macro should be modified to contain:
> 
> #define X(n) {int32x4_t v; v = vld1q_s32((const int32_t*)&p[n]); v =
> vaddq_s32(v, a); v = vorrq_s32(v, b); vst1q_s32 ((int32_t*)&p[n], v);}

I'm sorry, but this looks like a completely unjustified limitation to me. Why
intrinsics should be so much more difficult and less intuitive to use than just
inline assembly? Additionally, gcc allows to use normal arithmetic operations
on vector data types, something like:

void x(int32x4_t a, int32x4_t b, int32x4_t *p)
{
#define X(n) p[n] += a; p[n] |= b;
X(0); X(1); X(2); X(3); X(4); X(5); X(6); X(7);
X(8); X(9); X(10); X(11); X(12);
}

> There are still problems after doing this, however.  In particular the 
> compiler
> is not correctly tracking alias information for the load/store intrinsics,
> which means it is unable to move stores past loads to reduce stalls in the
> pipeline.

OK, thanks for the explanation.

> The stack wastage appears to be fixed in trunk gcc; at least I don't see any
> stack allocation for your testcase.

Yes, looks like it got a little bit better. Anyway stack allocation shows up
again after adding just a few more of these X() macros:
... X(13); X(14); X(15); X(16); ...

[Bug middle-end/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero

[siarhei.siamashka at gmail dot com]

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

Siarhei Siamashka  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #3 from Siarhei Siamashka  
2010-10-04 23:19:26 UTC ---
So if I understand it correctly, there are 2 independent performance issues
here:
1. one in the middle-end (redundant comparison with -1) when -O2 optimization
is selected.
2. another in ARM target, because it fails to produce efficient code with -Os
optimizations, while x86 can.

I just remembered that Mozilla has been using -Os optimizations up until now
because it was providing the best performance for them:
http://gcc.gnu.org/ml/gcc/2010-06/msg00715.html
I wonder if this particular missed-optimization issue is contributing to the
occasional performance advantage of -Os over -O2 (other than smaller code size
and reduced pressure on the instructions cache). Anyway, when looking at any
code generated by gcc, simple loops and branches always tend to contain
redundant instructions.

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-10-04 23:45:57 UTC ---
On Mon, 4 Oct 2010, siarhei.siamashka at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725
> 
> --- Comment #2 from Siarhei Siamashka  
> 2010-10-04 22:59:56 UTC ---
> (In reply to comment #1)
> > So the compiler is correct not to be using vld1 for this code.  The memory
> > format of int32x4_t is defined to be the format of a neon register that has
> > been filled from an array of int32 values and then stored to memory using 
> > VSTM
> > (or equivalent sequence).  The implication of all this is that int32x4_t 
> > does
> > not (necessarily) have the same memory layout as int32_t[4].
> 
> Could you elaborate on this? Specifically about the case when memory format 
> for
> VSTM and VST1 may differ.

Big-endian.

I previously explained the issues with big-endian NEON vectors in GCC at 
length:

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

  Component|libstdc++   |testsuite

--- Comment #15 from Hans-Peter Nilsson  2010-10-04 
23:51:54 UTC ---
(In reply to comment #9)
> ... something is wrong
> with lseek().

It certainly is!  There are at least three issues here.

1. The simulator has a bug: on a 64-bit host, the offset parameter to the lseek
call is in-effect zero-extended from 32-bit-long to 64-bit-long.  This causes
any change to the sequence of lseeks to show random regressions.

2. There is a test-suite hook,
libstdc++-v3/testsuite/lib/libstdc++.exp:check_v3_target_fileio that should
catch this.

3. Fixing #1 certainly shows improvement; 14 additional tests pass, but also 2
regressions, so there's still another issue...

Due to (#1 and) #2, I'm recategorizing this PR as belonging to the testsuite
and I'm assigning it to myself, pending a patch for #2 and investigating #3.
Sorry for the noise, feel free to remove yourself from CC if this made you lose
interest. :)

For the record, an strace excerpt of the simulator before and after r164529
shows the issue better than the actual simulator trace I had in mind.  (Though
it also shows that the failing ltrace call is an addition, and I guess you
would want to eliminate it, if possible.  Oops, four issues!  Maybe that was
what the attached patch was about...)

r164528:
...
open("seekoff-2io.tst", O_RDWR) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=116, ...}) = 0
lseek(4, 0, SEEK_CUR)   = 0
lseek(4, 2, SEEK_SET)   = 2
fstat(4, {st_mode=S_IFREG|0644, st_size=116, ...}) = 0
lseek(4, 0, SEEK_CUR)   = 2
read(4, " ", 1) = 1
read(4, "9", 1) = 1
lseek(4, 3, SEEK_SET)   = 3
write(4, "\n", 1)   = 1
lseek(4, 4, SEEK_SET)   = 4
read(4, "9", 1) = 1
lseek(4, 1, SEEK_CUR)   = 6
read(4, "1", 1) = 1
read(4, "1", 1) = 1
lseek(4, 4294967295, SEEK_CUR)  = 4294967303
write(4, "x", 1)= 1
write(4, "\n", 1)   = 1
lseek(4, 0, SEEK_CUR)   = 4294967305
read(4, "", 1)  = 0
read(4, "", 1)  = 0
lseek(4, 0, SEEK_END)   = 4294967305
write(4, "\n", 1)   = 1
write(4, "because because because. . .", 28) = 28
lseek(4, 4294967295, SEEK_END)  = 8589934629
read(4, "", 1)  = 0
lseek(4, 4294967295, SEEK_CUR)  = 12884901924
read(4, "", 1)  = 0
read(4, "", 1)  = 0
read(4, "", 1)  = 0
close(4)= 0
...

r164529:
...
open("seekoff-2io.tst", O_RDWR) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=116, ...}) = 0
lseek(4, 0, SEEK_CUR)   = 0
lseek(4, 2, SEEK_SET)   = 2
fstat(4, {st_mode=S_IFREG|0644, st_size=116, ...}) = 0
lseek(4, 0, SEEK_CUR)   = 2
read(4, " ", 1) = 1
read(4, "9", 1) = 1
lseek(4, 3, SEEK_SET)   = 3
write(4, "\n", 1)   = 1
lseek(4, 4, SEEK_SET)   = 4
read(4, "9", 1) = 1
lseek(4, 1, SEEK_CUR)   = 6
read(4, "1", 1) = 1
read(4, "1", 1) = 1
lseek(4, 0, SEEK_CUR)   = 8
lseek(4, 4294967295, SEEK_CUR)  = 4294967303
write(4, "x", 1)= 1
write(4, "\n", 1)   = 1
lseek(4, 0, SEEK_CUR)   = 4294967305
read(4, "", 1)  = 0
read(4, "", 1)  = 0
write(2, "assertion \"", 11assertion ")= 11
write(2, "c1 == c3", 8c1 == c3) = 8
write(2, "\" failed: file \"", 16" failed: file ")  = 16
...

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.04 23:59:13
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[muravev at yandex dot ru]

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

--- Comment #7 from Ilya Murav'jov  2010-10-05 
00:10:20 UTC ---
AFAIK, users of Boost.Function suffer from this PR too.
https://svn.boost.org/trac/boost/ticket/4538

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

--- Comment #16 from David Krauss  2010-10-05 00:24:35 
UTC ---
(In reply to comment #15)
> r164528:
> ...
> read(4, "1", 1) = 1
> lseek(4, 4294967295, SEEK_CUR)  = 4294967303
> write(4, "x", 1)= 1
> write(4, "\n", 1)   = 1
> lseek(4, 0, SEEK_CUR)   = 4294967305
> read(4, "", 1)  = 0
> read(4, "", 1)  = 0
> lseek(4, 0, SEEK_END)   = 4294967305
> ...
> 
> r164529:
> ...
> read(4, "1", 1) = 1
> lseek(4, 0, SEEK_CUR)   = 8
> lseek(4, 4294967295, SEEK_CUR)  = 4294967303
> write(4, "x", 1)= 1
> write(4, "\n", 1)   = 1
> lseek(4, 0, SEEK_CUR)   = 4294967305
> read(4, "", 1)  = 0
> read(4, "", 1)  = 0
> write(2, "assertion \"", 11assertion ")= 11

The failure had nothing to do with the additional seek. The excerpts above show
that the added operation didn't move the file pointer… the failure occurred at
the same position as success before the patch.

What the testcase ends up doing is extending the file and then reading past
EOF. That's not illegal behavior and the case as written should still pass
after comparing EOF == EOF, just as it did before my patch.

Hmm, yep, caught a bug in my patch! Thanks!

[Bug other/32998] -frecord-gcc-switches issues

[roland at redhat dot com]

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

--- Comment #10 from Roland McGrath  2010-10-05 
00:41:45 UTC ---
(In reply to comment #9)
> Wouldn't be appropriate to append these flags also/instead to DW_AT_producer?
> This way they get easily associated with the specific CU.

That makes some sense.  It also should get the strings nicely merged by the
linker in the .debug_str section.

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

--- Comment #18 from Hans-Peter Nilsson  2010-10-05 
01:58:45 UTC ---
(In reply to comment #16)
> What the testcase ends up doing is extending the file and then reading past
> EOF. That's not illegal behavior and the case as written should still pass
> after comparing EOF == EOF, just as it did before my patch.
> 
> Hmm, yep, caught a bug in my patch! Thanks!

Um... let me see if I got this right: the simulator with a buggy lseek caught a
bug in your patch not seen in a correctly working environment?  (That could
actually be issue #3.)

If so, I think that makes the top 5 weird bug behaviors in my experience!
(Ok, only some 22 years, nothing to speak of.)

Don't forget that for the new patch, I think we need a separate new regression
test-case, one that "works" without relying on buggy simulators. :-D

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

--- Comment #19 from David Krauss  2010-10-05 02:58:04 
UTC ---
(In reply to comment #18)
> Um... let me see if I got this right: the simulator with a buggy lseek caught 
> a
> bug in your patch not seen in a correctly working environment?  (That could
> actually be issue #3.)

Yep, accidentally seeking off the end causes read() to fail. Trying to read
from the streambuf after a write causes a mode switch and virtual flush, which
succeeds. I accidentally set the return error value variable to success based
on flush success, causing getc() not to return EOF despite failure. The
subsequent read did not have a flush and correctly returned EOF. Apparently
reading after a write at EOF is not in the tests.

> If so, I think that makes the top 5 weird bug behaviors in my experience!
> (Ok, only some 22 years, nothing to speak of.)
> 
> Don't forget that for the new patch, I think we need a separate new regression
> test-case, one that "works" without relying on buggy simulators. :-D

Yeah lol, I don't know if the regression case is really necessary, but I
suppose I should work it in somewhere. Should I reference this bug in regards
to such a change, or does that make more work for you?

Do you mean 22 years of life or 22 years in the field ;v) … I think this is
just serendipitous. Today is my 26th birthday, so you're either making me feel
old or just experienced… I guess cutting my teeth on old Classic Mac OS and
Apple Open Firmware (a fairly large Forth operating system, also deceased) gave
me a fair share of weirdness, nothing has really surprised me for years… but I
did quit software for a while in the meantime and this is my first return to
operating systems…

[Bug testsuite/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

--- Comment #20 from Hans-Peter Nilsson  2010-10-05 
04:02:00 UTC ---
(In reply to comment #19)
> Apparently
> reading after a write at EOF is not in the tests.

Good you noticed.

> Yeah lol, I don't know if the regression case is really necessary, but I
> suppose I should work it in somewhere.

It's a requirement for changes to the code-base.  The thinking goes, if you
have a patch for a bug, you need to a) prove it, and b) make sure the fix
doesn't get undone by later patches.

> Should I reference this bug in regards
> to such a change, or does that make more work for you?

Referencing would be slightly better than doing it from scratch, methinks.
I don't think I'm doing any extra work here.

> Do you mean 22 years of life or 22 years in the field ;v)

Um, in the field...  It's actually somewhat more, but never mind.

> … I think this is
> just serendipitous. Today is my 26th birthday, so you're either making me feel
> old or just experienced…

Not sure I follow your thinking there, but Happy Birthday.  Consider this bug
report an early gift. :]

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #8 from Florian Weimer  2010-10-05 04:48:54 
UTC ---
(In reply to comment #6)

> The general problem is that alias analysis is hard, thus follows that proper
> warnings are equally hard.

Note that it says "will break strict-aliasing rules", not "might break
strict-aliasing rules" (which also exists). I think the user can reasonably
expect that the "will break" variant is actually true.

[Bug bootstrap/45888] New: tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

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

   Summary: tm.texi generation is not portable, rule is broken
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rw...@gcc.gnu.org


The thread starting at:

lists a number of issues around tm.texi:

The output produced by genhooks is not portable (newline encoding), so it
should either produce binary output, or diff should be used to compare for
changes.

The tm.texi rule is broken because it references non-existing
$(srcdir)/doc/target.def.  Also, it seems references to source and build tree
are a bit messed up.  The logic to trigger a warning for updating the wrong
file could need a look-over, too.