[Bug rtl-optimization/30688] Branch registers loaded too late on ia64

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-03-10 06:48 ---
The load to the general register should also be moved by bt-load, then.

The bt-load pass is "designed" for SH only, in its current state, but I think
extending it to move a small group of insns instead of just one shouldn't be
very difficult.

Alternatively it could be done in ia64 machine-reorg, just before
scheduling/bundling.


-- 


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

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2009-03-10 06:32 ---
ISTR Richi has scripts to automatically identify file+function that is
miscompiled...?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-03-10 04:27 ---
(In reply to comment #3)
> (In reply to comment #1)

MIRO: Mudflap Improved with Referent Objects - Works on OpenSolaris also.
http://gcc.gnu.org/wiki/MIRO

Results for gcc version 4.4.0 20080520 (experimental) [miro revision 144368]
(GCC) testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02215.html

Rob


-- 


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

[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-03-10 04:22 ---
(In reply to comment #3)
> Dismal Testsuite results are here:
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
> Rob

Great results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html


-- 


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

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[hjl dot tools at gmail dot com]

--- Comment #13 from hjl dot tools at gmail dot com  2009-03-10 03:52 
---
(In reply to comment #12)
> Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
> loc_descriptor_from_tree_1
> 
> > --- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 
> > ---
> 
> > It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
> > .o files from stage1 and relink stage2 cc1plus to find out which files
> > are miscompiled by stage1 cc1. You may be to extract a small testcase to
> > show miscompilation.
> 
> The ICE doesn't occur if I replace parser.o.
> 

Can you find out which function is miscompiled?


-- 


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

[Bug c/39401] Reproducible internal compiler error for FFmpeg/h264.c; multiple platforms

[contact at multimedia dot cx]

--- Comment #3 from contact at multimedia dot cx  2009-03-10 03:01 ---
Confirmed fixed with revision 144720. Thanks.


-- 

contact at multimedia dot cx changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2009-03-10 
01:47 ---
Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1

> --- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 
> ---

> It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
> .o files from stage1 and relink stage2 cc1plus to find out which files
> are miscompiled by stage1 cc1. You may be to extract a small testcase to
> show miscompilation.

The ICE doesn't occur if I replace parser.o.

Dave


-- 


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

[Bug c/39403] Excessive optimization issue

[casmyu at gmail dot com]

--- Comment #3 from casmyu at gmail dot com  2009-03-10 01:23 ---
Hi:
I have changed the code as you said, but it is more error now.

  1 #include 
  2
  3 int main()
  4 {
  5 char src[30] = {"This is a test message.\n"};
  6 char dst[30];
  7 int len = 25;
  8
  9 __asm__ __volatile__(
 10 "cld\n\t"
 11 "rep movsb"
 12 :
 13 //  : "(src), "D"(dst), "c"(len)
 14 : "+c"(len), "+D"(dst), "+S"(src)
 15 );
 16 printf("%s\t%d\n", dst, len);
 17 return 0;
 18 }

[root][~]# gcc -O2 -o bugtest bugtest.c
bugtest.c: In function ¡®main¡¯:
bugtest.c:15: error: input operand constraint contains ¡®+¡¯
bugtest.c:15: error: input operand constraint contains ¡®+¡¯
bugtest.c:15: error: input operand constraint contains ¡®+¡¯
bugtest.c:9: error: input operand constraint contains ¡®+¡¯
bugtest.c:9: error: input operand constraint contains ¡®+¡¯
bugtest.c:9: error: input operand constraint contains ¡®+¡¯

Please help to re-check this issue.
Thank you!

(In reply to comment #2)
> Subject: Re:  Excessive optimization issue
> 
> 
> 
> Sent from my iPhone
> 
> On Mar 9, 2009, at 8:36 AM, "rguenth at gcc dot gnu dot org"
>   > wrote:
> 
> >
> >
> > --- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-09  
> > 15:36 ---
> > You need to specify that the registers are clobbered by the asm.   
> > The only
> > way to do that is to use output constraints ("+D", "+c", etc.) on  
> > proper
> > temporaries.
> >
> >  int lent = len;
> >  char *dstt = dst;
> >  char *srct = src;
> >  __asm__ __volatile__(
> >   "cld\n\t"
> >   "rep movsb"
> >   : "+c" (lent), "+D"(dstt), "+S"(src)
> >  );
> > Otherwise GCC thinks the registers still hold the original value.
> 
> Oh and mark this inline-ask as clobbering memory.
> 
> >
> >
> >
> > -- 
> >
> > 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=39403
> >
> 


-- 

casmyu at gmail dot com changed:

   What|Removed |Added

 CC||casmyu at gmail dot com
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/39417] Incorrect values computed with -ftree-copy-prop

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-03-09 23:22 ---
This works on the trunk.


-- 


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

[Bug c++/39417] Incorrect values computed with -ftree-copy-prop

[maksverver at geocities dot com]

--- Comment #3 from maksverver at geocities dot com  2009-03-09 23:21 
---
Created an attachment (id=17433)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17433&action=view)
The broken tree code


-- 


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

[Bug c++/39417] Incorrect values computed with -ftree-copy-prop

[maksverver at geocities dot com]

--- Comment #2 from maksverver at geocities dot com  2009-03-09 23:21 
---
Created an attachment (id=17432)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17432&action=view)
The working tree code


-- 


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

[Bug c++/39417] Incorrect values computed with -ftree-copy-prop

[maksverver at geocities dot com]

--- Comment #1 from maksverver at geocities dot com  2009-03-09 23:19 
---
Created an attachment (id=17431)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17431&action=view)
The test case that fails


-- 


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

[Bug c++/39417] New: Incorrect values computed with -ftree-copy-prop

[maksverver at geocities dot com]

Attached is a small program that computes some values and puts them in a
std::vector. The values are stored in the `init' variable, but when
optimizations are enabled, the data actually added to the vector is garbage.

I've done a little testing and the problem exists when compiling with -O and
-O2, but when compiling with -O0 or -O -fno-tree-copy-prop the bug disappears.
(This is also the case when compiling with -fmudflap.)

To reproduce the bug, take the attached test.cpp and do:
  $ g++ -O -o broken test.cpp
  $ ./broken
  broken: test.cpp:55: int main(): Assertion `res[0] == 5' failed.
  Aborted

For comparison, you can run:
  $ g++ -O -fno-tree-copy-prop -o working test.cpp
  $ ./working

And see that it works fine. Running the broken binary trough valgrind gives a
"conditional jump or move depends on uninitialised value" message.

I'll attach (part of) the output of compiling with -fdump-tree-optimized. The
code is similar in both versions, but I think the problem is here:

:
  init_lsm.129 = l / i - i / 2;
  if (init_lsm.129 >= 0)
goto ;
  else
goto ;

:
  init = init_lsm.129;
  init = init_lsm.130;

As you can see, the correct value in `init_lsm.129' is assigned to `init' only
to be overwritten by the uninitialized data in `init_lsm.130'. The working
version looks similar but seems to have the last two statements reversed, so
that the correct value ends up in `init'.

I'm using gcc version 4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5), but the problem
was first seen on a system runing GCC 4.1.x (or lower); not my own system so I
can't check exactly, but it probably doesn't matter. Since the bug seems to be
in the C++ front-end, it occurs when producing 64-bit as well as 32-bit
binaries.

Hopefully, you are able to figure out what goes wrong. If this is a genuine
bug, it seems to affect a wide range of compiler versions. Let me know if you
need any more information, and I'll be happy to help.


-- 
   Summary: Incorrect values computed with -ftree-copy-prop
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maksverver at geocities dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug fortran/39414] PROCEDURE statement double declaration bug

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-03-09 22:00 ---
> procedure() :: p
> integer :: p

I think it is valid; ifort 11beta also accepts it. (NAG 5.1 doesn't.)

Looking at "12.3.2.3 Procedure declaration statement" one sees that
"PROCEDURE()" is has the same effect as the EXTERNAL statement. And together
with the following, I think it makes it valid: "If proc-interface does not
appear, the procedure declaration statement does not specify whether the
declared procedures or procedure pointers are subroutines or functions."


-- 


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

[Bug libstdc++/39416] std::map::operator[] inserts a new item in RHS context

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-03-09 21:28 ---
It is hard for the library to know if we are doing an insert or doing an
extract as there is only one type of operator[] really.


-- 


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

[Bug libstdc++/39416] std::map::operator[] inserts a new item in RHS context

[glyn at adgie dot f9 dot co dot uk]

--- Comment #2 from glyn at adgie dot f9 dot co dot uk  2009-03-09 21:25 
---
Thanks Paolo, I suspected that this was not a bug in libstdc++, but
standard-compliant behaviour.

It just seems so unexpected, when compared to other languages that have maps,
e.g. tables in Lua. It is also unexpected when compared to other STL
containers, e.g. std::vector. A bug in the standard, perhaps? I would have
thought that if other languages can implement the expected behaviour for
reading from an associative array, so should C++. Perhaps there is something in
the implementation of std::map that makes this impossible or inefficient, but I
must say, I cannot see why.


-- 


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

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-09 21:12 ---
Yeah, before r128631 (PR debug/33316) it ICEd in modified_type_die, after it in
gen_tagged_type_instantiation_die.


-- 


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

[Bug libstdc++/39416] std::map::operator[] inserts a new item in RHS context

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-03-09 20:53 
---
There is nothing wrong here, the bahavior is fully specified in the Standard,
23.3.1.2 as:

Returns:  (*((insert(make_pair(x, T(.first)).second.

Note, our inline documentation comments are also very clear about this.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-03-09 20:52 ---
This is introduced by revision 117493:

http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00239.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hainque at adacore dot com


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

[Bug libstdc++/39416] New: std::map::operator[] inserts a new item in RHS context

[glyn at adgie dot f9 dot co dot uk]

#include 
#include 
#include 

// Demonstrate unexpected behaviour of std::map::operator[] when used in a read
// context, e.g. on the right hand side of an assignment.
//
// The intended application is a shell environment table, where accessing a
// non-existent variable should yield an empty string, but not alter the table.
// In my shell, I sometimes wish to distinguish between an existing variable
// with an empty value, and a non-existent variable. The behaviour of
// std::map::operator[] defeats this, so I have to use the more verbose
// std::map::find interface for reading from the map.

int main(int argc, char * argv[])
{
typedef std::map env_type;

env_type env;
env["my_var"] = "Hello world!"; // Add an item.

std::cout << env["thing"] << std::endl; // Empty string, as expected.

// List all variables and their values.
for(env_type::const_iterator it = env.begin(); it != env.end(); ++it)
{
std::cout << it->first << '=' << it->second << std::endl;
}

// Oh no! The non-existent variable 'thing' has been added to the map.
//
// my_var=Hello world!
// thing=

return 0;
}


-- 
   Summary: std::map::operator[] inserts a new item in RHS context
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: glyn at adgie dot f9 dot co dot uk


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

[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

[jmichae3 at yahoo dot com]

--- Comment #10 from jmichae3 at yahoo dot com  2009-03-09 20:12 ---
I didn't read that in the documentation.


-- 


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

[Bug c++/39415] New: static_cast used as downcast can silently lose const

[algrant at acm dot org]

This is silently accepted:

  struct T { };
  struct T_impl: public T { };
  T_impl *g(T *tp) { return static_cast(tp); }

The result type of the static_cast is pointer-to-const and should not
convert to a pointer-to-non-const.  This seems to be specific to when
it is used as a downcast.  Replacing the last line with

  T *g(T *tp) { return static_cast(tp); }

is faulted as expected.


-- 
   Summary: static_cast used as downcast can silently lose const
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org


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

[Bug c++/39371] [4.2/4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-03-09 19:35 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|2.95.4  |2.95.4 4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression]
   |Incorrectly rejects |Incorrectly rejects
   |switch((unsigned|switch((unsigned
   |int)boolvar)|int)boolvar)


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

[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-03-09 19:34 ---
Subject: Bug 39371

Author: jakub
Date: Mon Mar  9 19:34:10 2009
New Revision: 144732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144732
Log:
PR c++/39371
* semantics.c (finish_switch_cond): Don't call get_unwidened.
* decl.c (finish_case_label): Pass SWITCH_STMT_TYPE as 3rd argument
instead of TREE_TYPE (cond).

* g++.dg/opt/switch2.C: Add -w to dg-options.
* g++.dg/warn/Wswitch-1.C: Adjust expected warnings.
* g++.dg/warn/switch1.C: New test.
* g++.dg/other/switch3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/switch3.C
trunk/gcc/testsuite/g++.dg/warn/switch1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/switch2.C
trunk/gcc/testsuite/g++.dg/warn/Wswitch-1.C


-- 


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

[Bug c++/39413] static_assert and SFINAE

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug fortran/39414] New: PROCEDURE statement double declaration bug

[janus at gcc dot gnu dot org]

The following code is invalid, but currently accepted by gfortran:

procedure(iabs) :: p
integer :: p
end

It is also accepted when the two statements are reversed in order.
It's not completely obvious to me whether this variant is invalid, too:

procedure() :: p
integer :: p

It is rejected by g95, but one could argue that it is valid in the same way as:

external :: p
integer :: p


-- 
   Summary: PROCEDURE statement double declaration bug
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug c++/39413] static_assert and SFINAE

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-03-09 18:17 
---
Volunteers for a better Summary?


-- 


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

[Bug c++/10200] Weird clash with same names in different scopes

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2009-03-09 18:16 
---
*** Bug 39407 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/39407] Parse error in when user declares template-name c

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2009-03-09 18:16 
---


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


-- 

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=39407

[Bug c++/39407] Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

--- Comment #14 from jwakely dot gcc at gmail dot com  2009-03-09 18:13 
---
aha, on PR 11814 you mention PR 20308 which is the same.

Thanks, Andrew!


-- 


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

[Bug c++/39413] static_assert and SFINAE

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-03-09 18:10 
---
The below, not using any header neither C++0x mode (very likely can be further
reduced), doesn't compile with mainline and 4_3-branch, does with EDG-based
compilers in strict mode:

template
  class __static_assert { };

template<>
  class __static_assert;

template
  struct __are_same { static const bool value = false; };

template
  struct __are_same { static const bool value = true; };

class A {

};

class B : public A {

};

class C {

};

namespace gc {

template  class member_ptr;
}

template  class weak_ptr {

public:

weak_ptr() {}

template  weak_ptr(const weak_ptr& v) {}

weak_ptr(const gc::member_ptr& v);

template  weak_ptr& operator=(const weak_ptr& v) {
return *this; }
};

namespace gc {

template  class member_ptr {

  __static_assert<__are_same::value> sa;
   };
}

int main() {

weak_ptr ap1;
weak_ptr bp1;

ap1 = bp1;
}


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-09 18:10:02
   date||


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

[Bug c++/39413] static_assert and SFINAE

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-03-09 17:48 
---
let's try to simplify the issue as much as possible... are defaulted / deleted
functions really necessary to trigger the bug? Thus, is c++0x mode really
necessary?


-- 


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

[Bug debug/39412] [4.4 Regression] ICE in gen_tagged_type_instantiation_die

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3 4.4.0
  Known to work||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2009-03-09 17:47:29
   date||


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

[Bug c++/39407] Parse error in when user declares template-name c

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2009-03-09 17:42 
---
This is related to PR 11814 or is the same bug.  I thought there was an exact
duplicate of this parsing issue but I cannot find it.


-- 


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

[Bug c++/39413] New: static_assert and SFINAE

[piotr dot wyderski at gmail dot com]

G++ fails when compiling the following program in
g++0x mode. It displays "spooky action at a distance"
when instantiating the member_ptr template, but I
expect the converting assignment operator from weak_ptr
to be selected instead.

-8<---


#include 

class A {

};

class B : public A {

};

class C {

};


namespace gc {

template  class member_ptr;
}


template  class weak_ptr {

public:

weak_ptr() {}

template  weak_ptr(const weak_ptr& v) {}

weak_ptr(const weak_ptr&) = default;

weak_ptr(const gc::member_ptr& v);

~weak_ptr() = default;

// --

weak_ptr& operator =(const weak_ptr&) = default;

template  weak_ptr& operator =(const weak_ptr& v) {
return *this; }
};

namespace gc {

template  class member_ptr {

static_assert(std::is_base_of::value,
  "spooky action at a distance");
};
}



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

weak_ptr ap1;
weak_ptr bp1;

ap1 = bp1;

return 0;
}


-8<---


-- 
   Summary: static_assert and SFINAE
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-4.4.0 (20090309), Cygwin, Windows XP


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

[Bug debug/39412] [4.4 Regression] ICE in gen_tagged_type_instantiation_die

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug debug/39412] New: [4.4 Regression] ICE in gen_tagged_type_instantiation_die

[jakub at gcc dot gnu dot org]

struct S { int i; };

void
bar (const void *x, unsigned long y)
{
  const union { struct S a[y / sizeof (struct S)]; } *u = x;
}

void
foo (const void *x, unsigned long y)
{
  bar (x, y);
}

ICEs at -O[23s] -g with
internal compiler error: in gen_tagged_type_instantiation_die, at
dwarf2out.c:14850


-- 
   Summary: [4.4 Regression] ICE in
gen_tagged_type_instantiation_die
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug c++/39407] Parse error in when user declares template-name c

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2009-03-09 16:24 
---
Seriously, thanks Jonathan for the reduced C++ snippet. Really, this way of
seeing the issue makes much more sense to me.


-- 


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

[Bug c++/39407] Parse error in when user declares template-name c

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-03-09 16:19 
---
Better... ;)


-- 


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

[Bug c++/39407] Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

--- Comment #10 from jwakely dot gcc at gmail dot com  2009-03-09 16:08 
---
reduced:

template  struct x;
template  struct y { int x; };

template
bool operator<(const y& l, const y& r) { return l.x < r.x; }


It doesn't happen except in a template context, so it seems that l.x< is parsed
differently depending on whether it's inside a template or not. This is OK:

template  struct x;
struct z { int x; };
bool operator<(const z& l, const z& r) { return l.x < r.x; }


-- 


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

[Bug ada/39411] New: GNAT BUG DETECTED: implementation of protected interface by protected type

[andriy at irbisnet dot com]

Hi Team,

I have 'GNAT BUG DETECTED' error message when I try to compile my project. I am
providing the more simple example of source code which will help to reproduce
the problem.

Please, advise

+===GNAT BUG DETECTED==+
| 4.3.2 (i386-portbld-freebsd7.0) Assert_Failure sinfo.adb:1079|
| Error detected at sample.ads:29:5|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+


The gcc -v output:

Using built-in specs.
Target: i386-portbld-freebsd7.0
Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada
--disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local
--program-suffix=43 --bindir=/usr/local/bin/gcc43
--libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd7.0
Thread model: posix
gcc version 4.3.2 (GCC)


The compilation command:

$ gnatmake -p -P sample.gpr

The source/project files:

 sample.ads -
-- --
--  Author: Andriy Bakay  --
-- --
--  Indent: 4  --
--  Tabs:   no --
-- --
--  Copyright (c) Andriy Bakay. 2009   --
--  All rights reserved.   --
-- --
-

package Sample is

type Return_Code is mod 2 ** 32;

type Interface_Type is protected interface;

procedure Write(
Inst: in out Interface_Type;
RC  :out Return_Code;
D   : in Integer ) is abstract;

function Read(
Inst: in Interface_Type;
D   : not null access Integer )
return   Return_Code is abstract;

protected type Instance is new Interface_Type with

overriding
procedure Write(
RC  :out Return_Code;
D   : in Integer );

overriding
function Read(
D   : not null access Integer )
returnReturn_Code;

private

Data: Integer   := 0;

end Instance;

end Sample;

 sample.ads -
 sample.adb -
-- --
--  Author: Andriy Bakay  --
-- --
--  Indent: 4  --
--  Tabs:   no --
-- --
--  Copyright (c) Andriy Bakay. 2009   --
--  All rights reserved.   --
-- --
-

package body Sample is

protected body Instance is

procedure Write(

RC  :out Return_Code;
D   : in Integer )

is

begin
RC  := 0;

Data:= D;
end Write;

function Read(

D   : not null access Integer )
returnReturn_Code

is

begin
D.all   := Data;
return 0;
end Read;

end Instance;

end Sample;

 sample.adb -
 common.gpr -
-- --
--  Author: Andriy Bakay  --
--

[Bug c++/39407] Parse error in when user declares template-name c

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2009-03-09 15:59 ---
Subject: Re:  Parse error in  when user declares template-name  c



Sent from my iPhone

On Mar 9, 2009, at 8:40 AM, "rguenth at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #7 from rguenth at gcc dot gnu dot org  2009-03-09  
> 15:40 ---
> I think this is more likely a C++ frontend issue.  At least I cannot  
> believe
> this behavior is mandated by the std ;)
>
> Jason?

