[Bug other/70426] New: decl_expr contains too little information

2016-03-27 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70426

Bug ID: 70426
   Summary: decl_expr contains too little information
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com
  Target Milestone: ---

using gcc (Debian 4.9.2-10) 4.9.2
In the 001t.tu file, the decl_expr contains no real information. 

here is the context of relevant statements :

@9529   function_declname: @9547type: @5191scpe: @155
 srcp: eval.c:199  chain: @9548
 link: static   body: @9549

@9549   bind_exprtype: @129 vars: @9568body: @9569

@9569   statement_list   0   : @95871   : @95882   : @9589
 3   : @95904   : @95915   : @9592
 6   : @9593
@9585   identifier_node  strg: pwd  lngt: 3
@9568   var_decl name: @9585type: @144 scpe: @9529
 srcp: eval.c:201  chain: @9586
 size: @22  algn: 64   used: 1

@9587   decl_exprtype: @129
@9588   decl_exprtype: @129
@9589   modify_expr  type: @144 op 0: @9586op 1: @9615

@129void_typename: @126 algn: 8
@126type_declname: @128 type: @129 chain: @130
@128identifier_node  strg: void lngt: 4



The source code around 199 is :
  198 static void
  199 send_pwd_to_eterm ()
  200 {
  201   char *pwd, *f;
  202 
  203   f = 0;
  204   pwd = get_string_value ("PWD");
  205   if (pwd == 0)
  206 f = pwd = get_working_directory ("eterm");
  207   fprintf (stderr, "\032/%s\n", pwd);
  208   free (f);
  209 }

So can I infer that @9587 refers to line 201 for the pwd variable?

See https://archive.org/details/bash.compilation for a full snapshot of the
compile. build/eval.c.001t.tu is the file.


So please tell me if this is correct or are we missing important fields in the
decl_expr.

[Bug other/70425] New: decl_expr contains too little information

2016-03-27 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70425

Bug ID: 70425
   Summary: decl_expr contains too little information
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com
  Target Milestone: ---

using gcc (Debian 4.9.2-10) 4.9.2
In the 001t.tu file, the decl_expr contains no real information. 

here is the context of relevant statements :

@9529   function_declname: @9547type: @5191scpe: @155
 srcp: eval.c:199  chain: @9548
 link: static   body: @9549

@9549   bind_exprtype: @129 vars: @9568body: @9569

@9569   statement_list   0   : @95871   : @95882   : @9589
 3   : @95904   : @95915   : @9592
 6   : @9593
@9585   identifier_node  strg: pwd  lngt: 3
@9568   var_decl name: @9585type: @144 scpe: @9529
 srcp: eval.c:201  chain: @9586
 size: @22  algn: 64   used: 1

@9587   decl_exprtype: @129
@9588   decl_exprtype: @129
@9589   modify_expr  type: @144 op 0: @9586op 1: @9615

@129void_typename: @126 algn: 8
@126type_declname: @128 type: @129 chain: @130
@128identifier_node  strg: void lngt: 4



The source code around 199 is :
  198 static void
  199 send_pwd_to_eterm ()
  200 {
  201   char *pwd, *f;
  202 
  203   f = 0;
  204   pwd = get_string_value ("PWD");
  205   if (pwd == 0)
  206 f = pwd = get_working_directory ("eterm");
  207   fprintf (stderr, "\032/%s\n", pwd);
  208   free (f);
  209 }

So can I infer that @9587 refers to line 201 for the pwd variable?

See https://archive.org/details/bash.compilation for a full snapshot of the
compile. build/eval.c.001t.tu is the file.


So please tell me if this is correct or are we missing important fields in the
decl_expr.

[Bug c++/67155] New: Linking of complex constexpr static class member failing across files

2015-08-07 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67155

Bug ID: 67155
   Summary: Linking of complex constexpr static class member
failing across files
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com
  Target Milestone: ---

Created attachment 36148
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36148action=edit
test case

I encountered a strange behavior when creating a class that wraps a constexpr
string.

It seems that the static constant string field wrapped in a class is only
accessible in the same header file and not available in a separate compilation
unit. 

The workaround is to move the usage of the static fields into the header.

If you prefer git you can find the test case here as well :
https://github.com/h4ck3rm1k3/gcc-plugin-cpp-template/tree/constexpr/testcase


