[Bug c/25802] VM types of external and internal linkage variables not diagnosed

[mrs at apple dot com]

--- Comment #2 from mrs at apple dot com  2006-05-06 21:24 ---
I have a fix for this, will post.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 CC||mrs at apple dot com


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

[Bug c/18740] Execution-time sizeof drops side effects

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2006-05-09 00:47 ---
I have a fix for this.


-- 


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

[Bug c/7948] gcc fails to fault gnu extension with -std=c99

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2006-05-09 00:48 ---
I have a fix for this.


-- 


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

[Bug c/25802] VM types of external and internal linkage variables not diagnosed

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2006-05-18 19:29 ---
aka radr://4336222


-- 


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

[Bug c/27673] [4.2 Regression] Gcc failed to bootstrap on Linux

[mrs at apple dot com]

--- Comment #7 from mrs at apple dot com  2006-05-19 01:39 ---
I'm building a cross compiler now...


-- 


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

[Bug c/27673] [4.2 Regression] Gcc failed to bootstrap on Linux

[mrs at apple dot com]

--- Comment #10 from mrs at apple dot com  2006-05-19 02:11 ---
A stage1 cross compiler with --enable-checking=assert targeting
--target=i686-unknown-linux-gnu hosted on darwin doesn't seem to fail, nor does
a darwin native compiler with --enable-checking=assert.  I've reviewed the
code, and it all looks very safe wrt the data structures.  I'm expected an
uninitialized scope data structure, but I see they carefully zero it and manage
it cleared.  Anybody have any hints, I'll see if I can dig out a linux box to
try next.


-- 


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

[Bug c/27673] [4.2 Regression] Gcc failed to bootstrap on Linux

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2006-05-19 04:01 ---
Ok, just finished a:

  configure --enable-languages=c

native build for i686-pc-linux-gnu, worked just fine...  I'll try an expanded
configure line next...


-- 


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

[Bug c/27673] [4.2 Regression] Gcc failed to bootstrap on Linux

[mrs at apple dot com]

--- Comment #12 from mrs at apple dot com  2006-05-19 06:09 ---
Ok, finished a:

configure   --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert
--prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local
--enable-languages=c,c++,java,objc

style build, and it gets through to building cc1 in stage3 and then dies with:

 /home/mstump/gcc-linux/./prev-gcc/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o cc1 /usr/lib/crt1.o /usr/lib/crti.o
/home/mstump/gcc-linux/./prev-gcc/crtbegin.o
-L/home/mstump/gcc-linux/./prev-gcc c-lang.o stub-objc.o attribs.o c-errors.o
c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o
c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o
c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o
c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o cc1-checksum.o main.o
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /home/mstump/gcc-linux/./prev-gcc/crtend.o /usr/lib/crtn.o
collect2: ld returned 1 exit status
$ echo $?
1

which I can't explain.  I think this might be a code gen bug that is unrelated
to my change.  A binary search on version numbers might help track it down.


-- 


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

[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2006-05-31 22:32 ---
I have a patch:

http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01580.html

that I think fixes this problem.  I'd be cusious to hear if it fixes the
Fortran problem for you.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 CC|    |mrs at apple dot com


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

[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs

[mrs at apple dot com]

--- Comment #17 from mrs at apple dot com  2006-06-08 22:26 ---
This should be fixed now.


-- 


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

[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2006-06-08 22:40 ---
The regression was introduced by:

2006-04-30  David Edelsohn  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.c (rs6000_override_options): Enable
TARGET_NO_FP_IN_TOC for section anchors.
(optimization_options): Enable section anchors for all
non-"Objective" languages.


-- 


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

[Bug bootstrap/28026] Cross compiles involving Darwin fail

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2006-06-14 17:11 ---
What problem did you see when ld wasn't in build_gcc?

Also, if the compiler is configured with isysroot, if gcc.c is taught to
default to using it, then I think the change to configure.ac isn't needed. 
This also helps with point #3 I think.


-- 


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

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning with VLA and typeof

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2006-07-08 10:10 ---
Fix submitted.


-- 


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2006-07-11 18:31 ---
I've posted a patch to fix this.


-- 


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

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning with VLA and typeof

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2006-07-12 13:13 ---
I have checked in a fix for this.


-- 


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

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning with VLA and typeof

[mrs at apple dot com]

--- Comment #9 from mrs at apple dot com  2006-07-15 18:52 ---
THis bug should be reopened.


-- 


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

[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c

[mrs at apple dot com]

--- Comment #13 from mrs at apple dot com  2008-11-11 23:13 ---
The darwin patch is fine.


-- 


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

[Bug c++/38087] New: Pseudo destructor call

[mrs at apple dot com]

In 5.2.4p2 [expr.pseudo]:

  The cv-unqualified versions  of
  the  object  type and of the type designated by the pseudo-destructor-
  name shall be the same type.

class B { };
class C : public B {
 void m() {
   this->~B();
 }
};

I tried:

  GNU C++ (GCC) version 4.4.0 20081003 (experimental) [trunk revision 140855]
(i686-apple-darwin9)

and it gave no error.


-- 
   Summary: Pseudo destructor call
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/38087] Pseudo destructor call

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2008-11-12 18:33 ---
I'm merely eching bits from the clang development list...  Now they think the
above doesn't apply, but 3.4.5p3 does:

3 If the unqualified-id is 
∼ type-name, the type-name is looked up in the context of the entire
postfix-expression. If the 
type T of the object expression is of a class type C, the type-name is also
looked up in the scope of class C. At least one 
of the lookups shall find a name that refers to (possibly
cv-qualified) T.

:-)


-- 


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

[Bug c/36113] fix C enumerators

[mrs at apple dot com]

--- Comment #5 from mrs at apple dot com  2008-11-18 20:26 ---
The C standard mandates that all enumeration constants have the same type, gcc
violates this requirement.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/38375] New: infinite loop on invalid struct redefinition

[mrs at apple dot com]

struct sqt13 {};
struct sqt13 {
  struct sqt13 x;
} y = { 3.0 };

takes infinite time/memory to compile.

GNU C (GCC) version 4.4.0 20081003 (experimental) [trunk revision 140855]
(i686-apple-darwin9)


-- 
   Summary: infinite loop on invalid struct redefinition
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c/38375] infinite loop on invalid struct redefinition

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-12-02 21:43 ---
Radar 6400208