There is a dup of this bug somewhere also.


>
>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> CC||jason at redhat dot  
> com
>  Component|libstdc++   |c++
>   Keywords||rejects-valid
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
>


-- 


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

Re: [Bug c++/39407] Parse error in when user declares template-name c

[Andrew Thomas Pinski]

Sent from my iPhone

On Mar 9, 2009, at 8:40 AM, "rguenth at gcc dot gnu dot org" > wrote:





--- Comment #7 from rguenth at gcc dot gnu dot org  2009-03-09  
15:40 ---
I think this is more likely a C++ frontend issue.  At least I cannot  
believe

this behavior is mandated by the std ;)

Jason?


There is a dup of this bug somewhere also.






--

rguenth at gcc dot gnu dot org changed:

  What|Removed |Added
--- 
--- 
--
CC||jason at redhat dot  
com

 Component|libstdc++   |c++
  Keywords||rejects-valid


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

[Bug c++/39407] Parse error in when user declares template-name c

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-03-09 15:58 ---
Icc 11 has no problems.


-- 


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

[Bug c/39403] Excessive optimization issue

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-03-09 15:57 ---
Subject: Re:  Excessive optimization issue



Sent from my iPhone

On Mar 9, 2009, at 8:36 AM, "rguenth at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-09  
> 15:36 ---
> You need to specify that the registers are clobbered by the asm.   
> The only
> way to do that is to use output constraints ("+D", "+c", etc.) on  
> proper
> temporaries.
>
>  int lent = len;
>  char *dstt = dst;
>  char *srct = src;
>  __asm__ __volatile__(
>   "cld\n\t"
>   "rep movsb"
>   : "+c" (lent), "+D"(dstt), "+S"(src)
>  );
> Otherwise GCC thinks the registers still hold the original value.