[Bug c++/67155] Linking of complex constexpr static class member failing across files

2015-08-07 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67155

--- Comment #1 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
The compiler output :

g++ -std=gnu++11 test.cpp test.hpp
/tmp/cceBFmJM.o: In function `S::S()':
test.cpp:(.text+0x35): undefined reference to `S::u'
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'test' failed
make: *** [test] Error 1


[Bug c++/67155] Linking of complex constexpr static class member failing across files

2015-08-07 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67155

--- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
adding this seems to solve the linker error:

constexpr CU S::u;


[Bug c++/67155] Linking of complex constexpr static class member failing across files

2015-08-07 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67155

James Michael DuPont JamesMikeDuPont at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
got feedback on so
http://stackoverflow.com/questions/31889247/c-static-constexpr-class-member-with-complex-class-linking-issues/31889510#31889510


[Bug c++/66506] New: Crash on compiling llvm plugin

2015-06-11 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66506

Bug ID: 66506
   Summary: Crash on compiling llvm plugin
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com
  Target Milestone: ---

When developing/compiling a llvm clang 3.7 plugin with gcc 4.9 on debian
unstable I encounted a crash. I thought to report this because maybe it would
be useful.

My internal bug report is here:
https://github.com/h4ck3rm1k3/traces/issues/2

Here is the backtrace:

In file included from /usr/lib/llvm-3.7/include/clang/AST/Attr.h:150:0,
from /usr/lib/llvm-3.7/include/clang/AST/DeclCXX.h:20,
from /usr/lib/llvm-3.7/include/clang/AST/DeclVisitor.h:17,
from trace_instrumentor.cpp:26:
/usr/lib/llvm-3.7/include/clang/AST/Attrs.inc:4263:7: internal compiler error:
Segmentation fault
class ObjCExceptionAttr : public InheritableAttr {
^


[Bug c++/66507] Crash on compiling llvm plugin

2015-06-11 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66507

James Michael DuPont JamesMikeDuPont at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
Not reproducable. Will close for now. I have seen this sporadic compiler crash
before.


[Bug c++/66507] New: Crash on compiling llvm plugin

2015-06-11 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66507

Bug ID: 66507
   Summary: Crash on compiling llvm plugin
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com
  Target Milestone: ---

When developing/compiling a llvm clang 3.7 plugin with gcc 4.9 on debian
unstable I encounted a crash. I thought to report this because maybe it would
be useful.

this error did not recoccur when trying to compiling again. 

My internal bug report is here:
https://github.com/h4ck3rm1k3/traces/issues/2

Here is the backtrace:

/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. 
-I ../include  -I/usr/lib/llvm-3.7/include  -DNDEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2
-fomit-frame-pointer -fPIC -std=c++11   -g -O2 -MT trace_instrumentor.lo -MD
-MP -MF .deps/trace_instrumentor.Tpo -c -o trace_instrumentor.lo
trace_instrumentor.cpp

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I ../include
-I/usr/lib/llvm-3.7/include -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2 -fomit-frame-pointer -fPIC
-std=c++11 -g -O2 -MT trace_instrumentor.lo -MD -MP -MF
.deps/trace_instrumentor.Tpo -c trace_instrumentor.cpp  -fPIC -DPIC -o
.libs/trace_instrumentor.o

In file included from /usr/lib/llvm-3.7/include/clang/AST/Attr.h:150:0,
from /usr/lib/llvm-3.7/include/clang/AST/DeclCXX.h:20,
from /usr/lib/llvm-3.7/include/clang/AST/DeclVisitor.h:17,
from trace_instrumentor.cpp:26:
/usr/lib/llvm-3.7/include/clang/AST/Attrs.inc:4263:7: internal compiler error:
Segmentation fault
class ObjCExceptionAttr : public InheritableAttr {
^


[Bug c++/65638] New: Crash on invalid input

2015-03-31 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638

Bug ID: 65638
   Summary: Crash on invalid input
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com

using the invalid input file:
```
void crash (bool
```

found using permutation testing based on the 
https://h4ck3rm1k3.wordpress.com/2015/03/31/test-random-permutations-of-files-and-lines-for-gccgo-golang-go-compiler-bug-reporting/

Arch:
Linux gcc2-power8.osuosl.org 3.17.4-301.fc21.ppc64le #1 SMP Mon Dec 1 07:51:01
UTC 2014 ppc64le ppc64le ppc64le GNU/Linux

crashes on :
gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)
and
gcc (GCC) 5.0.0 20150331 (experimental)
but not on :

Linux 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) x86_64 GNU/Linux
with g++-4.9 (Debian 4.9.2-10) 4.9.2