-- 

mrs at apple dot com changed:

   What|Removed |Added

 CC||mrs at apple dot com


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[mrs at apple dot com]

--- Comment #17 from mrs at apple dot com  2008-12-09 23:24 ---
I agree, Apple would like this as well...

radr://5739832


-- 


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

[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"

[mrs at apple dot com]

--- Comment #21 from mrs at apple dot com  2008-12-12 18:42 ---
My long term guidance would be to engineer gcc to use its copy of the libgcc_s
dylib and link against it.  This would mean that the newly installed libgcc_s
should be found first, over /usr/lib, and that development and support mirror
linux, in all the usual ways.


-- 


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

[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo

[mrs at apple dot com]

--- Comment #9 from mrs at apple dot com  2008-12-18 12:21 ---
Ok with the:

+  *-*-darwin[3-8]*) have_unwind_getipinfo=no ;;

spelling.  It matches the spelling in the rest of the compiler, which makes it
easier to spot and modify.  Technically, the:

*-*-darwin[0-8]|*-*-darwin[0-8].*) ...

is a bit more perfect, but, I'm not terribly worried about darwin1 or darwin2
systems.  They won't work for other reasons.


-- 


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

[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing

[mrs at apple dot com]

--- Comment #8 from mrs at apple dot com  2009-01-24 04:18 ---
First, you didn't test 4.0.0, so all your reasoning is invalid.  Second,
claiming no ABI breakage when there is abi breakage is silly.  I guess if you
have no customers with no software, with do previously deployed software and
you don't care about abi breakage, you can get away with it.  Unfortunately,
this doesn't apply in our case.

I'd rather you close this out as won't fix, if you can't be bothered to even
actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more
honest.  Closing it as invalid is wrong.

:-(


-- 


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

[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2009-01-24 04:22 ---
First, you didn't test 4.0.0, so all your reasoning is invalid.  Second,
claiming no ABI breakage when there is abi breakage is silly.  I guess if you
have no customers with no software, with do previously deployed software and
you don't care about abi breakage, you can get away with it.  Unfortunately,
this doesn't apply in our case.

I'd rather you close this out as won't fix, if you can't be bothered to even
actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more
honest.  Closing it as invalid is wrong.

:-(


-- 


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

[Bug c++/9726] namespace typedef hides global when interacting with using directive

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2005-11-15 23:56 ---
radr://4329536


-- 


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

[Bug c++/25316] New: POD structures can have

[mrs at apple dot com]

A user reported that this:

mrs $ cat > t98.c
struct X {
int a, b;
X() : a(0), b(0) {}
};

static void f(const char *s, ...);

int main()
{
X x;
f("foo!", x);
return 0;
}

works on other C++ compilers (Metroworks), but on gcc:

mrs $ ./g++ -B./ -c t98.c
t98.c: In function 'int main()':
t98.c:11: warning: cannot pass objects of non-POD type 'struct X' through
'...'; call will abort at runtime

This, according the a reading of the standard is a POD type, no, really.  :-) 
Curious though, the same misreading of the text was done by the author of:

3 It is possible to transfer into  a  block,  but  not  in  a  way  that
  bypasses declarations with initialization.  A  program  that  jumps77)
  from a point where a local variable with automatic storage duration is
  not in scope to a point where it is in scope is ill-formed unless  the
  variable  has POD type (_basic.types_) and is declared without an ini-
  tializer (_dcl.init_).

as the intent was to not bypass a constructor call.

Also curious is the wording:

  To default-initialize an object of type T means:

  --if T is a non-POD class type (clause _class_), the default construc-
tor  for  T is called (and the initialization is ill-formed if T has
no accessible default constructor);

which again reinforces the idea that only non-PODs can have default
constructors called.

Seems like we need a DR to clarify this, if one doesn't aready exist, and then
to fix up the compiler, if any fixups need to be done.  I'd expect that the
compiler behavior is correct, but until DRed.


-- 
   Summary: POD structures can have
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/25316] POD structures can have

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2005-12-08 20:51 ---
Ah, Geoff found it:

  The definition of 'aggregate' is in 8.5.1

I new it was there someplace.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|POD structures can have |POD structures can have


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

[Bug c++/25316] POD structures can have

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2005-12-08 23:53 ---
As I said, the prohibition is in 8.5.1 in the definition of aggregate.  This is
what makes it not a POD.  No DR needed, no gcc bug fix needed, the bug was in
the Metroworks compiler and in the users understanding.


-- 


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

[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*

[mrs at apple dot com]

--- Comment #9 from mrs at apple dot com  2006-07-19 23:50 ---
We can't define __Unwind_GetIPInfo in libgcc_s.10.5.dylib at this time.  If we
create a situation in which we can, rest assured, we will.


-- 


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

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[mrs at apple dot com]

--- Comment #12 from mrs at apple dot com  2006-08-10 16:54 ---
Trivially, one could use turing completeness at compile time to achieve the
desired result.  :-)  Not that I think that is better than `fixing' this bug.


-- 


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

[Bug tree-optimization/28778] New: strict-aliasing bug

[mrs at apple dot com]

mrs $ cat /tmp/t2.cc
typedef long GLint;
void aglChoosePixelFormat(const GLint *);

void find(const int *alistp) {
  const int *blist;
  int list[32];
  if (alistp)
blist = alistp;
  else {
list[3] = 42;   /* this store disappears with -fstrict-aliasing */
blist = list;
  }
  aglChoosePixelFormat((GLint*)blist);
}
mrs $ ./xgcc -B./ -S -O1 /tmp/t2.cc -fno-strict-aliasing && grep 42 t2.s
li r0,42
mrs $ ./xgcc -B./ -S -O1 /tmp/t2.cc -fstrict-aliasing && grep 42 t2.s
mrs $ 

The store cannot be removed, as the converted pointer can be used inside the
aglChoosePixelFormat function to access the value.  Since the optimizer can't
see that it isn't used, the optimizer must assume it can as the function isn't
marked pure.  If it had been, then the optimization would be ok.

t2.cc.035t.dce1 is the first pass that doesn't have the store, t2.cc.034t.fre
has the store.

This worked in 3.3, but not 4.0.1.  This doesn't work in gcc version 4.2.0
20060815 (experimental) on powerpc-apple-darwin9.0.0d1, nor on
i686-apple-darwin8.


-- 
   Summary: strict-aliasing bug
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug tree-optimization/28778] strict-aliasing bug

[mrs at apple dot com]

--- Comment #2 from mrs at apple dot com  2006-08-18 21:12 ---
radr://4658741


-- 


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

[Bug c++/28139] alias information for EH is wrong

[mrs at apple dot com]

--- Comment #8 from mrs at apple dot com  2006-08-25 22:27 ---
Date: Fri, 25 Aug 2006 16:03:00 -0400
From: Jason Merrill <[EMAIL PROTECTED]>
Subject: Re: RFA: Fix PR 28139
Message-id: <[EMAIL PROTECTED]>

This is OK.

:REVIEWURL http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01295.html:


-- 


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

[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2006-09-29 01:29 ---
This should be fixed by the last checkin.


-- 


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[mrs at apple dot com]

--- Comment #8 from mrs at apple dot com  2006-09-29 23:15 ---
> If it is a VAR_DECL, then I believe the optimization is always safe

Not in C++.


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[mrs at apple dot com]

--- Comment #16 from mrs at apple dot com  2006-10-02 09:32 ---
The dynamic type of the object at &i is indeed float and has the value 7.0 (iff
align and sizes work out).  We permitted this so that can can do:

  class C { ... };
  char buf[1024];
  new (&buf[n]) C

and have the dynamic type of the storage be C.  You can know the dynamic type
is C, by doing a virtual dispatch, or by asking for the name of the type with
rtti.

Likewise, you can do:

  new (&i) float(7.0)

with the same effects.  The dynamic type is float, and the value is 7.0, and
this is in all ways the same as:

  *(float*)&i = 7.0

Thinking about this some more, it would appear that it is unsafe to reorder
writes of otherwise non-conflicting types past each other as type based
analysis alone isn't enough to ensure they don't conflict.  It might be
reasonable to add the C rules that the dynamic type _must_ match the static
(declared) type, if there is one for types other than pointer or pointer to
member the the language standard and to clarify the dynamic type of an object
when a bitwise copy of the object is made to better match the C rules.

Reads should be fine as they are required to be the same type as the write (or
character).  In practice, if the optimizer can't see the placement new, it
can't reorder things so this is safe; if it can see it, then it should do value
based analysis in addition to type analysis and conclude they conflict (or can
conflict) and still avoid doing the wrong thing.

I do agree, that for now, this isn't a bug in the library.  It could be made a
bug in the library by requring a placement new operator as the only way in
which storage can be reused as a different dynamic type.


-- 

mrs at apple dot com changed:

   What|Removed |Added

         CC|        |mrs at apple dot com


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2006-10-02 19:28 ---
What is your position based upon?  Mine is based upon having been in the room
when we decided what the C rules probably were, what the C++ rules could be and
the up side and down side of each choice and where we decided what our intent
was going to be and lots of word smithing sessions as well.  You can see some
of the depth with which we discussed it in our formulation of the wording in
the standard:

6 Similarly,  before the lifetime of an object has started but after the
  storage which the object will occupy has been allocated or, after  the
  lifetime  of  an  object  has  ended  and before the storage which the
  object occupied is reused or released, any lvalue which refers to  the
  original  object may be used but only in limited ways.  Such an lvalue
  refers to allocated  storage  (_basic.stc.dynamic.deallocation_),  and
  using the properties of the lvalue which do not depend on its value is
  well-defined.  If  an  lvalue-to-rvalue  conversion  (_conv.lval_)  is
  applied  to such an lvalue, the program has undefined behavior; if the
  original object will be or was of a non-POD class  type,  the  program
  has undefined behavior if:

  --the lvalue is used to access a non-static data member or call a non-
static member function of the object, or

  --the lvalue is implicitly converted (_conv.ptr_) to a reference to  a
base class type, or

  --the   lvalue   is   used   as   the   operand   of   a   static_cast
(_expr.static.cast_) (except when the conversion  is  ultimately  to
char& or unsigned char&), or

  --the   lvalue   is   used   as   the   operand   of   a  dynamic_cast
(_expr.dynamic.cast_) or as the operand of typeid.

7 If, after the lifetime of an object has ended and before  the  storage
  which  the object occupied is reused or released, a new object is cre-
  ated at the storage location which the  original  object  occupied,  a
  pointer that pointed to the original object, a reference that referred
  to the original object, or the name of the original object will  auto-
  matically  refer  to  the new object and, once the lifetime of the new
  object has started, can be used to manipulate the new object, if:

  --the storage for the new object exactly overlays the storage location
which the original object occupied, and

  --the  new object is of the same type as the original object (ignoring
the top-level cv-qualifiers), and

  --the original object was a most derived  object  (_intro.object_)  of
type  T  and the new object is a most derived object of type T (that
is, they are not base class subobjects).  [Example:
  struct C {
  int i;
  void f();
  const C& operator=( const C& );
  };
  const C& C::operator=( const C& other)
  {
  if ( this != &other )
  {
  this->~C(); // lifetime of *this ends
  new (this) C(other);// new object of type C created
  f();// well-defined
  }
  return *this;
  }
  C c1;
  C c2;
  c1 = c2;// well-defined
  c1.f(); // well-defined; c1 refers to a new
object of type C
 --end example]

8 If a program ends the lifetime of an object  of  type  T  with  static
  (_basic.stc.static_)  or automatic (_basic.stc.auto_) storage duration
  and if T has a non-trivial destructor,35) the program must ensure that
  an object of the original type occupies  that  same  storage  location
  when  the implicit destructor call takes place; otherwise the behavior
  of the program is undefined.  This is true even if the block is exited
  with an exception.

We explcitly did consider overlaying one type with a completely different type
and did so intend for the standard to allow that.  Further, our intent of
saying that automatics and objects with static duration could be so changed
provided certain conditions were met was meant no only to state that this could
be done, but to state the exact sitations in which it was defined to do so.

> Mike's position is that accessing a variable using its static type is not 
> always safe; I find this bizarre.

Welcome to C++, let me quote the standard:

8 If a program ends the lifetime of an object  of  type  T  with  static
  (_basic.stc.static_)  or automatic (_basic.stc.auto_) storage duration
  and if T has a non-trivial destructor,35) the program must ensure that
  an object of the original type occupies  that  same  storage  location
  when  the implicit destructor call takes place; otherwise the behavior
  of the program is undefined.

If we didn't mean exactly what we wrote, why on earth would we write it?  Hint,
in this, we meant exactlty what was written.  I was there, in every single
meeting where 

[Bug target/10901] non-local goto's don't work on powerpc-darwin

[mrs at apple dot com]

--- Comment #16 from mrs at apple dot com  2006-10-05 00:57 ---
Our positron branch has the fix for this in it.  We should dig it out and
submit it.


-- 


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

[Bug target/25850] real kind=16 failures on powerpc-darwin

[mrs at apple dot com]

--- Comment #10 from mrs at apple dot com  2006-10-06 05:46 ---
> Apple has no long double library support

This is false.  What we don't have is symbol versioning and the `normal' names
refer to an abi different long double, 8 bytes as I recall.

The impact to the fortran frontend should be 2 lines of code, if that.  The
impact to the darwin.c file will be larger.


-- 


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

[Bug c++/15795] No way to teach operator new anything about alignment requirements

[mrs at apple dot com]

--- Comment #37 from mrs at apple dot com  2006-10-10 04:54 ---
Additionally, you can petition ISO/C++ to provide a more elegant solution for
you.

VxWorks also does 16-byte alignment on ppc (for altivec) as I recall.


-- 


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

[Bug bootstrap/29531] New: REG: --disable-bootstrap && make bootstrap doesn't work

[mrs at apple dot com]

If one configures with --disable-boostrap --enable-languages=c and then builds
with make bootstrap but doesn't have ada installed, the build fails.  The
problem is that gcc/configure unconditionally adds ada to the stage 1 languages
BOOT_LANGUAGES, even though --enable-languages=c is used.

In non--disable-boostrap builds I think this was fixed by the patch in:

http://gcc.gnu.org/PR24252

(that was incorrectly attached to the wrong PR, but the patch is the one that
seems to cause it to work).

This is a regression


-- 
   Summary: REG: --disable-bootstrap && make bootstrap doesn't work
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrs at apple dot com


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

[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2006-10-20 22:09 ---
I think something like:

Doing diffs in configure.ac.~1~:
--- configure.ac.~1~2006-10-16 12:38:48.0 -0700
+++ configure.ac2006-10-20 15:00:44.0 -0700
@@ -3419,6 +3419,16 @@ changequote([,])dnl
done
;;
esac
+   if test "$language" = ada
+   then
+   case ",$enable_languages," in
+   *,ada,*) ;;
+   *,all,*) ;;
+   *)
+   ok=false
+   ;;
+   esac
+   fi
$ok || continue