Oh and mark this inline-ask as clobbering memory.

>
>
>
> -- 
>
> 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=39403
>


-- 


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

Re: [Bug c/39403] Excessive optimization issue

[Andrew Thomas Pinski]

Sent from my iPhone

On Mar 9, 2009, at 8:36 AM, "rguenth at gcc dot gnu dot org" > wrote:





--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-09  
15:36 ---
You need to specify that the registers are clobbered by the asm.   
The only
way to do that is to use output constraints ("+D", "+c", etc.) on  
proper

temporaries.

 int lent = len;
 char *dstt = dst;
 char *srct = src;
 __asm__ __volatile__(
  "cld\n\t"
  "rep movsb"
  : "+c" (lent), "+D"(dstt), "+S"(src)
 );
Otherwise GCC thinks the registers still hold the original value.


Oh and mark this inline-ask as clobbering memory.





--

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=39403

[Bug c++/39407] Parse error in when user declares template-name c

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-03-09 15:40 ---
I think this is more likely a C++ frontend issue.  At least I cannot believe
this behavior is mandated by the std ;)

Jason?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at redhat dot com
  Component|libstdc++   |c++
   Keywords||rejects-valid


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

[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-03-09 15:37 ---
This flag isn't supposed to be used with libstdc++.


-- 

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=39404

[Bug c/39403] Excessive optimization issue

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-09 15:36 ---
You need to specify that the registers are clobbered by the asm.  The only
way to do that is to use output constraints ("+D", "+c", etc.) on proper
temporaries.

  int lent = len;
  char *dstt = dst;
  char *srct = src;
  __asm__ __volatile__(
   "cld\n\t"
   "rep movsb"
   : "+c" (lent), "+D"(dstt), "+S"(src)
  );

Otherwise GCC thinks the registers still hold the original value.


-- 

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=39403

[Bug libstdc++/39407] Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

--- Comment #6 from jwakely dot gcc at gmail dot com  2009-03-09 15:20 
---
(In reply to comment #5)
> Well, the as-if rule allows (x.c < ((y.c)) too of course.

bah - it would allow it if I could type the right number of closing
parentheses!


-- 


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

[Bug libstdc++/39407] Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-03-09 15:19 
---
Well, the as-if rule allows (x.c < ((y.c)) too of course.

I could be wrong and the compiler should parse it ok, I haven't thought about
it very hard.

The same problem occurs here, although it's only in a GNU extension this time:

template  struct value { };
#include 


-- 


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

[Bug libstdc++/39407] Parse error in when user declares template-name c

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-03-09 15:08 
---
Before considering touching the library, I want evidence that at least another
widespread implementation has that operator< somehow different than the obvious
way. Besides, the issue affects  too, of course, and in that case the
Standard is even explicit about implementing exactly as x.c < y.c.


-- 


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

[Bug driver/39356] assembler isn't called

[r dot emrich at de dot tecosim dot com]

--- Comment #5 from r dot emrich at de dot tecosim dot com  2009-03-09 
15:07 ---
(In reply to comment #4)
> Sorry, pex_run & co aren't the reason for this issue. By further debugging I
> found that for bigger functions using alloca with variable sizes wrong code is
> generated for optimizations bigger then -O0.
> By this reason the driver gcc.c in execute is broken. The interesting issue
> about this is, when trying to make a smaller testcase out of it, code is
> produced correct.
> 

I can confirm this. Building the compiler with CFLAGS="-O0" results in a
working driver.


-- 


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

[Bug c++/39409] internal compiler error: Segmentation fault

[amit at mobiletornado dot com]

--- Comment #1 from amit at mobiletornado dot com  2009-03-09 14:38 ---
Created an attachment (id=17430)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17430&action=view)
the preprocessed file (gzipped)


-- 


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

[Bug c++/39409] New: internal compiler error: Segmentation fault

[amit at mobiletornado dot com]

$ uname -a
system type: AIX aix52a 1 6 000921F2D700

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix6.1.0.0
--target=powerpc-ibm-aix6.1.0.0 --build=powerpc-ibm-aix6.1.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0

gcc command:
g++ -g -fstack-check -DAIX  -fPIC -D_REENTRANT -DTUNICODE -g -fstack-check
-DAIX -D_PTHREADS -fcheck-new -D__STL_ASSERTIONS -D__STDC_LIMIT_MACROS -c -o
updatethread.o updatethread.cpp

error:
updatethread.cpp: At global scope:
updatethread.cpp:2777: internal compiler error: Segmentation fault


-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amit at mobiletornado dot com


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

[Bug libstdc++/39407] Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

--- Comment #3 from jwakely dot gcc at gmail dot com  2009-03-09 14:25 
---
(In reply to comment #2)
> FWIW, if I use v3 together with the Intel C++ compiler, it builds...
> 

That's interesting, Comeau's online compiler gives a very similar error to gcc
4.3.2


-- 


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

[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-03-09 14:03 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/39407] Parse error in when user declares template-name c

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-03-09 14:02 
---
FWIW, if I use v3 together with the Intel C++ compiler, it builds...


-- 


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

[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-03-09 14:01 ---
Subject: Bug 39394

Author: jakub
Date: Mon Mar  9 14:01:29 2009
New Revision: 144727

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144727
Log:
PR tree-optimization/39394
* gimplify.c (gimplify_type_sizes): Gimplify DECL_SIZE and
DECL_SIZE_UNIT of variable length FIELD_DECLs.

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

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


-- 


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

[Bug libstdc++/39407] Parse error in when user declares template-name c

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-03-09 14:00 
---
disgusting ;)


-- 


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

[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

[matz at gcc dot gnu dot org]

--- Comment #6 from matz at gcc dot gnu dot org  2009-03-09 13:25 ---
It's also PRE that produces such patterns, so moving predcom behind
vectorization alone won't help this problem.


-- 


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

[Bug c/39406] ice in tree-dfa.c for legal code with -O2

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-09 13:16 ---
This is likely dup of PR39360, please retry with a newer snapshot.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/39407] New: Parse error in when user declares template-name c

[jwakely dot gcc at gmail dot com]

It was just brought to my attention that this fails to compile:

template  void c();
#include 


In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
 from mark.cc:2:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:
In function ‘bool std::operator<(const std::stack<_Tp, _Seq>&, const
std::stack<_Tp, _Seq>&)’:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: `.' cannot appear in a constant-expression
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: parse error in template argument list

The problem is here:

  template
inline bool
operator<(const stack<_Tp, _Seq>& __x, const stack<_Tp, _Seq>& __y)
{ return __x.c < __y.c; }

The presence of the template ::c means that "c <" is parsed as the start of a
template-id, which then fails.

I *think* the compiler is doing the right thing here, but that doesn't help
users who've declared a template 'c'.  libstdc++ could make it a non-issue by
using parentheses to prevent __x.c being parsed as a template-id:

{ return (__x.c) < __y.c; }

I've only tested it with 4.3.2 but it apparently fails with 3.2 - 4.3.3, and I
assume with 4.4 too.


-- 
   Summary: Parse error in  when user declares template-name
c
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com


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

[Bug c/39406] ice in tree-dfa.c for legal code with -O2

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-03-09 11:53 ---
Created an attachment (id=17429)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17429&action=view)
C source code


-- 


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

[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-03-09 11:52 ---
Created an attachment (id=17428)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17428&action=view)
gcc44-pr39394.patch

Patch I'm going to bootstrap/regtest.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/39406] New: ice in tree-dfa.c for legal code with -O2

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package sparse sparse-0.4.1.git1-1.56
with the GNU C compiler version 4.4 snapshot 20090306
and the compiler said

sparse.c: In function 'check_context':
sparse.c:546: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:563
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O2 required.


-- 
   Summary: ice in tree-dfa.c for legal code with -O2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

[davidgkinniburgh at yahoo dot co dot uk]

--- Comment #8 from davidgkinniburgh at yahoo dot co dot uk  2009-03-09 
11:34 ---
Thanks Jerry.

PS

CHARACTER(80) :: str

no longer required in test case.


-- 


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

[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

[davidgkinniburgh at yahoo dot co dot uk]

--- Comment #7 from davidgkinniburgh at yahoo dot co dot uk  2009-03-09 
11:33 ---
Thanks Jerry.

PS

CHARACTER(80) :: str

no longer needed in test case. 


-- 


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

[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-03-09 11:28 ---
Oops, sorry.  I guess the problem is that this VL type isn't gimplified.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |tree-optimization
   GCC host triplet|pentium2-slackware-linux-gnu|
 GCC target triplet|pentium2-slackware-linux-gnu|
  Known to fail||4.4.0
  Known to work||4.3.3
Summary|gcc 4.4.0 20090306 segfaults|[4.4 regression] ICE in
   |at argp-help.c in glibc 2.7 |copy_tree_body_r
   |and 2.9 |


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

[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-03-09 11:09 ---
Confirmed.  Simplified testcase:
extern inline void *
asmfn (void *dest, const void *src, unsigned long n)
{
  asm volatile (""
: "=m" (*(struct { char x[n]; } *) dest)
: "r" (n), "r" (dest), "r" (src),
  "m" (*(struct { char x[n]; } *) src)
: "cc");
  return dest;
}


extern inline void
baz (char *dest, const char *str, unsigned long len)
{
   if (__builtin_constant_p (len))
 asmfn (dest, str, len + 1);
   else
 asmfn (dest, str, len);
}

extern inline void
bar (char *dest, const char *str)
{
  baz (dest, str, __builtin_strlen (str));
}

void
foo (char *dest, const char *str)
{
  bar (dest, str);
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |c
   Keywords|ice-on-valid-code   |
  Known to fail|4.4.0   |
  Known to work|4.3.1   |
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2009-03-09 11:09:57
   date||
Summary|[4.4 regression] ICE in |gcc 4.4.0 20090306 segfaults
   |copy_tree_body_r|at argp-help.c in glibc 2.7
   ||and 2.9
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r

[falk at debian dot org]

--- Comment #5 from falk at debian dot org  2009-03-09 10:59 ---
Here's a test case:

void *p;
extern inline void *f1(int n) {
asm volatile("" : "=m"(*(struct { char x[n]; }*) p));
}

int x;
extern inline void f2() {
x ? f1(1) : f1(2);
}

inline void f3() { f2(); }
void f4() { f3(); }

With trunk #144708, I'm getting:

min.c: In function 'f4':
min.c:12: internal compiler error: in copy_tree_body_r, at tree-inline.c:1042
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

falk at debian dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.4.0
  Known to work||4.3.1
Summary|gcc 4.4.0 20090306 segfaults|[4.4 regression] ICE in
   |at argp-help.c in glibc 2.7 |copy_tree_body_r
   |and 2.9 |


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

[Bug c++/39405] New: std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

[gcc at cohi dot at]

Can't see why this shouldn't work with std::shared_ptr; changing the type of
m_foo to std::shared_ptr, i.e. leaving out the redundant template
argument, changes nothing; only when making foo a class instead of a class
template, and removing all template arguments, does it compile.

co...@weasel:/tmp> g++-mp-4.3 -v
Using built-in specs.
Target: i386-apple-darwin9.6.0
Configured with: ../gcc-4.3.3/configure --prefix=/opt/local
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc43 --includedir=/opt/local/include/gcc43
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.3 --with-gxx-include-dir=/opt/local/include/gcc43/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.3.3 (GCC) 
co...@weasel:/tmp> cat t.cc
#include 

template< typename T >
struct foo
{
   std::shared_ptr< foo< T > > m_foo;
};

int main()
{
   std::shared_ptr< foo< int > > t;
   return sizeof( t );
}
co...@weasel:/tmp> make t
g++-mp-4.3 -O3 -Wall -Wextra -Woverloaded-virtual -std=gnu++0x -m32
-fno-enforce-eh-specs -I/opt/local/includet.cc   -o t
t.cc: In instantiation of 'foo':
/opt/local/include/gcc43/c++/tr1_impl/type_traits:291:   instantiated from
'std::is_abstract >'
/opt/local/include/gcc43/c++/tr1_impl/type_traits:206:   instantiated from
'std::is_function >'
/opt/local/include/gcc43/c++/type_traits:127:   instantiated from
'std::add_lvalue_reference >'
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:463:   instantiated
from 'std::__shared_ptr, _S_mutex>'
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:822:   instantiated
from 'std::shared_ptr >'
t.cc:11:   instantiated from here
t.cc:6: error: 'foo::m_foo' has incomplete type
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:822: error:
declaration of 'class std::shared_ptr >'
make: *** [t] Error 1
co...@weasel:/tmp> cat b.cc
#include 

template< typename T >
struct foo
{
   boost::shared_ptr< foo< T > > m_foo;
};

int main()
{
   boost::shared_ptr< foo< int > > t;
   return sizeof( t );
}
co...@weasel:/tmp> make b
g++-mp-4.3 -O3 -Wall -Wextra -Woverloaded-virtual -std=gnu++0x -m32
-fno-enforce-eh-specs -I/opt/local/includeb.cc   -o b
co...@weasel:/tmp>


-- 
   Summary: std::shared_ptr barfs on incomplete template class that
boost::shared_ptr accepts
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at cohi dot at
  GCC host triplet: i386-apple-darwin9.6.0


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

[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-03-09 10:31 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00463.html


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg00463.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-05 10:35:56 |2009-03-09 10:31:06
   date||


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

[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9

[cneil at yahoo dot com]

--- Comment #4 from cneil at yahoo dot com  2009-03-09 10:14 ---
OK, maybe I should slept before I submitted this.

1.  The glibc-2.9 snapshot is from 20081201.  I am not capable of time travel.

2.  I successfully compiled this same glibc-2.9 snapshot with the gcc-4.4
snapshot from 20090220.  Hopefully this helps.


-- 


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

[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9

[cneil at yahoo dot com]

--- Comment #3 from cneil at yahoo dot com  2009-03-09 10:00 ---
Created an attachment (id=17427)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17427&action=view)
preprocessed argp-help.c

If any additional information is needed, I'll do my best to provide it.


-- 


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

[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9

[cneil at yahoo dot com]

--- Comment #2 from cneil at yahoo dot com  2009-03-09 09:58 ---
I think I'm hitting the same bug as the reporter.

i686-pc-linux-gnu-gcc argp-help.c -c -std=gnu99 -fgnu89-inline -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -ggdb
-march=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2  -g0 -O99
-fomit-frame-pointer -D__USE_STRING_INLINES -fexceptions
-mpreferred-stack-boundary=4 -fexceptions   -I../include
-I/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp
-I/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl
-I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686
-I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386
-I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv
-I../ports/sysdeps/unix/sysv-I../sysdeps/unix/sysv -I../sysdeps/unix/i386
-I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686
-I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486
-I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports  -I..
-I../libio -I. -nostdinc -isystem
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include -isystem
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include-fixed -isystem
/usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h  
-U_FORTIFY_SOURCE -U_FORTIFY_SOURCE -o
/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o
-MD -MP -MF
/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o.dt
-MT
/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o
argp-help.c: In function ‘print_header’:
argp-help.c:1024: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This is from a gentoo ebuild, but no patches are being applied.  I'm using the
gcc-4.4 snapshot from 20090306, and argp-help.c is from a glibc-2.9 snapshot
from 20091201.

I used -save-temps to get a preprocessed file (I'll attach momentarily) and did
a little trial-and-error experimenting.  Here's what I found:

gcc -c argp-help.i -o argp-help.o -O0 : succeeds
gcc -c argp-help.i -o argp-help.o -O1 : fails
gcc -c argp-help.i -o argp-help.o -O1 -fno-inline : succeeds

This is on an i686 (athlon-xp) machine, but I get the same failure on my x86_64
(amdfam10) machine.

Here's my output from gcc -v (on the athlon-xp machine):
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090306/work/gcc-4.4-20090306/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20090306
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/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 --enable-libgomp
--enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20090306' --without-ppl --without-cloog --disable-ppl-version-check
--disable-cloog-version-check
Thread model: posix
gcc version 4.4.0-alpha20090306  (experimental) (Gentoo 4.4.0_alpha20090306)


-- 


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

[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-09 08:22 ---
This isn't related to just bool, e.g.:
void
foo (unsigned char b)
{
  switch ((unsigned int) b)
{
case 1:
case 257:
  break;
}
}
also results in
pr39371-2.C:7: warning: large integer implicitly truncated to unsigned type
pr39371-2.C:7: error: duplicate case value
pr39371-2.C:6: error: previously used here

In C both testcases are fine.


-- 


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

[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

[dannysmith at users dot sourceforge dot net]

--- Comment #8 from dannysmith at users dot sourceforge dot net  2009-03-09 
07:52 ---
>From gcc.info:

*Warning:* the `-fpack-struct' switch causes GCC to generate code
 that is not binary compatible with code generated without that
 switch.  Additionally, it makes the code suboptimal.  Use it to
 conform to a non-default application binary interface.


-- 


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

[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination

[dannysmith at users dot sourceforge dot net]

--- Comment #13 from dannysmith at users dot sourceforge dot net  
2009-03-09 07:46 ---
(In reply to comment #12)
> Was this broken in 4.3 compilers?  Is it a 4.4 regression?
> 
This is not a new bug in the compiler (the same multiple definition will occur
with 3.4.5)  , but an old 'feature' of the the PE-COFF linker

_InterlockedIncrement is defined as an ordinary  C library function  in
lib64_libmingwex_a-wininterlocked.o

In thread.cpp, it is defined and emitted using linkonce semantics (it is put
into its own .text$_InterlockedIncrement link_once sections, which is how
PE-COFF implements vague linkage.

The linker grabs the one and only .text$_InterlockedIncrement section in
thread.o and then while resolving another symbol it needs from
lib64_libmingwex_a-wininterlocked.o finds an ordinary (not .linkonce)
definition InterlockedIncrement

Hence the multiple definition.


-- 


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