[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[schwab at suse dot de]

--- Comment #38 from schwab at suse dot de  2009-01-21 09:16 ---
(In reply to comment #35)
> "system", which is a function argument, is trashed here.

But it's not modified between setjmp and longjmp, so its value must be
preserved.


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-21 10:13 ---
Confirmed.  PRE doesn't find a leader for a NAME (!?) when inserting
{nop_expr,g_2.7_47}.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 10:13:21
   date||
Summary|ice in  |[4.4 Regression] ice in
   |find_or_generate_expression,|find_or_generate_expression,
   |at tree-ssa-pre.c:2769  |at tree-ssa-pre.c:2769
   Target Milestone|--- |4.4.0
Version|unknown |4.4.0


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

[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code

[hpreg at vmware dot com]

--- Comment #4 from hpreg at vmware dot com  2009-01-21 10:19 ---
Andrew,

With respect to your comment #2: initializing all the variables to 0 does not
solve the problem, which is that gcc does not understand that %rbp is
clobbered.

With respect to your comment #3: as explained in the bug description, it is
_not_ possible to mark r8 through r15 as clobbered in an inline-asm statement.
Hence the "mess".


-- 


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

[Bug c++/38928] New: infinite loop on error message in C++ only

[etienne_lorrain at yahoo dot fr]

etie...@pc300:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
etie...@pc300:~$ cat tmp.c
struct id_struct
{
unsigned char is_ip_addrs[4];
};

struct addr_struct
{
unsigned shortfamily;
unsigned short   port;
struct   id_struct id;
char *name;
};

int main (int argc, char **argv)
{
struct addr_struct tmp_addr_struct = {
family: 1,
port: 666,
id: 0,
name: (char []){"psig TCP"}
};
return 2;
}
etie...@pc300:~$ gcc tmp.c
etie...@pc300:~$ g++ tmp.c 2> log
^C
etie...@pc300:~$ head log
tmp.c: In function 'int main(int, char**)':
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
etie...@pc300:~$


-- 
   Summary: infinite loop on error message in C++ only
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script

[jwakely dot gcc at gmail dot com]

--- Comment #8 from jwakely dot gcc at gmail dot com  2009-01-21 12:21 
---
Not sure what happened yesterday, but I get the same result for both libgomp
and libstdc++ today: both interpret the GNU ld version as 1800


-- 


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

[Bug c/38925] gcc ignores use of %rbp via assembly, generates bad code

[thutt at vmware dot com]

--- Comment #5 from thutt at vmware dot com  2009-01-21 13:06 ---
(In reply to comment #2)
> I think this code is undefined as you are using uninitialized variables for
> input of the inline-asm.
> 

I disagree.  

The registers are intended to have their *current*
values saved across the 'vmrun' instruction.  Since it's
not possible to specify registers R8 through R15 in constraints, bug  
16331 suggests this obtuse workaround.

The intent of this code is twofold: demonstrate the assginment of 
two variables to '%rbp' and to show that it's not possible to 
show clobber an arbitrary set of registers.  It does both well.

Furthermore, if you'd take the code and compile with all the initializations,
in place, you would have seen that it makes no difference whatsoever: two
variables are assigned to '%rbp', just the same.

But, all the initializations also make the code incorrect: the point is to
either save all the registers across the 'vmrun' instruction, or to
clearly indicate to the compiler that all the registers are clobbered 
at the end of the 'vmrun' instruction.


-- 

thutt at vmware dot com changed:

   What|Removed |Added

  Component|inline-asm  |c


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

[Bug c/38925] gcc ignores use of %rbp via assembly, generates bad code

[thutt at vmware dot com]

--- Comment #6 from thutt at vmware dot com  2009-01-21 13:08 ---
(In reply to comment #3)
> Also I think the inline-asm could be improved so that the inline-asm just 
> marks
> the registers that are clobbered instead of doing the mess you are doing.  
> 

Can you provide an example of how this can be done?
The whole point of this report is to show that what you claim isn't 
actually possible.  If it is possible, then that'd be a great thing --
but someone shoould update the docs to show that it is possible.

Here's a wacky idea -- update the constraints system for the x86_64 target
to allow any available (and specific) register to be constrained.


-- 


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

[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2009-01-21 13:35 ---
Subject: Bug 38887

Author: domob
Date: Wed Jan 21 13:34:55 2009
New Revision: 143541

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143541
Log:
2009-01-21  Daniel Kraft  

* trans-stmt.c (gfc_conv_elemental_dependencies):  Cleaned up comment.

2009-01-21  Daniel Kraft  

PR fortran/38887
* runtime/in_unpack_generic.c (internal_unpack):  Return instead of
abort when called with empty array.
* m4/in_unpack.m4:  Ditto.
* generated/in_unpack_i1.c:  Regenerated.
* generated/in_unpack_i2.c:  Regenerated.
* generated/in_unpack_i4.c:  Regenerated.
* generated/in_unpack_i8.c:  Regenerated.
* generated/in_unpack_i16.c: Regenerated.
* generated/in_unpack_r4.c:  Regenerated.
* generated/in_unpack_r8.c:  Regenerated.
* generated/in_unpack_r10.c: Regenerated.
* generated/in_unpack_r16.c: Regenerated.
* generated/in_unpack_c4.c:  Regenerated.
* generated/in_unpack_c8.c:  Regenerated.
* generated/in_unpack_c10.c: Regenerated.
* generated/in_unpack_c16.c: Regenerated.

2009-01-21  Daniel Kraft  

PR fortran/38887
* gfortran.dg/mvbits_5.f90:  New test.

Added:
trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/in_unpack_c10.c
trunk/libgfortran/generated/in_unpack_c16.c
trunk/libgfortran/generated/in_unpack_c4.c
trunk/libgfortran/generated/in_unpack_c8.c
trunk/libgfortran/generated/in_unpack_i1.c
trunk/libgfortran/generated/in_unpack_i16.c
trunk/libgfortran/generated/in_unpack_i2.c
trunk/libgfortran/generated/in_unpack_i4.c
trunk/libgfortran/generated/in_unpack_i8.c
trunk/libgfortran/generated/in_unpack_r10.c
trunk/libgfortran/generated/in_unpack_r16.c
trunk/libgfortran/generated/in_unpack_r4.c
trunk/libgfortran/generated/in_unpack_r8.c
trunk/libgfortran/m4/in_unpack.m4
trunk/libgfortran/runtime/in_unpack_generic.c


-- 


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

[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments

[domob at gcc dot gnu dot org]

--- Comment #5 from domob at gcc dot gnu dot org  2009-01-21 13:37 ---
Fixed on trunk by converting the abort() call in internal_unpack to a return
(this is also what the "real" unpack library call does).


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[dberlin at dberlin dot org]

--- Comment #2 from dberlin at gcc dot gnu dot org  2009-01-21 14:09 ---
Subject: Re:  [4.4 Regression] ice in 
find_or_generate_expression, at tree-ssa-pre.c:2769

names should be self-leaders.
Sounds like a set bitmap messup somewhere or an equality function gone
bad or something.
i'll take a look

On Wed, Jan 21, 2009 at 5:13 AM, rguenth at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-21 10:13 
> ---
> Confirmed.  PRE doesn't find a leader for a NAME (!?) when inserting
> {nop_expr,g_2.7_47}.
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> 
> CC||dberlin at gcc dot gnu dot
>   ||org
> Status|UNCONFIRMED |NEW
>  Component|c   |tree-optimization
> Ever Confirmed|0   |1
>  GCC build triplet|i686-pc-linux-gnu   |
>   GCC host triplet|i686-pc-linux-gnu   |
>  GCC target triplet|i686-pc-linux-gnu   |
>   Keywords||ice-on-valid-code
>   Last reconfirmed|-00-00 00:00:00 |2009-01-21 10:13:21
>   date||
>Summary|ice in  |[4.4 Regression] ice in
>   |find_or_generate_expression,|find_or_generate_expression,
>   |at tree-ssa-pre.c:2769  |at tree-ssa-pre.c:2769
>   Target Milestone|--- |4.4.0
>Version|unknown |4.4.0
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38926
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug target/38547] duplicate symbols with g++ on AIX

[bruprz1 at lhsystems dot pl]

--- Comment #18 from bruprz1 at lhsystems dot pl  2009-01-21 14:39 ---
(In reply to comment #13)
> symbols. The assembly files generated by GCC for AIX always have included
> multiple symbol definitions for certain global variable and function

If I understand correctly, that statement means that there have always been
duplicate symbols under AIX. This may be true for 5.3, but:

We maintain an application in C/C++ (over 1.5 million ELOC, with shared
libraries) and since we had upgraded to AIX 5.2 and GCC4.1.1 we didn't have
even one duplicate symbol there. Before that we indeed had duplicate symbols in
C++ code (since weak symbols were not supported). Please have a look at the
following:

host52:/tmp$ oslevel -r
5200-00
host52:/tmp$ /usr/local/gcc/3.4.3/bin/g++ a.cc
host52:/tmp$ /usr/local/gcc/4.1.1/bin/g++ a.cc


host53:/tmp$ oslevel -r
5300-02
host53:/tmp$ /usr/local/gcc/4.0.2/bin/g++ a.cc
ld: 0711-224 WARNING: Duplicate symbol: .__divdi3
ld: 0711-224 WARNING: Duplicate symbol: .__moddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivdi3
ld: 0711-224 WARNING: Duplicate symbol: .__umoddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivmoddi4
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
host53:/tmp$ /usr/local/gcc/4.3.2/bin/g++ a.cc
ld: 0711-224 WARNING: Duplicate symbol: .__divdi3
ld: 0711-224 WARNING: Duplicate symbol: .__moddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivdi3
ld: 0711-224 WARNING: Duplicate symbol: .__umoddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivmoddi4
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

It looks like a 5.3 regression - could you have look at the problem again,
please?


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[vmakarov at redhat dot com]

--- Comment #39 from vmakarov at redhat dot com  2009-01-21 15:39 ---
Yes, right.  I should have read the standard itself (not gcc manual which
states "ISO C says that automatic variables that are not declared `volatile'
have undefined values after a `longjmp'").  That is good that Andrew checked
and posted what the current standard saying about setjmps.

So the code is actually valid and it is an IRA bug.

Working on the PR, I found that GCC even guarantees that modified local
variable will have the right values after longjmp because GCC always puts
pseudos intersected setjmps on the stack.  Probably it is the safest behaviour.

In any way the patch solving the PR is ready and I'll submit it today after
checking bootstraps on a few machines.



-- 


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

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-21 15:43 ---
Mine.  I am working on adding versioning for non-constant strides.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||irar at il dot ibm dot com
 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 15:43:08
   date||


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

[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2009-01-21 16:15 ---
Subject: Bug 26693

Author: dodji
Date: Wed Jan 21 16:14:49 2009
New Revision: 143546

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143546
Log:
gcc/ChangeLog:
2009-01-21  Dodji Seketeli  

PR c++/26693
* c-decl.c: (clone_underlying_type): Move this  ...
* c-common.c (set_underlying_type): ... here.
Also, make sure the function  properly sets TYPE_STUB_DECL() on
the newly created typedef variant type.
(is_typedef_decl ): New entry point.
* tree.h: Added a new member member_types_needing_access_check to
struct tree_decl_non_common.
(set_underlying_type): New entry point.
(is_typedef_type): Likewise.

gcc/cp/ChangeLog/
2009-01-21  Dodji Seketeli  

PR c++/26693
* decl2.c (grokfield): when a typedef appears in a
class, create the typedef variant type node for it.
(save_template_attributes): Creating typedef variant type node
 here is now useless.
* decl.c (grokdeclarator): If the typedef'ed struct/class was
anonymous, set the proper type name to all its type variants.
* name-lookup.c (pushdecl_maybe_friend): Reuse the
set_underlying_type function to install typedef variant types.
* cp-tree.h (MEMBER_TYPES_NEEDING_ACCESS_CHECK): New template accessor
macro.
(append_type_to_template_for_access_check): New entry points.
* semantics.c (check_accessibility_of_qualified_id):
When a typedef that is a member of a class appears in a template,
add it to the template. It will be ...
* pt.c (instantiate_class_template, instantiate_template ): ... access
checked at template instantiation time.
(tsubst): Handle the case of being called with NULL args.
(resolve_type_name_type): The type name should be the name of the
main type variant.
(append_type_to_template_for_access_check): New entry point.

gcc/testsuite/ChangeLog
2009-01-21  Dodji Seketeli  

PR c++/26693
* g++.dg/template/typedef11.C: New test.
* g++.dg/template/typedef12.C: Likewise.
* g++.dg/template/typedef13.C: Likewise.
* g++.dg/template/typedef14.C: Likewise.
* g++.dg/template/sfinae3.C: Compile this pedantically.
The only errors expected should be the one saying the typedef is ill
formed.
* g++.old-deja/g++.pt/typename8.C: Likewise.
* g++.dg/template/access11.C: Update this.

libstdc++-v3/ChangeLog:
2009-01-21  Dodji Seketeli  

* include/ext/bitmap_allocator.h: the typedefs should be made public
if we want them to be accessible. This has been revealed by the patch
that fixes PR c++/26693 in g++.


Added:
trunk/gcc/testsuite/g++.dg/template/typedef11.C
trunk/gcc/testsuite/g++.dg/template/typedef12.C
trunk/gcc/testsuite/g++.dg/template/typedef13.C
trunk/gcc/testsuite/g++.dg/template/typedef14.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/access11.C
trunk/gcc/testsuite/g++.dg/template/sfinae3.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/typename8.C
trunk/gcc/tree.h
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/bitmap_allocator.h


-- 


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

[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot

[rakdver at gcc dot gnu dot org]

--- Comment #6 from rakdver at gcc dot gnu dot org  2009-01-21 16:41 ---
(In reply to comment #4)
> Zdenek, could you please comment on comment #3?
> 

Adding MTP_AFTER_MOVE seems like the right thing to do; after all, even the
comments for may_trap_or_fault_p specify that it should behave the same way as
may_trap_after_code_motion_p (except for also looking for misaligned memory
references).

However, I suspect that all the places that use may_trap_after_code_motion_p in
fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well. 
So I would propose to merge may_trap_or_fault_p and
may_trap_after_code_motion_p to one function (and replace the checks for
MTP_UNALIGNED_MEMS in may_trap_p_1 by MTP_AFTER_MOVE, as they IMHO handle
different instances of the same problem -- the code that does not fail at its
current location, but may fail elsewhere).


-- 


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

[Bug c/38929] New: Optimisation with inline function causes invalid behaviour

[gcc at twistedsquare dot com]

I have a program with an addition function for int8_t that is intended to check
for overflow.  Regardless of whether the test works, I get different results
from the program if I compile it with -O1 vs compiling with -O2.  It appears
that GCC is performing optimisations it shouldn't across the process boundaries
that lead to the wrong behaviour.  In particular, GCC is effectively saying
that it has the value 128 in an int8_t.  This is not specifically a printf
problem, as the overflow is not set with -O1, and is set with -O2.  Running
with -O1, the program runs all the tests successfully.  With -O2, there is a
failure, where GCC says it is adding the int8_t values 0 and 128 during the
loop.  Compare that with the earlier lines where it correctly says it is trying
to add 0 and -128 in the standalone tests.  Here's the complete code of the
reduced test-case (the .i file is no different apart from the included headers,
and the includes are all standard C headers):

#include 
#include 
#include 
#include 
#include 

int g_overflow;

static inline int8_t add_int8_t (int8_t, int8_t, const char *);
static inline int8_t add_int8_t (int8_t a, int8_t b, const char *pos) {
printf("int8_t : adding %d and %d\n", (int)a, (int)b);
if (((b<1)&&(-128-b<=a)) || ((b>=1)&&(127-b>=a))) {
return a + b;
} else {
g_overflow = 1; return 0;
}
}

int main(int argc, char** argv)
{
g_overflow = 0;
const int8_t result = add_int8_t(-128,0,"");
printf("-128 + 0, result: %d, overflow: %d", (int)result, g_overflow);

g_overflow = 0;
const int8_t resultB = add_int8_t(0,-128,"");
printf("-128 + 0, result: %d, overflow: %d", (int)resultB, g_overflow);

// Test commutativity:
int done_x_once = 0;
for (int8_t x = 0; !(x == 0 && done_x_once == 1);x++) {
done_x_once = 1;
int done_y_once = 0;
for (int8_t y = 0; !(y == 0 && done_y_once == 1);y++) {
done_y_once = 1;

g_overflow = 0;
const int8_t r0 = add_int8_t(x,y,"");
const int overflow_earlier = g_overflow;

g_overflow = 0;
const int8_t r1 = add_int8_t(y,x,"");
const int overflow_later = g_overflow;

if ((overflow_later == 1 && overflow_earlier == 1) ||
  (overflow_earlier == 0 && overflow_later == 0 && r0
== r1)) {
//Passed
} else {
printf("Comm failed, non-commutative with %d,
%d (overflow: %d, %d) (res: %d, %d)\n",
  (int)x, (int)y, overflow_earlier,
overflow_later, r0, r1);
goto failed_comm;
}
}
}
failed_comm:;


return 0;
}


Here is my gcc -v output (I'm using the latest standard GCC on Ubuntu):

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)

Command-line to get correct behaviour (pasting the above code into gccbug.c)
is: gcc -std=gnu99 gccbug.c -O1
Command-line to trigger the bug is: gcc -std=gnu99 gccbug.c -O2

There is no compiler output, and adding -Wall still gives no compiler output.


-- 
   Summary: Optimisation with inline function causes invalid
behaviour
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at twistedsquare dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[gcc at twistedsquare dot com]

--- Comment #1 from gcc at twistedsquare dot com  2009-01-21 17:03 ---
I tried fiddling with various optimisations.  With -O1 the code works fine. 
With -O2 the code breaks.  With -O2 -fno-tree-vrp it works fine again, so that
may help in finding the bug.


-- 


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[gcc at twistedsquare dot com]

--- Comment #2 from gcc at twistedsquare dot com  2009-01-21 17:13 ---
The -fno-tree-vrp flag does stop the problem on the testcase I submitted. 
However, on the full program I drew the testcase from, it only modifies the
behaviour to a different invalid problem, so it is perhaps an interaction of
optimisations.


-- 


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[gcc at twistedsquare dot com]

--- Comment #3 from gcc at twistedsquare dot com  2009-01-21 17:36 ---
The main optimisation that seems to affect this example, is, -fstrict-overflow.
 So to reiterate:

Works: gcc gccbug.c -std=gnu99 -O1
Doesn't work: gcc gccbug.c -std=gnu99 -O2
Doesn't work: gcc gccbug.c -std=gnu99 -O2 -fno-strict-overflow
Works: gcc gccbug.c -O2 -std=gnu99 -O2 -fno-strict-overflow -fno-tree-vrp

I can see that the assumptions involved in strict-overflow may cause the
overflow test to behave differently, but it is still the case that under the
optimisations, one printf says -128 for the int8_t value, and the other (when
passed in the same value from a different call) says 128, and therefore I am
still confident that this is a bug.


-- 


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

[Bug libstdc++/38834] FAIL: abi_check on alpha

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2009-01-21 18:02 ---
Mine.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 18:02:29
   date||
   Target Milestone|--- |4.4.0


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

[Bug libstdc++/38834] FAIL: abi_check on alpha

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2009-01-21 18:02 ---
fixed.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/38930] New: [4.4 Regression] Revision 143546 failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

Revision 143546:

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00940.html

causes

In file included from ../../../../src-trunk/libjava/gij.cc:11:
../../../../src-trunk/libjava/include/jvm.h:260: internal compiler error: in
gen_typedef_die, at dwarf2out.c:14665
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [gij.lo] Error 1

Revision 143543 is OK. Gcc is configured with

--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld


-- 
   Summary: [4.4 Regression]  Revision 143546 failed to bootstrap on
Linux/ia64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-01-21 18:31 ---
It also happened on Linux/ia32.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2009-01-21 18:47 ---
Subject: Bug 38879

Author: uros
Date: Wed Jan 21 18:47:19 2009
New Revision: 143549

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143549
Log:
PR rtl-optimization/38879
* alias.c (base_alias_check): Unaligned access via AND address can
alias all surrounding object types except those with sizes equal
or wider than the size of unaligned access.


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


-- 


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

[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-01-21 18:50 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug rtl-optimization/38931] New: Seg fault when getting instruction latency on a *movsi_1 with an MMX target register

[nvachhar at google dot com]

Calling insn_default_latency on the following RTL causes the compiler to
segfault.

(insn 75 73 77 2 y.ii:19 (set (reg:SI 30 mm1)
(const_int 0 [0x0])) 41 {*movsi_1} (nil))

The root cause of the problem seems to be in i386.md.  Pasted below is a
snippet of the file describing the alternatives for the instruction:

(define_insn "*movsi_1"
  [(set (match_operand:SI 0 "nonimmediate_operand"
"=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
(match_operand:SI 1 "general_operand"
"g ,ri,C ,*y,*y ,rm ,C ,*x,*Yi,*x,r   ,m "))]

In this case, alternative 2 is selected (an MMX register destination and a
constant source).  Later in the .md file, we see that this causes the
instruction to have attribute "type" equal to "mmxadd"

  [(set (attr "type")
 (cond [(eq_attr "alternative" "2")
  (const_string "mmxadd")
(eq_attr "alternative" "3,4,5")
  (const_string "mmxmov")
(eq_attr "alternative" "6")
  (const_string "sselog1")
(eq_attr "alternative" "7,8,9,10,11")
  (const_string "ssemov")
(match_operand:DI 1 "pic_32bit_operand" "")
  (const_string "lea")
   ]
   (const_string "imov")))

Finally, from much earlier in i386.md, there is code to set the attribute
"memory".  Here is that code:

(define_attr "memory" "none,load,store,both,unknown"
  (cond [(eq_attr "type" "other,multi,str")
   (const_string "unknown")
 (eq_attr "type" "lea,fcmov,fpspc")
   (const_string "none")
 (eq_attr "type" "fistp,leave")
   (const_string "both")
 (eq_attr "type" "frndint")
   (const_string "load")
 (eq_attr "type" "push")
   (if_then_else (match_operand 1 "memory_operand" "")
 (const_string "both")
 (const_string "store"))
 (eq_attr "type" "pop")
   (if_then_else (match_operand 0 "memory_operand" "")
 (const_string "both")
 (const_string "load"))
 (eq_attr "type" "setcc")
   (if_then_else (match_operand 0 "memory_operand" "")
 (const_string "store")
 (const_string "none"))
 (eq_attr "type" "icmp,test,ssecmp,ssecomi,mmxcmp,fcmp")
   (if_then_else (ior (match_operand 0 "memory_operand" "")
  (match_operand 1 "memory_operand" ""))
 (const_string "load")
 (const_string "none"))
 (eq_attr "type" "ibr")
   (if_then_else (match_operand 0 "memory_operand" "")
 (const_string "load")
 (const_string "none"))
 (eq_attr "type" "call")
   (if_then_else (match_operand 0 "constant_call_address_operand" "")
 (const_string "none")
 (const_string "load"))
 (eq_attr "type" "callv")
   (if_then_else (match_operand 1 "constant_call_address_operand" "")
 (const_string "none")
 (const_string "load"))
 (and (eq_attr "type" "alu1,negnot,ishift1,sselog1")
  (match_operand 1 "memory_operand" ""))
   (const_string "both")
 (and (match_operand 0 "memory_operand" "")
  (match_operand 1 "memory_operand" ""))
   (const_string "both")
 (match_operand 0 "memory_operand" "")
   (const_string "store")
 (match_operand 1 "memory_operand" "")
   (const_string "load")
 (and (eq_attr "type"
 "!alu1,negnot,ishift1,
   imov,imovx,icmp,test,bitmanip,
   fmov,fcmp,fsgn,
   sse,ssemov,ssecmp,ssecomi,ssecvt,ssecvt1,sseicvt,sselog1,
   sseiadd1,mmx,mmxmov,mmxcmp,mmxcvt")
  (match_operand 2 "memory_operand" ""))
   (const_string "load")
 (and (eq_attr "type" "icmov,ssemuladd,sse4arg")
  (match_operand 3 "memory_operand" ""))
   (const_string "load")
]
(const_string "none")))

One will notice that none of the patterns match, however, when evaluating the
second to last pattern, it queries operand 2 which does not exist for this RTL
instruction.  This directly leads to the segfault.


-- 
   Summary: Seg fault when getting instruction latency on a *movsi_1
with an MMX target register
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
 GCC build triplet: i686-unknown-linux-gnu
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug rtl-optimization/38931] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register

[nvachhar at google dot com]

--- Comment #1 from nvachhar at google dot com  2009-01-21 19:02 ---
Created an attachment (id=17158)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17158&action=view)
Test case to trigger the segfault.

To generate the segfault, use the following command line:

g++ -mtune=generic -O2 -mfpmath=sse -msse2 y.ii


-- 


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

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[davek at gcc dot gnu dot org]

--- Comment #12 from davek at gcc dot gnu dot org  2009-01-21 19:20 ---
Subject: Bug 37660

Author: davek
Date: Wed Jan 21 19:20:08 2009
New Revision: 143552

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143552
Log:
PR bootstrap/37660
* config/i386/cygwin.h (SHARED_LIBGCC_SPEC):  New helper macro.
(LIBGCC_SPEC):  Don't define.
(REAL_LIBGCC_SPEC):  Define instead, using SHARED_LIBGCC_SPEC.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cygwin.h


-- 


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap on Linux/ia64

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 19:37:52
   date||


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-01-21 19:46 ---
It failed to bootstrap on Linux/ia32 and Linux/Intel64.
Linux/ia64 is OK.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.4 Regression]  Revision  |[4.4 Regression]  Revision
   |143546 failed to bootstrap  |143546 failed to bootstrap
   |on Linux/ia64   |


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-01-21 19:58 ---
It failed to bootstrap on i686-apple-darwin9 too.


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #40 from hjl dot tools at gmail dot com  2009-01-21 20:03 
---
*** Bug 38660 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||kurt at roeckx dot be


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

[Bug middle-end/38660] Pointer value changed to NULL

[hjl dot tools at gmail dot com]

--- Comment #16 from hjl dot tools at gmail dot com  2009-01-21 20:03 
---
I am closing it as dup of PR 38587, which will be fixed by

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01067.html

Please re-open it if the patch above doesn't fix this bug.

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/38587] [4.4 Regression] IRA doesn't preserve local variables after setjmp

[vmakarov at gcc dot gnu dot org]

--- Comment #41 from vmakarov at gcc dot gnu dot org  2009-01-21 20:18 
---
Subject: Bug 38587

Author: vmakarov
Date: Wed Jan 21 20:18:03 2009
New Revision: 143554

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143554
Log:
2009-01-21  Vladimir Makarov  

PR middle-end/38587
* ira-color.c (coalesce_spill_slots): Don't coalesce allocnos
crossing setjmps.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c


-- 


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2009-01-21 20:22 ---
(In reply to comment #1)
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html
> 

Richard,

I am not sure that any of the gfortran developers have the skills to deal with
this.  I read the words about canonical types and more or less understand them
but think that it would require more time than I have to implement what is
needed.

You have set the PR as P3/blocker - does that imply that you intend to attack
the problem or should we approach Jakub to do the business?

Cheers

Paul  


-- 


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-21 20:26 ---
You overflow x and y in main() which invokes undefined behavior.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-21 20:50 ---
I was able to work around the issue sofar, but more analysis is still required.
I will see if I can find some time for that.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug middle-end/38587] [4.4 Regression] IRA doesn't preserve local variables after setjmp

[rguenth at gcc dot gnu dot org]

--- Comment #42 from rguenth at gcc dot gnu dot org  2009-01-21 21:56 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38878] [4.4 Regression] gcc.dg/tree-ssa/foldaddr-1.c XFAILed

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P1


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

[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2009-01-21 22:00 ---
(In reply to comment #6)
> However, I suspect that all the places that use may_trap_after_code_motion_p 
> in
> fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well.

Me too.

> So I would propose to merge may_trap_or_fault_p and
> may_trap_after_code_motion_p to one function (and replace the checks for
> MTP_UNALIGNED_MEMS in may_trap_p_1 by MTP_AFTER_MOVE, as they IMHO handle
> different instances of the same problem -- the code that does not fail at its
> current location, but may fail elsewhere).

Yes: I'll prepare a patch to replace (change back) calls to
may_trap_after_code_motion_p with calls to may_trap_or_fault_p and fold
MTP_AFTER_MOVE into MTP_UNALIGNED_MEMS.
If the release managers deems that too invasive for 4.3 and 4.4, perhaps they
can still agree with the patch in commen #3.

Thanks for checking.


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/38794] [4.2/4.3 regression] Function body accepted in typedef

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-21 22:15 ---
Fixed for GCC 4.4, not worth fixing on the branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.2.4 4.3.2
  Known to work||4.4.0
 Resolution||FIXED
   Target Milestone|4.2.5   |4.4.0


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

[Bug target/38902] [4.3 Regression] __builtin_strcpy doesn't work with -fstack-protector

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 22:16:39
   date||


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

[Bug middle-end/38851] [4.3 regression] Compiler warns about uninitialized variable that is an object with a constructor

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2009-01-21 22:19 ---

Confirmed for s390x.

This is causing the following s390x libstdc++ testsuite failures, and is thus a
regression from 4.3. As far as I can tell these warnings are spurious. 

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02102.html

And from the libstdc++.log file:

FAIL: 27_io/ios_base/types/fmtflags/bitmask_operators.cc (test for excess
errors)


Excess errors:
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'a' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'b' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:413:
warning: 'b' is used uninitialized in this function


FAIL: 27_io/ios_base/types/iostate/bitmask_operators.cc (test for excess
errors)



/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'a' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'b' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:413:
warning: 'b' is used uninitialized in this function

FAIL: 27_io/ios_base/types/openmode/bitmask_operators.cc (test for excess
errors)


/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'a' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:401:
warning: 'b' is used uninitialized in this function
/build-extralong/BUILD/gcc/libstdc++-v3/testsuite/util/testsuite_common_types.h:413:
warning: 'b' is used uninitialized in this function


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 22:19:31
   date||
Summary|Compiler warns about|[4.3 regression] Compiler
   |uninitialized variable that |warns about uninitialized
   |is an object with a |variable that is an object
   |constructor |with a constructor


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

[Bug c++/38908] [4.3 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2009-01-21 22:24 ---

I see this as well. See 38851 for more spurious uninitialized warnings. 

This is a regression from 4.3, and IMHO is not minor.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org
   Severity|minor   |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-01-21 22:24:03
   date||
Summary|Unexplained "''  |[4.3 regression] Unexplained
   |is used uninitialized in|"'' is used
   |this function" warning in   |uninitialized in this
   |cc1plus -m64|function" warning in cc1plus
   ||-m64


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2009-01-21 22:25 ---
I think I have an idea of what's going on.

g++ is actually failing on the line:
typedef unsigned int uaddr __attribute__ ((mode (pointer)));
(in libjava/include/jvm.h:262, while compiling libjava/jni-libjvm.cc).

That's due to my changing grokfield (in decl2.c) to make it create typedef
variant variant types for typedef declarations. It appears that later down in
that function, the call to cplus_decl_attributes honours the mode (pointer)
attribute set specification. That attribute specification changes the TREE_TYPE
property of the typedef declaration, making it be an unsigned pointer.

Changing the TREE_TYPE like that invalidates an invariant condition of
typedefs, hence the ICE on the gcc_assert() in gen_typedef_die.


-- 


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-01-21 22:27 ---
Created an attachment (id=17159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view)
Fix candidate

I think this patch should fix the problem.

I am testing it right now. It'll take a little while as I need to re-bootstrap
everything on my box. If you have a fast box could you please test it and tell
me if it works for you ?


-- 


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-01-21 22:34 ---
A small testcase:

[...@gnu-6 pr38930]$ cat x.cc
class _Jv_Linker
{
private:
  typedef unsigned int uaddr __attribute__ ((mode (pointer)));

};
[...@gnu-6 pr38930]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -O2 -g x.cc -S -o x.s -m32
x.cc:3: internal compiler error: in gen_typedef_die, at dwarf2out.c:14665
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-6 pr38930]$ 


-- 


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-01-21 22:37 ---
(In reply to comment #5)
> Created an attachment (id=17159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
> 
> I think this patch should fix the problem.
> 
> I am testing it right now. It'll take a little while as I need to re-bootstrap
> everything on my box. If you have a fast box could you please test it and tell
> me if it works for you ?

I am doing it now.


-- 


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[dodji at redhat dot com]

--- Comment #8 from dodji at gcc dot gnu dot org  2009-01-21 22:37 ---
Subject: Re:  [4.4 Regression]  Revision 143546 failed to bootstrap

hjl dot tools at gmail dot com a écrit :
> --- Comment #6 from hjl dot tools at gmail dot com  2009-01-21 22:34 
> ---
> A small testcase:
> 
> [...@gnu-6 pr38930]$ cat x.cc
> class _Jv_Linker
> {
> private:
>   typedef unsigned int uaddr __attribute__ ((mode (pointer)));
> 
> };
> [...@gnu-6 pr38930]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -O2 -g x.cc -S -o x.s 
> -m32
> x.cc:3: internal compiler error: in gen_typedef_die, at dwarf2out.c:14665
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> [...@gnu-6 pr38930]$ 

Is that with my patchlet ?
> 


-- 


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2009-01-21 22:41 ---
fix summary


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 regression] Unexplained|[4.4 regression] Unexplained
   |"'' is used  |"'' is used
   |uninitialized in this   |uninitialized in this
   |function" warning in cc1plus|function" warning in cc1plus
   |-m64|-m64


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

[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2009-01-21 22:41 ---
fixed summary


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.2
Summary|[4.3 regression] Compiler   |[4.4 regression] Compiler
   |warns about uninitialized   |warns about uninitialized
   |variable that is an object  |variable that is an object
   |with a constructor  |with a constructor


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-01-21 22:43 ---
(In reply to comment #8)
> Subject: Re:  [4.4 Regression]  Revision 143546 failed to bootstrap
> 
> hjl dot tools at gmail dot com a écrit :
> > --- Comment #6 from hjl dot tools at gmail dot com  2009-01-21 22:34 
> > ---
> > A small testcase:
> > 
> > [...@gnu-6 pr38930]$ cat x.cc
> > class _Jv_Linker
> > {
> > private:
> >   typedef unsigned int uaddr __attribute__ ((mode (pointer)));
> > 
> > };
> > [...@gnu-6 pr38930]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
> > -B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -O2 -g x.cc -S -o x.s 
> > -m32
> > x.cc:3: internal compiler error: in gen_typedef_die, at dwarf2out.c:14665
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > [...@gnu-6 pr38930]$ 
> 
> Is that with my patchlet ?

No. Your patch in comment #5 fixes my small testcase.


-- 


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

[Bug c++/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-21 22:49 ---
I think it is the frontends business to omit the stores.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |c++
   Keywords||diagnostic, missed-
   ||optimization
   Priority|P3  |P2
   Target Milestone|--- |4.4.0


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-21 22:59 ---
(In reply to comment #5)
> I think it is the frontends business to omit the stores.

Or the gimplifier like what happens for GNU C code:
  /* For zero sized types only gimplify the left hand side and right hand
 side as statements and throw away the assignment.  Do this after
 gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable
 types properly.  */

The reason why it does not do it for C++ code is because the struct's size are
really 1 instead of 0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |middle-end


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2009-01-21 23:27 ---
Subject: Re:  Optimisation with inline function causes invalid
 behaviour

On Wed, 21 Jan 2009, rguenth at gcc dot gnu dot org wrote:

> You overflow x and y in main() which invokes undefined behavior.

Actually, I don't think this is undefined behavior; I think it's the same 
as bug 35634.  There is no arithmetic on int8_t in C; the values are 
promoted to int (defined), arithmetic is done on int (which doesn't 
overflow for the promoted values) and if the values are then stored back 
in int8_t they are converted back (where the implementation-defined 
conversions are documented, and it's implementation-defined not 
undefined).  But we know in bug 35634 that GCC is wrongly treating 
increment/decrement of types such as int8_t as having undefined behavior, 
by not representing the intermediate promotions and truncations.


-- 


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-21 23:28 ---
Reopening to ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/38929] Optimisation with inline function causes invalid behaviour

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-21 23:30 ---
Yes it is a dup, replacing ++ with +=1 allows this to work correctly.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/35634] [4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted

[pinskia at gcc dot gnu dot org]

--- Comment #18 from pinskia at gcc dot gnu dot org  2009-01-21 23:30 
---
*** Bug 38929 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc at twistedsquare dot com


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

[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
  Known to fail||4.4.0
  Known to work||4.3.3
Summary|Seg fault when getting  |[4.4 Regression] Seg fault
   |instruction latency on a|when getting instruction
   |*movsi_1 with an MMX target |latency on a *movsi_1 with
   |register|an MMX target register
   Target Milestone|--- |4.4.0


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2009-01-22 00:01 
---
(In reply to comment #5)
> Created an attachment (id=17159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
> 
> I think this patch should fix the problem.
> 
> I am testing it right now. It'll take a little while as I need to re-bootstrap
> everything on my box. If you have a fast box could you please test it and tell
> me if it works for you ?
> 

It passed bootstrap. But compared against revision 143543, revision 143556
+ your fix has following regressions on Linux/x86-64:


FAIL: 21_strings/basic_string/requirements/explicit_instantiation/debug.cc
(test for excess errors)
FAIL: 23_containers/deque/14340.cc (test for excess errors)
FAIL: 23_containers/deque/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/deque/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/deque/invalidation/3.cc (test for excess errors)
FAIL: 23_containers/deque/invalidation/4.cc (test for excess errors)
FAIL: 23_containers/list/14340.cc (test for excess errors)
FAIL: 23_containers/list/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/list/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/list/invalidation/3.cc (test for excess errors)
FAIL: 23_containers/list/invalidation/4.cc (test for excess errors)
FAIL: 23_containers/list/operations/35969.cc (test for excess errors)
FAIL: 23_containers/map/14340.cc (test for excess errors)
FAIL: 23_containers/map/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/map/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/map/modifiers/insert/16813.cc (test for excess errors)
FAIL: 23_containers/multimap/14340.cc (test for excess errors)
FAIL: 23_containers/multimap/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/multimap/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/multiset/14340.cc (test for excess errors)
FAIL: 23_containers/multiset/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/multiset/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/set/14340.cc (test for excess errors)
FAIL: 23_containers/set/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/set/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/unordered_map/requirements/debug_container.cc (test for
excess errors)
FAIL: 23_containers/unordered_multimap/requirements/debug.cc (test for excess
errors)
FAIL: 23_containers/unordered_multiset/requirements/debug.cc (test for excess
errors)
FAIL: 23_containers/unordered_set/requirements/debug_container.cc (test for
excess errors)
FAIL: 23_containers/vector/14340.cc (test for excess errors)
FAIL: 23_containers/vector/debug_mode_requires_reallocation-1.cc (test for
excess errors)
FAIL: 23_containers/vector/debug_mode_requires_reallocation-2.cc (test for
excess errors)
FAIL: 23_containers/vector/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/vector/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/vector/invalidation/3.cc (test for excess errors)
FAIL: 23_containers/vector/invalidation/4.cc (test for excess errors)
FAIL: 25_algorithms/set_difference/35541.cc (test for excess errors)
FAIL: 25_algorithms/set_intersection/34730.cc (test for excess errors)
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/list_update_data_map_rand.cc (test for excess
errors)
FAIL: ext/pb_ds/regression/list_update_no_data_map_rand.cc (test for excess
errors)
FAIL: ext/pb_ds/regression/priority_queue_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/tree_data_map_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/trie_data_map_rand.cc (test for excess errors)
FAIL: ext/pb_ds/regression/trie_no_data_map_rand.cc (test for excess errors)
FAIL: ext/slist/check_construct_destroy.cc (test for excess errors)
FAIL: ext/slist/requirements/explicit_instantiation.cc (test for excess errors)
FAIL: tr1/4_metaprogramming/is_member_function_pointer/value.cc execution test
FAIL: tr1/4_metaprogramming/is_member_object_pointer/value.cc execution test


-- 


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

[Bug libmudflap/32276] [4.3/4.4 Regression]: libmudflap.c++/pass41-frag.cxx

[sje at cup dot hp dot com]

--- Comment #10 from sje at cup dot hp dot com  2009-01-22 00:08 ---
Pointer to http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00371.html where Martin
Jambor says he has looked at this bug and says he thinks it is a libmudflap bug
and not actually related to the patch that caused it to start showing up.  He
mentions that -heur-proc-map MUDFLAP option makes it go away.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-22 01:30 ---
Confirmed, more reduced testcase:
typedef int __m64 __attribute__ ((__vector_size__ (8)));
__inline __m64 _m_pshufw (){}
typedef unsigned char uint8;
void dummy (
const int input_bpl,
const unsigned char * input
, unsigned char * output
, unsigned long x1) {
  uint8 *pix_end_ptr = output + x1*4;
  __m64 m_original ;
  __m64 m_base_addr = __builtin_ia32_vec_init_v2si (0, input_bpl);
  __m64 m_addr =  __builtin_ia32_paddd (m_original, m_base_addr);
  __m64 *a0 = ( __m64 *)(input);
  for (; output < pix_end_ptr; output += 4)
  {
a0 = (__m64 *)(input  + __builtin_ia32_vec_ext_v2si (m_addr, 0));
m_addr = _m_pshufw();
__builtin_prefetch (a0, 0);
  }
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-unknown-linux-gnu  |
   GCC host triplet|i686-unknown-linux-gnu  |
 GCC target triplet|i686-unknown-linux-gnu  |i?86-*-*
   Last reconfirmed|-00-00 00:00:00 |2009-01-22 01:30:40
   date||


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

[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
   Keywords||ice-on-valid-code


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

[Bug c++/38928] infinite loop on error message in C++ only

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-22 01:41 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i486-linux-gnu  |
   GCC host triplet|i486-linux-gnu  |
 GCC target triplet|i486-linux-gnu  |
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2009-01-22 01:41:08
   date||


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

[Bug c++/38928] infinite loop on error message in C++ only

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-22 01:41 ---
3.3 ICEd on the testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.0.0 4.3.0 4.4.0


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

[Bug target/38924] gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in "gcc/config/sol2.h"

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-22 01:47 ---
With that dropped in gcc seems to build and test correctly. It _might_ be 
that gcc builds Faster and uses Less memory during the two peaks in libjava
after this patch, more testing required.

Rob


-- 


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

[Bug middle-end/28734] gather stats vs PCH

[rob1weld at aol dot com]

--- Comment #9 from rob1weld at aol dot com  2009-01-22 01:51 ---
Confirmed, trunk, i386-pc-solaris2.11 - the gcc.log is:

/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/pch/common-1.c:3: internal
compiler error: in ggc_record_overhead, at ggc-common.c:873

/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/pch/counter-1.c:7: internal
compiler error: in ggc_record_overhead, at ggc-common.c:873


More info:
Results for 4.4.0 20090121 (experimental) [trunk revision 143538] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html

Rob


-- 


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

[Bug bootstrap/38890] Trunk [revision 143454] broken - stage1 libgcc "No rule to make target `all'"

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-22 02:24 ---
One we get to gcc version 4.4.0 20090121 (experimental) [trunk revision 143538] 
this no longer occurs. Closing FIXED.

Rob


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/38439] I/O PD edit descriptor inconsistency

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-01-22 03:05 
---
Further information:  PD is not the problem here at all.  The problem is that
when using the D edit descriptor, one is not allowed to also specify the
exponent digits.

Thus:  '(1pD24.15)'  is valid

While: '(1pD24.15e4)'  is invalid


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-22 03:05:22
   date||


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

[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-22 03:51 ---
The problem here is that you are using unitialized local register variables so
the register allocator does not know any better.  Anyways it works correctly on
the trunk and I don't have any other compiler to test with really (this is both
with and without IRA).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |inline-asm


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

[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-01-22 04:01 ---
Also I think this is the same as bug 35160.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[regehr at cs dot utah dot edu]

--- Comment #25 from regehr at cs dot utah dot edu  2009-01-22 05:06 ---
I get this using r143561 on Ubuntu Hardy on x86:

reg...@john-home:~/volatile/tmp126$ current-gcc -O3 -c small.c 
small.c: In function ‘bar’:
small.c:22: internal compiler error: in set_value_range, at tree-vrp.c:398
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

reg...@john-home:~/volatile/tmp126$ cat small.c

long long int foo (long long int si1, int si2)
{
  return 0 && 9223372036854775807LL - si2 || si1 < 0 && si2 < 0
&& si1 < -9223372036854775807LL - 1 - si2 ? : si1;
}

int g_11;
volatile int g_49;

int func_10 (void)
{
  for (g_11 = 1; 1;)
return 1;
}

int func_25 (void)
{
  int l_28 = 8L;
  return l_28;
}

void bar (int p_9)
{
  int l_146 = 4L;
  func_10 ();
  if (foo
  (p_9,
   ((signed char) (1 - (unsigned int) func_25 () | g_11) / l_146)))
g_49;
}


-- 


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

[Bug c++/38930] [4.4 Regression] typedef with attribute mode causes ICE in dwarf2

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-01-22 05:56 
---
(In reply to comment #5)
> Created an attachment (id=17159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
> 
> I think this patch should fix the problem.
> 
> I am testing it right now. It'll take a little while as I need to re-bootstrap
> everything on my box. If you have a fast box could you please test it and tell
> me if it works for you ?
> 

I also tried revision 143546 + this patch. There are many C++
regressions on Linux/x86-64:

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02208.html

Should we revert revision 143546 now and reapply the updated
patch when it is ready?


-- 


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

[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-01-22 06:03 ---
One fix is to add a proper intrinsic for vmrun.


-- 


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

[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2009-01-22 07:15 ---
Subject: Bug 26693

Author: dodji
Date: Thu Jan 22 07:15:41 2009
New Revision: 143562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143562
Log:
Reverted commit 143546 related to PR c++/26693


Removed:
trunk/gcc/testsuite/g++.dg/template/typedef11.C
trunk/gcc/testsuite/g++.dg/template/typedef12.C
trunk/gcc/testsuite/g++.dg/template/typedef13.C
trunk/gcc/testsuite/g++.dg/template/typedef14.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/access11.C
trunk/gcc/testsuite/g++.dg/template/sfinae3.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/typename8.C
trunk/gcc/tree.h
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/bitmap_allocator.h


-- 


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