all_lang_makefrags="$all_lang_makefrags
\$(srcdir)/$subdir/Make-lang.in"
--

fixes this.


-- 


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

[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2006-10-20 22:29 ---
If the decision is to rip out mass amounts of code for bootstrapping in stage3,
well, that can be done, but unless that it is done, this is a bug.  If it is to
be done, that it is a bug that it isn't done.  As for WONTFIX, well, I already
did fix it, so that isn't quite true.


-- 


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

[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work

[mrs at apple dot com]

--- Comment #7 from mrs at apple dot com  2006-10-20 22:33 ---
I'd like my patch to be considered for 4.2, seems safee enough.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work

[mrs at apple dot com]

--- Comment #9 from mrs at apple dot com  2006-10-20 23:24 ---
I spent a minute upgrading my build system to handle the new world order that's
coming down the pike in 4.3...  The problem I thought I might hit didn't
happen, so, I'm fine with this being WONTFIX.  I now do a bootstrap by not
using the --disable-bootstrap configure option.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/30659] New: ICE in undefined template

[mrs at apple dot com]

mrs2 $ ./xgcc -B./ /tmp/t.ii
/tmp/t.ii:1: error: ISO C++ forbids declaration of 'basic_istream' with no type
/tmp/t.ii:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
mrs2 $ cat /tmp/t.ii
extern "C" { extern template basic_istream& 
operator>>(basic_istream&, string&);


-- 
   Summary: ICE in undefined template
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/30659] ICE in undefined template

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2007-01-31 20:30 ---
radr://4958852


-- 


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

[Bug target/30518] error from system header file

[mrs at apple dot com]

--- Comment #10 from mrs at apple dot com  2007-02-08 19:02 ---
Ignore me, I'm going crazy.  This is really just a simple problem of the
software isn't portable to 10.3.9.  The right fix is to modify it so that it
compiles.  The OS has been fixed to not have this bug in more recent versions.


-- 


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

[Bug c/4076] -Wunused doesn't warn about static function only called by itself.

[mrs at apple dot com]

--- Comment #13 from mrs at apple dot com  2007-02-16 17:59 ---
Adding inline seems obvious to me, all the other functions are marked inline.


-- 


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

[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558

[mrs at apple dot com]

--- Comment #16 from mrs at apple dot com  2007-04-05 02:52 ---
I think this patch breaks:

  FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error)
  FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors)