```
test.cc:1:14: error: expected ‘,’ or ‘...’ at end of input
 void crash ( bool
  ^
test.cc:1:14: error: expected ‘)’ at end of input
test.cc:1:14: error: expected initializer at end of input
```

[Bug c++/65638] Crash on invalid input

2015-03-31 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638

--- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
No options at all.
On the gcc compile farm : gcc112.fsffrance.org


[h4ck3rm1k3@gcc2-power8 ~]$ which g++
/usr/bin/g++
[h4ck3rm1k3@gcc2-power8 ~]$ g++ test1.cc
test1.cc:1:1: internal compiler error: Segmentation fault
 void crash ( bool
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.


[Bug c++/65638] Crash on invalid input

2015-03-31 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638

--- Comment #3 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
This test case can be reduced to just a file with the word bool in it.

```
bool
```


[Bug go/65272] switch on type of interface failing

2015-03-15 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272

--- Comment #3 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
(In reply to James Michael DuPont from comment #2)
 also on github https://github.com/golang/go/issues/10047

this was closed on github because it is valid go.


[Bug go/65272] switch on type of interface failing

2015-03-15 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272

--- Comment #5 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
@iant thanks for the update. my bad, I got confused.

here is the commit.
https://github.com/gcc-mirror/gcc/commit/cc0446bae7c8c0ccead885787ad3fc4db0c127e0


[Bug go/65272] switch on type of interface failing

2015-03-01 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272

--- Comment #1 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
output is :

test.go:6:8: error: expected type


[Bug go/65272] New: switch on type of interface failing

2015-03-01 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272

Bug ID: 65272
   Summary: switch on type of interface failing
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: JamesMikeDuPont at googlemail dot com
CC: cmang at google dot com

package test;

func clr(q interface{}) {
switch x := q.(type) {
case *x:
return
}

occurs in : https://github.com/cznic/ql/blob/master/btree.go


[Bug go/65272] switch on type of interface failing

2015-03-01 Thread JamesMikeDuPont at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272

--- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
also on github https://github.com/golang/go/issues/10047


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-10 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #10 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
I have reported the problem in the code to boost, they have fixed it.
https://svn.boost.org/trac/boost/ticket/8651#comment:1

The problem is having to do with underspecifed namespace selection. They
changed the code to remove the crash.

mike


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-05 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
Here is a small change to work around the crash :

namespace boost {

namespace detail { namespace variant {
struct variant_hasher: public //boost::
static_visitorstd::size_t {
template class T
std::size_t operator()(T const val) const {
  //using namespace boost;
hashT hasher;
return hasher(val);
}
};
}}
}

It is the uneeded namespace usage that causes the problem.


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-05 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #4 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
Created attachment 30259
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30259action=edit
test case

this is the minimal test case that I have.
by applying the small namespace changes to the end it will go away.


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-05 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #5 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
Sorry, It seems that the original attachment was not applied, I have bzip2ed it
so now it fits.
thanks
mike


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-05 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #6 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
I have filed a small cosmetic bug in boost about this change to the namespace
usage :
https://svn.boost.org/trac/boost/ticket/8651


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-05 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #8 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
Tested like this:
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -std=gnu++11 -fdump-translation-unit
testvariant_min.ii


[Bug c++/57524] New: internal compiler error on dump translation unit

2013-06-04 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

Bug ID: 57524
   Summary: internal compiler error on dump translation unit
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JamesMikeDuPont at googlemail dot com

using the debian sid standard : GNU C++ (Debian 4.7.2-5) version 4.7.2
(x86_64-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR
version 3.1.0-p10, MPC version 0.9 warning: MPFR header version 3.1.0-p10
differs from library version 3.1.1-p2. GGC heuristics: --param
ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiling boost spirit.qi code,
Here is the one that creates the error.

Invocation is :
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -std=gnu++11 -fdump-translation-unit
treedumpparse.ii

the output is:

(this is the last of the function print )
 std::size_t boost::detail::variant::variant_hasher::operator()(const T) const

the error is :
In file included from /usr/include/boost/variant/variant.hpp:35:0,
 from /usr/include/boost/spirit/home/support/info.hpp:14,
 from /usr/include/boost/spirit/home/qi/domain.hpp:16,
 from /usr/include/boost/spirit/home/qi/meta_compiler.hpp:15,
 from /usr/include/boost/spirit/home/qi/action/action.hpp:14,
 from /usr/include/boost/spirit/home/qi/action.hpp:14,
 from /usr/include/boost/spirit/home/qi.hpp:14,
 from /usr/include/boost/spirit/include/qi.hpp:16,
 from treedumpparse.cpp:6:
/usr/include/boost/variant/detail/hash_variant.hpp:32:33: internal compiler
error: in timevar_start, at timevar.c:344
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.

This can be reproduced with this one include :
#include /usr/include/boost/variant/detail/hash_variant.hpp


I am trying to reduce the problem, but it is difficult.


[Bug c++/57524] internal compiler error on dump translation unit

2013-06-04 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524

--- Comment #1 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com ---
I tried to reduce the input size but it is not producing any results.

namespace std {
  typedef long unsigned int size_t;
};
namespace boost { 
  namespace detail {
struct is_static_visitor_tag { };
typedef void static_visitor_default_return;
  } 
  template typename R = ::boost::detail::static_visitor_default_return
  class static_visitor: public detail::is_static_visitor_tag {
  public:
typedef R result_type;
  protected:
static_visitor() { }~static_visitor() { }
  };}
namespace boost
{
  template class T struct hash;
  template class T void hash_combine(std::size_t seed, T const v);
  template class It std::size_t hash_range(It, It);
  template class It void hash_range(std::size_t, It, It);
}
namespace boost {
  namespace detail { namespace variant {
  struct variant_hasher: public boost::static_visitorstd::size_t {
template class T
std::size_t operator()(T const val) const {
  using namespace boost;
  hashT hasher;
  return hasher(val);
}  };}  }}


[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists

2011-05-16 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853

--- Comment #5 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com 2011-05-16 19:17:06 UTC ---
Ok,
I will have to look into it,
thanks,
mike

On Mon, May 16, 2011 at 1:19 PM, redi at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853

 Jonathan Wakely redi at gcc dot gnu.org changed:

           What    |Removed                     |Added
 
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.05.16 11:00:14
     Ever Confirmed|0                           |1

 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16 
 11:00:14 UTC ---
 please try to reproduce this with a current FSF release or report it to Ubuntu

 for C++0x bugs please try 4.5 or later, lots of initializer list bugs have 
 been
 fixed already

 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.



[Bug c++/45938] New: tree tag for CLASSTYPE_TEMPLATE_SPECIALIZATION spec is confusing.

2010-10-08 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45938

   Summary: tree tag for CLASSTYPE_TEMPLATE_SPECIALIZATION spec
is confusing.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamesmikedup...@googlemail.com


In the file : gcc/cp/dump.c
there is a dump of the CLASSTYPE_TEMPLATE_SPECIALIZATION,

   if (CLASSTYPE_TEMPLATE_SPECIALIZATION(t))
dump_string(di, spec);

This is confusing, because spec already has a different meaning, it is used to
denote other values, spec : NAME. 

It would be better to rename this output to dump_string(di, tmpl_spclz); for
example so that the tag spec is consistent.

thanks,
mike


[Bug c++/45853] New: Segfault while experimenting with c++-0x initializer lists

2010-10-01 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853

   Summary: Segfault while experimenting with c++-0x initializer
lists
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamesmikedup...@googlemail.com


Created attachment 21928
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21928
Compile Log

I have been experimenting with c++ initializer lists and refactoring binutils
to use c++. While doing so, the compiler crashed. I am reporting this in case
it might help the development of the compiler.

Compiler is :
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1

lsb version : 9.10 karmic with lots of backports and patches


[Bug c++/45855] New: switched ; and : causes compile crash

2010-10-01 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45855

   Summary: switched ; and : causes compile crash
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamesmikedup...@googlemail.com


Created attachment 21931
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21931
Preprocessed .ii file

g++  -save-temps -std=c++0x  -I. -I../../include  ../../opcodes/i386-dis.h
../../opcodes/i386-dis.h:1706: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

Line is:
const dis386 test2(addB, {Eb, Gb}):


[Bug c++/45855] switched ; and : causes compile crash

2010-10-01 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45855

--- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com 2010-10-01 08:11:48 UTC ---
The bug also occurs with ;. it seems to be a different problem.


[Bug c++/45855] switched ; and : causes compile crash

2010-10-01 Thread JamesMikeDuPont at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45855

--- Comment #4 from James Michael DuPont JamesMikeDuPont at googlemail dot 
com 2010-10-01 08:34:13 UTC ---
In the newest git head version, I get a better error report :
g++ (GCC) 4.6.0 20100929 (experimental)

./gcc/build/gcc/cc1plus -quiet -std=c++0x i386-dis-21931.ii
../../opcodes/i386-dis.h:1706:37: error: expected ',' or ';' before ':' token

and when I replace the semicolon, it works.


[Bug c++/42814] New: gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com
/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: gcc segfaults on gch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: JamesMikeDuPont at googlemail dot com


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #3 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:17 
---
Created an attachment (id=19667)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19667action=view)
precompiled headers

/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.


-- 


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #4 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:27 
---
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 326 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To g...@github.com:h4ck3rm1k3/MapNickAutotools.git
   1ae752a..6803b1b  master - master


-- 


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #5 from JamesMikeDuPont at googlemail dot com  2010-01-20 19:41 
---
Sorry that is not the precompiled header, but the preprocessed,
all you need to get the crash i hope.


-- 


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #8 from JamesMikeDuPont at googlemail dot com  2010-01-20 20:05 
---
got it again after make clean,
maybe it ran out of memory:
mdup...@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$ gunzip
src/filter_factory.ii.gz
mdup...@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$
/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H
-DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG
-I/usr/include/libpng12 -I/usr/include/freetype2
-I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include
-I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0
-I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I../include -save-temps -MT
libmapnik_la-filter_factory.lo -MD -MP -MF
.deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii 
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions


-- 


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #9 from JamesMikeDuPont at googlemail dot com  2010-01-20 20:09 
---
Subject: Re:  gcc segfaults on gch

/usr/local/bin/c++ --version
c++ (GCC) 4.5.0 20100113 (experimental)
Copyright (C) 2010 Free Software Foundation, Inc.

On Wed, Jan 20, 2010 at 9:01 PM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:


 --- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-20 20:01 
 ---
 Which GCC version are you using?  The preprocessed source does not use
 a precompiled header.  Compiling the file works ok for me with GCC 4.4.


 --

 rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
 
  GCC target triplet|                            |i?86-*-*


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

 --- You are receiving this mail because: ---
 You reported the bug, or are watching the reporter.



-- 


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



[Bug c++/42814] gcc segfaults on gch

2010-01-20 Thread JamesMikeDuPont at googlemail dot com


--- Comment #11 from JamesMikeDuPont at googlemail dot com  2010-01-20 
20:54 ---
Subject: Re:  gcc segfaults on gch

so I am thinking about a way to wrap the existing templates that I use.
there must be a way to reduce the size of the gch by specifing a list
of classes we use. that would reduce the build size.

this boost lib takes forever to process.
We only use %1 of it at a time. There has got to be a way to
precompile all these templates. A nice fine grained, for each header,
external pch database for stl and boost would make working with them
fun again.

I have been experimenting with grouping the headers into groups of
common dependencies. Basically I made a type level dependency tree
that is sliced up into pools of common types and topologically sorted
so that we can compile the the gch files in the right order and
include the previous gch.

I would consider putting some time into helping make the gch better if
you give me direction.

mike

On Wed, Jan 20, 2010 at 9:47 PM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:


 --- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-20 20:47 
 ---
 With unoptimized trunk I see us blowing the stack during garbage-collecting.
 Note that we have a load of templates in this testcase and we walk them in
 unfortunate order.

 (gdb)
 #79368 0x0835b9fb in ggc_collect ()
    at /home/richard/src/trunk/gcc/ggc-page.c:1962
 1962      ggc_mark_roots ();


 ugh.  We reach stuff from the function decl type.

 400                   gt_ggc_m_9tree_node ((*x).generic.type.size_unit);
 (gdb)
 #79358 0x0828fdc9 in gt_ggc_mx_lang_tree_node (x_p=0xb772f378)
    at ./gt-cp-tree.h:163
 163                   gt_ggc_m_9tree_node ((*x).generic.int_cst.common.type);
 (gdb)
 #79357 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xb7743000)
    at ./gt-cp-tree.h:398
 398                   gt_ggc_m_9tree_node ((*x).generic.type.values);

 hmm ...

 #79349 0x0829115c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff180)
    at ./gt-cp-tree.h:417
 417                   gt_ggc_m_9tree_node ((*x).generic.type.name);
 (gdb)

 #79348 0x08290cb9 in gt_ggc_mx_lang_tree_node (x_p=0xa8400138)
    at ./gt-cp-tree.h:355
 355                   gt_ggc_m_9tree_node
 ((*x).generic.type_decl.common.common.common.common.common.context);
 (gdb)
 #79347 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xa83ff000)
    at ./gt-cp-tree.h:398
 398                   gt_ggc_m_9tree_node ((*x).generic.type.values);
 (gdb)
 #79346 0x08290229 in gt_ggc_mx_lang_tree_node (x_p=0xa84003a8)
    at ./gt-cp-tree.h:228
 228                   gt_ggc_m_9tree_node
 ((*x).generic.decl_non_common.common.common.common.common.common.type);
 (gdb)
 #79345 0x0829121c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff420)
    at ./gt-cp-tree.h:425
 425                   gt_ggc_m_9lang_type ((*x).generic.type.lang_specific);
 (gdb)
 #79344 0x08292154 in gt_ggc_mx_lang_type (x_p=0xa83fdaa0) at 
 ./gt-cp-tree.h:713
 713               gt_ggc_m_9tree_node ((*x).u.c.template_info);


 hmm - we reach templates via integer constants ...


 --

 rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
 
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|-00-00 00:00:00         |2010-01-20 20:47:22
               date|                            |


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

 --- You are receiving this mail because: ---
 You reported the bug, or are watching the reporter.



-- 


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



[Bug c++/42765] New: If the compile fails, the gch is still produced.

2010-01-16 Thread JamesMikeDuPont at googlemail dot com
Even if the compile fails, the gch is produced!

mdup...@introspector-desktop:~/2010/01/extern/mapnik/include/mapnik$ make
datasource_cache.hpp.gch
g++   -x c++-header -I ../.. -I .. -I   -Winvalid-pch -pg \
-DMAPNIK_DEBUG \
-I/usr/include/libpng12   \
-I/usr/include/freetype2   -DHAVE_CONFIG_H  \
-I/home/mdupont/2010/01/mapnik/mapnik/agg/include \
-I/usr/local/include  \
-I/usr/include/libxml2   \
-D_REENTRANT -I/usr/include/cairomm-1.0 -I/usr/include/cairo
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12   -c
datasource_cache.hpp 
In file included from datasource_cache.hpp:31:0:
../mapnik/plugin.hpp:44:42: error: ‘Plugin’ has not been declared
make: *** [datasource_cache.hpp.gch] Error 1


mdup...@introspector-desktop:~/2010/01/extern/mapnik/include/mapnik$ make
datasource_cache.hpp.gch
make: `datasource_cache.hpp.gch' is up to date.


-- 
   Summary: If the compile fails, the gch is still produced.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: JamesMikeDuPont at googlemail dot com


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



[Bug pch/40215] GCH generated with -save-temps does not store preprocessor state.

2010-01-14 Thread JamesMikeDuPont at googlemail dot com


--- Comment #6 from JamesMikeDuPont at googlemail dot com  2010-01-14 13:55 
---
I am having this problem as well. 
Using the lastest version of g++.
Test like this :

If you include cassert in a pch, 
and then in the other file that uses the pch, the macro assert is no longer
there.


-- 


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



[Bug c++/42745] New: gcc segfaults on gch

2010-01-14 Thread JamesMikeDuPont at googlemail dot com
The gch is segfaulting
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/506728


-- 
   Summary: gcc segfaults on gch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: JamesMikeDuPont at googlemail dot com


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



[Bug c++/42745] gcc segfaults on gch

2010-01-14 Thread JamesMikeDuPont at googlemail dot com


--- Comment #2 from JamesMikeDuPont at googlemail dot com  2010-01-14 14:51 
---
Using the preprocessed headers breaks the pch. 

I tried this with the latest 4 4 head I compiled myself, but now it does not
break. 

I will continue testing with the latest version.
thanks for you help.


-- 

JamesMikeDuPont at googlemail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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