on powerpc-apple-darwin:

/Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4736b.C:
In function 'i
nt main()':
/Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4736b.C:41:
internal co
mpiler error: in convert_memory_address, at explow.c:319

:-(

radr://5107167


-- 


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

[Bug c++/31513] [4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to Function

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2007-04-09 20:25 ---
radr://5076058


-- 

mrs at apple dot com changed:

   What|Removed |Added

 CC||mrs at apple dot com


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

[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558

[mrs at apple dot com]

--- Comment #17 from mrs at apple dot com  2007-04-13 03:09 ---
The followup problem has now been fixed in 4.2.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 CC|mrs at apple dot com|


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

[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions

[mrs at apple dot com]

--- Comment #37 from mrs at apple dot com  2007-04-25 01:42 ---
libgcc_s.10.5.dylib now includes __Unwind_GetIPInfo on mainline and in 4.2...


-- 


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

[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions

[mrs at apple dot com]

--- Comment #38 from mrs at apple dot com  2007-04-25 01:56 ---
I think a non-working --with-system-libunwind corner case on darwin is a P4 at
best?


-- 


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

[Bug target/32961] GCC 4.2 has different requirements for x86 shift xmm intrinsics

[mrs at apple dot com]

--- Comment #2 from mrs at apple dot com  2007-10-16 19:29 ---
I can confirm the bug and that Intel's documentation does not have a immediate
restriction on any of the epi functions.


-- 


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

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[mrs at apple dot com]

--- Additional Comments From mrs at apple dot com  2005-03-24 19:36 ---
Subject: Re:  shared SH libgcc is exporting too many symbols

On Mar 24, 2005, at 8:30 AM, Joern RENNECKE wrote:
> ! #if 1 /* ??? The export list mechanism is broken, everything that  
> is not
> !  hidden is exported.  */
> ! #undef FUNC
> ! #define FUNC(X).type X,@function  .hidden X
> ! #undef ALIAS
> ! #define ALIAS(X,Y).global GLOBAL(X); .set GLOBAL(X),GLOBAL 
> (Y); .hidden GLOBAL(X)
> ! #endif

Could you add a reference to the PR in the code, as the next person  
to play with this will find it useful.




-- 


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

[Bug preprocessor/19475] [3.3/3.4/4.0 Regression] missing whitespace after macro name in C90 or C++

[mrs at apple dot com]

--- Additional Comments From mrs at apple dot com  2005-04-05 22:54 ---
Subject: Re: [PATCH] Fix PR preprocessor/19475

On Apr 5, 2005, at 4:56 AM, Jakub Jelinek wrote:
> Thanks, you're right.  With following incremental patch
> it passes just fine (and fails with cc1 built without the patch).
>
> diff -u gcc/testsuite/gcc.dg/cpp/macspace2.c

I prefer if the flag is added in the framework driver, not the  
testcase files



-- 


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

[Bug c++/37085] New: global friends in classes

[mrs at apple dot com]

Global friend inside a class regressed.

$ cat /tmp/t.cc
class test1 {
 public:
  friend void newtest1(int x) {
  }
};

int main(int argc, char *argv[]) {
  newtest1(5);
}
$ ./xgcc -B./ /tmp/t.cc -c
/tmp/t.cc: In function ‘int main(int, char**)’:
/tmp/t.cc:8: error: ‘newtest1’ was not declared in this scope
GNU C++ (GCC) version 4.4.0 20080811 (experimental) [trunk revision 138965]
(i686-apple-darwin9)

This worked just fine in gcc 4.0.1.

radr://6135771


-- 
   Summary: global friends in classes
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
  GCC host triplet: i686-apple-darwin9


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

[Bug c++/37085] global friends in classes

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-08-11 21:39 ---
Oh, see 11.4p5 (ANSI 98 standard) for details on this type of code.


-- 


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

[Bug c++/37260] New: infinite loop in init

[mrs at apple dot com]

gcc version 4.4.0 20080827 (experimental) [trunk revision 138965] (GCC) 

produces:

/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
/tmp/t.cc:9: error: initializer for ‘pthread_once_t’ must be brace-enclosed
[...]

for

struct pthread_once_t { };
struct test {
  pthread_once_t once;
};

int main(void) {
  struct test foo = {
once: PTHREAD_ONCE_INITIALIZER
  };

  return 0;
}

:-(


-- 
   Summary: infinite loop in init
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/37260] infinite loop in init

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-08-27 22:47 ---
I think reshape_init_r doesn't handle init when it ia error_mark_node.


-- 


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

[Bug c++/37465] New: ctors never override virtual functions

[mrs at apple dot com]

class A {
 virtual int B() { return 0; }
};

class B: A {
 B() { }
};

gives an error, but should compile (as gross as it is).  I'm hoping there is a
prohibition against it, but didn't find one.


-- 
   Summary: ctors never override virtual functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/37465] ctors never override virtual functions

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-09-10 18:28 ---
radr://6202462


-- 


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

[Bug c++/37728] New: if scoping for declarations

[mrs at apple dot com]

In:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html

we were discussing possible bugs in g++ scoping for if statements.

$ cat t.cc
void foo() {
  if (int x = 0) {
int x;
  }
}
$ ./xgcc -B./ -c t.cc 
$ 

they expected this to produce a redeclaration error on the inner declaration
for X.

Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision 140855]
(GCC)

There were other concerns about for, but, others seem to think gcc does the
right thing with them.


-- 
   Summary: if scoping for declarations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug middle-end/37864] New: incorrect warning from fold

[mrs at apple dot com]

We found an interesting bootstrap failure in gcc after changing a machine
definition some, the important bits are below.  Something is wrong, but it is
hard to say exactly what.  The warning would be fine, if there were no
preprocessor involved.  But, it is.  The warning doesn't make any sense for the
source in stmt.c, and the definitions in insn-*.h are also valid.  When the
preprocessor combines them, then the result is worthy of warning about, but,
that's hardly the fault of stmt.c, or the machine definition.  Logically, we
want to only issue the warning if the code in question came from the user, not
as a combination of macro preprocessing.  I can't recall any other place in the
compiler when we take into consideration the preprocessor like this, so that
makes this case weird in my book.

So, some solutions:

  Don't use -Werror, because stmt.c can warn on some .md files.
  Remove the warning, the benefit isn't work the risk of false positives.
  Keep the warning, but somehow take into consideration the preprocessor (ick).
  Recode how the insn-*.h files are generated to avoid the warning.
  Redo stmt.c to use a local variable and then use that in the conditional.

Thoughts?  Currently we're taking the last approach, but it just feels icky. 
Longer term, would be nice if gcc were architected so that this can't crop up.

$ cat /tmp/t.c
extern int target_flags;
#define ARM ((target_flags & (1 << 16)) != 0)
#define THUMB (!ARM)
#define LONGCALL ((target_flags & (1 << 11)) != 0)

#define ARMLONGCALL ((target_flags & ((1<<16) | (1<<11))) != 0)

// 4.2 version:
//#define HAVE_tablejump (ARM || LONGCALL)
// shows same problem in 4.4
#define HAVE_tablejump (ARMLONGCALL)
#define HAVE_casesi (THUMB)

void foo();

void expand_case()
{
  if (0
  /* If neither casesi or tablejump is available, we can
 only go this way.  */
  || (!HAVE_casesi && !HAVE_tablejump))
foo();
}
$ ./xgcc -B./ -c /tmp/t.c -O
/tmp/t.c: In function 'expand_case':
/tmp/t.c:21: warning: 'and' of mutually exclusive equal-tests is always 0

gcc version 4.4.0 20081003 (experimental) [trunk revision 140855] (GCC)


-- 
   Summary: incorrect warning from fold
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
     Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug libstdc++/35081] New: abi breakage in typeinfo (4.0.1 -> 4.2.1)

[mrs at apple dot com]

 private:
+/// Assigning type_info is not supported.
+type_info& operator=(const type_info&);
+type_info(const type_info&);
   };

   /**
@@ -169,9 +167,11 @@
   {
   public:
 bad_cast() throw() { }
+
 // This declaration is not useless:
 // http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
 virtual ~bad_cast() throw();
+
 // See comment in eh_exception.cc.
 virtual const char* what() const throw();
   };
@@ -181,9 +181,11 @@
   {
   public:
 bad_typeid () throw() { }
+
 // This declaration is not useless:
 // http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
 virtual ~bad_typeid() throw();
+
 // See comment in eh_exception.cc.
 virtual const char* what() const throw();
   };

?


-- 
   Summary: abi breakage in typeinfo (4.0.1 -> 4.2.1)
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


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

[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)

[mrs at apple dot com]

--- Comment #2 from mrs at apple dot com  2008-02-08 03:10 ---
It should be const char**argv.


-- 


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

[Bug c/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2008-02-12 01:28 ---
We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and
static inline otherwise in our tree.


-- 


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2008-02-13 02:59 ---
Ok, how about:

#ifdef __GNUC_STDC_INLINE__
#define __EXTERN_INLINE __inline __attribute__((always_inline))
#else
#define __EXTERN_INLINE extern __inline __attribute__((always_inline))
#endif
__EXTERN_INLINE void foo() ;
__EXTERN_INLINE void foo() {
  __asm ("nop");
}

void bar1() {
  foo();
}

I think that will work...  See any gotchas (other than linking when it can't be
inlined)?


-- 


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #9 from mrs at apple dot com  2008-02-12 22:04 ---
Ah, I see now, you're right, that doesn't work.  :-(


-- 


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

[Bug libstdc++/35173] New: trivial long -> int implicit conversions

[mrs at apple dot com]

ollate   = 1L << 2;
static const category time  = 1L << 3;
static const category monetary  = 1L << 4;
static const category messages  = 1L << 5;


bits/ios_base.h:
  _S_boolalpha  = 1L << 0,
  _S_dec= 1L << 1,
  _S_fixed  = 1L << 2,
  _S_hex= 1L << 3,
  _S_internal   = 1L << 4,
  _S_left   = 1L << 5,
  _S_oct= 1L << 6,
  _S_right  = 1L << 7,
  _S_scientific = 1L << 8,
  _S_showbase   = 1L << 9,
  _S_showpoint  = 1L << 10,
  _S_showpos= 1L << 11,
  _S_skipws = 1L << 12,
  _S_unitbuf= 1L << 13,
  _S_uppercase  = 1L << 14,

  _S_app= 1L << 0,
  _S_ate= 1L << 1,
  _S_bin= 1L << 2,
  _S_in = 1L << 3,
  _S_out= 1L << 4,
  _S_trunc  = 1L << 5,
  _S_ios_openmode_end = 1L << 16 

  _S_badbit = 1L << 0,
  _S_eofbit = 1L << 1,
  _S_failbit= 1L << 2,
  _S_ios_iostate_end = 1L << 16 

  _S_ios_seekdir_end = 1L << 16


-- 
   Summary: trivial long -> int implicit conversions
   Product: gcc
       Version: 4.2.1
    Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #7 from mrs at apple dot com  2008-02-12 18:01 ---
Testcase for comment #6?  I believe we tested every case and it works fine.


-- 


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #14 from mrs at apple dot com  2008-02-13 20:49 ---
I think we should do this; further, I think we should add && pedantic to it as
well.  Only people that want to be hurt by the standard should be.


-- 


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

[Bug c/35198] New: missed evaluation of VM array type

[mrs at apple dot com]

void* a(void* x) {return (int (*)[10][printf("hi\n")])x;}
  int main() { int i; a(&i); }

should print hi.  This was still broken in 4.3 in July, 2007.


-- 
   Summary: missed evaluation of VM array type
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: mrs at apple dot com


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

[Bug bootstrap/32009] [4.3/4.4 Regression] building gcc4-4.3/4.4.0-20070518 failed on OSX 10.3.9

[mrs at apple dot com]

--- Comment #28 from mrs at apple dot com  2008-02-20 15:44 ---
Thanks.


-- 


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

[Bug target/10901] non-local goto's don't work on powerpc-darwin

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2008-02-21 19:48 ---
Nope.


-- 


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

[Bug c/35449] New: extended asm documentation wrong

[mrs at apple dot com]

In doc/extend.texi we have:

int foo ()
@{
  int x = 42;
  int *y = &x;
  int result;
  asm ("magic stuff accessing an 'int' pointed to by '%1'"
"=&d" (r) : "a" (y), "m" (*y));
  return result;
@}

two problems, r != result.  Second problem, there should be a : before the
output constraint.

The current docs on the web site are unchanged.


-- 
   Summary: extended asm documentation wrong
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/35450] New: ice on valid template

[mrs at apple dot com]

#include 

struct test_a{ void load(){} };
struct test_b{ };

template  class Concept, typename Model>
struct models
{

typedef char (&yes)[2];
typedef char no;

template  class C, typename M, typename C::type
P = 0>
struct hint
{ };

template 
static yes test(M*, hint * = 0);
static no  test(...);

static const bool value = (sizeof(test((Model*)0))==sizeof(yes));
};

template 
struct member
{
typedef Type Class::* type;
};

template 
struct loadable
{ };


int main()
{
std::cout << models::value << std::endl;
}

# with 4.2.1:
$ g++-4.2 t.cc
t.cc: In instantiation of ‘models’:
t.cc:37:   instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://developer.apple.com/bugreporter> for instructions.

And the same with a compiler from today as well:
$ /Volumes/pool1/mrs/packages/gcc-20080308/bin/g++ t.cc
t.cc: In instantiation of ‘models’:
t.cc:37:   instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This works on comeau.

radr://5772368


-- 
   Summary: ice on valid template
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrs at apple dot com


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

[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2008-03-04 01:19 ---
My bug is related to this, but mine is an ice on valid.


-- 


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

[Bug debug/35462] New: anonymous struct in c++ has wrong name in -gdwarf-2

[mrs at apple dot com]

typedef struct {
  int x;
} mystruct;
mystruct m;

should either have no name or a name of mystruct in C++.  I see:

.ascii "\0"   ; DW_AT_name

and

.ascii "$_0\0"  ; external name

This works as expected in C.

Still fails in 20080308.  I think this is target independent.


-- 
   Summary: anonymous struct in c++ has wrong name in -gdwarf-2
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug debug/35463] New: typedef missing in debug information with -gdwarf-2 for c++

[mrs at apple dot com]

typedef struct {
  int x;
} mystruct;
mystruct m;

is missing any debug information for mystruct.  If one compiles as C, mystruct
is present.

Still broken in 20080308 compiler.  Should be target independent.


-- 
   Summary: typedef missing in debug information with -gdwarf-2 for
c++
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-03-04 20:14 ---
radr://5070293


-- 


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

[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-03-04 20:15 ---
radr://5070293


-- 


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

[Bug c++/35640] New: invalid access to protected base class

[mrs at apple dot com]

class A {
};

class B: protected A {
};

class C: protected A {
public:
C(B & b);
};

C::C(B & b)
: A(b)
{
}

int main() {
B b;
C c(b);
return 0;
}

should give an error for : A(b), the conversion from B to A is invalid as A is
protected.

This still fails on 4.4.0 20080317

radr://5805511


-- 
   Summary: invalid access to protected base class
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/35688] New: template visibility botch

[mrs at apple dot com]

/* { dg-require-visibility "" } */
/* { dg-options "-fvisibility=hidden" } */

/* { dg-final { scan-hidden "__ZN1s6vectorI1AEC1Ev" } } */
/* { dg-final { scan-hidden "__ZN1s3fooI1AEEvT_" } } */
/* Radar 5813435 */

namespace s __attribute__((visibility("default"))) {
  template 
class vector {
  public:
vector() { }
  };
  template 
void foo(T t) {
  }
}

class A {
public:
  A() { }
};

s::vector v;

int main() {
  A a;
  s::foo(a);
}

should pass (if I got the spelling for the symbols correct wrt leading _).

radr://5813435


-- 
   Summary: template visibility botch
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin

[mrs at apple dot com]

--- Comment #13 from mrs at apple dot com  2009-02-17 19:18 ---
Ok to add that to darwin.h.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #16 from mrs at apple dot com  2009-08-31 17:37 ---
Oops, I mean #12 and #13.  For #13, make sure there isn't an existing entry
already.  If there is, the code should be added to it.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #15 from mrs at apple dot com  2009-08-31 17:35 ---
#13 looks fine.  #14 needs a build to confirm it works.  I've tested the style
of #14 in the gcc-4.2.1 tree and it works as expected.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2009-08-31 20:37 ---
That file just has:

# APPLE LOCAL file dynamic-no-pic
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin.

BOOT_CFLAGS=-g -O2 -mdynamic-no-pic

in it.  This just results in a faster compiler, otherwise, there should be no
real change.


-- 


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

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2009-09-02 17:41 ---
dwarfdump exists on 10.5 and 10.6.  Not sure if that would help at all (I've
not been following what people are doing).


-- 


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

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[mrs at apple dot com]

--- Comment #13 from mrs at apple dot com  2009-09-02 20:17 ---
Subject: Re:  [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at
revision 151318

On Sep 2, 2009, at 12:57 PM, howarth at nitro dot med dot uc dot edu  
wrote:
> --- Comment #12 from howarth at nitro dot med dot uc dot edu   
> 2009-09-02 19:57 ---
> (In reply to comment #11)
>> dwarfdump exists on 10.5 and 10.6.  Not sure if that would help at  
>> all (I've
>> not been following what people are doing).
>
> Can you find out if the darwin's strip reorders the sections? This  
> seems to
> by why Solaris's comparison of stage2 and stage3 is failing  
> (PR41228)? If so
> is there an option to suppress the reordering?

No option.  I suspect it can.  You should be able to run otool and  
print the sections out.  As I recall, the order printed, is the order  
in the file.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #21 from mrs at apple dot com  2009-09-02 20:37 ---
The patch in #19 is wrong.  If you configure a x86->ppc64 compile, it would
want to use -m32, which is wrong.  We experimented with a change like that in
#20 and it resulted in failures; I can't imagine any good coming from it.  In
short, CC isn't a variable that can be changed here, like this, only
tentative_cc can be.  I don't know what these two bits are trying to fix, so, I
can't say what the right solution is.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #26 from mrs at apple dot com  2009-09-03 00:20 ---
First, config.guess is orthogonal to the entire discussion, because of that, we
never need to mention it again.

Next, we do a case analysis of every combination of host/target and build…  We
engineer each case to work as desired.  Once that is done, you'll discover that
we absolutely do need the i386 case to set -m32.  If that isn't done, the
compiler defaults to 64-bit, and that runs counter to the command implied by
the i386, which is to generate 32-bit code.  So, the fragment I sent is
absolutely required, unchanged.  You can know this is true by configure
--build=i386-apple-darwin10 on a 64-bit SL box and running file on gcc/expr.o. 
If it is 64-bit, it is wrong.

-m32 should never be set because the x86_64 case.  x86_64 means 64-bit, so, the
most it implies is -m64.  For this reason, #19 must be wrong.  x86_64 implying
-m64 is useful for gcc's that default to 32-bit code-gen.  I don't have that in
my tree, as I don't have to worry much about older systems and older compilers.
 For the FSF tree, it would be nice to have that.  You can know this is true by
configuring --build=x86_64-apple-darwin on a Leopard box (where gcc defaults to
32-bit) and running file on gcc/expr.o.  If it is 32-bit, it is wrong.

darwin10 supports and runs on 32-bit only processors.  In that case, x86_64
isn't the default code-gen, contrary to your statement in #22.

It is improper to test target in #20, as target has no influence. 
--host=i386-apple-darwin --target=arm-elf implies -m32.  Build one, then run
file gcc/expr.o.  If that file is 64-bit, it is wrong.

The changes to configure.ac are independent of config.guess, so your assertion
that the changes are only appropriate after config.guess is accepted, is wrong.
 You can see this by configure --build=i386-apple-darwin10 and running file
gcc/expr.o and noticing it is wrong currently on SL.  It is says 64-bit, it is
wrong.

For the comment in #24, no, that isn't its only purpose.  The purpose of it
would be to allow one to configure --host=i386-apple-darwin10
--build=i386-apple-darwin10, and have gcc do what it is told to do, which is to
generate 32-bit binaries.

Now, all that aside, you only need to change the patches I suggested, if there
is an error in them.  You've not identified one error, therefore you don't need
to change them.  If you want to change them, please explain the error.

Lastly, tentative_cc won't work as well as setting CC.  My comment in #15 is
wrong, CC must be used.

As for the libraries.  You have to build them appropriately, and give to gcc,
the appropriate libs.  I build them universal, so what I give gcc is trivially,
always good.  If you build just one architecture, you have to build the
libraries with the same 32/64-bitness as you want to build the compiler.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #30 from mrs at apple dot com  2009-09-04 01:49 ---
I admit that having gcc automagically add -m32 isn't strictly needed, the user
can do that.  The problem is when they don't do that.  What behavior do we
want?  We can pick:

  1)  Just work.
  2)  Fail immediately, telling them they did it wrong.
  3)  Grind away for hours, just to fail in some obscure hard to understand way

Status quo is #3.  Now, we have the choice to do this, or to do 1.  Argue
against 1; it is import to fail in some obscure way because...  I have never
see a compelling argument.  I did the change up as I was supporting users that
grew tied of it failing all the time.  I grew tied of it failing all the time. 
For me, it's an easy choice.  The cost of the few lines is well worth the
benefit to me.


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2009-09-22 18:56 ---
I wonder if we could just trim out the symbols from libgcc that are in
libSystem, and arrange for gcc's installed libgcc to be found first. 
Advantage, simplicity, less target specific work, easy to understand. 
Downside, OS upgrades require recompiling the world, to the extent there are
new symbols in libgcc that are then added to libSystem in later OS releases. 
ld has magic in it that can appear and disappear symbols from a dylib depending
upon which OS is targeted.  Target old OSes, all the usual symbols are there,
target newer OSes, large swaths disappear (but are found anyway in libSystem).

Also, all this fun stuff it relevant to darwin10 and later only (not darwin9). 
I'm not a fan of yet more compile flags in general.  I'd rather have a nice
design that covers the bases, that doesn't really need yet more flags.

The hiding trick goes something like:

#define NOT_HERE_BEFORE_10_6(sym) \
extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
__attribute__((visibility("default"))) const char sym##_tmp3 = 0; \


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

--- Comment #8 from mrs at apple dot com  2009-09-22 21:17 ---
I meant the idea that libSystem has new symbols in it is relevant only to
darwin10.  The system libgcc_s is present on older OSes, so those aspects are
still relevant.  Yeah, to solve that problem one would either have to have a
new name, or possibly an explicit path.  I've not tried the later, but it might
offer a way to construct the library with fewer mods.

from darwin10:
$ nm /usr/lib/libgcc_s.1.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace
$ nm /usr/lib/libSystem.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace

also note, there is add as well as hide;

$ nm /usr/lib/libgcc_s.10.5.dylib | grep Unwind_Back
0f0a S $ld$add$os10.4$__Unwind_Backtrace
0f0b S $ld$add$os10.5$__Unwind_Backtrace

As for what functions (symbols), well, the ones in common between
libSystem/libgcc_s on the system and libgcc from gcc.


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

--- Comment #19 from mrs at apple dot com  2009-09-23 20:43 ---
Subject: Re:  TLS emutls not linked to automatically on Darwin

On Sep 22, 2009, at 8:02 PM, howarth at nitro dot med dot uc dot edu  
wrote:
> Doesn't this imply that you can't make force libgcc to be found before
> libSystem under SL?

No.


-- 


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