[Bug target/27542] [4.2 Regression] the ms_struct pragma is not documented
--- Comment #1 from echristo at apple dot com 2006-06-04 19:02 --- Not sure it qualifies as a regression, but I'll take it. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 19:02:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
--- Comment #1 from echristo at apple dot com 2006-06-04 19:03 --- ditto on the regression, i'll take it anyhow. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 19:03:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #2 from echristo at apple dot com 2006-06-08 00:10 --- Since you're using the MS abi then for sh64 you'll need to dig up where I'm doing something wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #1 from echristo at apple dot com 2006-06-08 18:11 --- Can you get me the size of that structure according to MS VC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #4 from echristo at apple dot com 2006-06-08 18:14 --- Well, I suppose the question is whether or not I'm doing something wrong here. The alignment should be added unilaterally (as far as I can tell from the documents that I included in the documentation). Part of the question is what happens with the packed attribute? I've not seen any part of an abi document that includes that. I'm perfectly willing to include your patch in - it shouldn't affect anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug preprocessor/8270] [4.0/4.1/4.2 Regression] back-slash white space newline with comments, no warning
--- Comment #35 from echristo at apple dot com 2006-06-08 21:06 --- I'm unlikely to work on this... -- echristo at apple dot com changed: What|Removed |Added AssignedTo|echristo at apple dot com |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug target/27542] [4.2 Regression] the ms_struct pragma is not documented
--- Comment #2 from echristo at apple dot com 2006-06-08 21:40 --- Submitted patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #6 from echristo at apple dot com 2006-06-08 22:23 --- Sure. Sounds good. As I said, the ABI stuff I've seen (and helped write) don't take packed into account anywhere :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #3 from echristo at apple dot com 2006-06-08 22:39 --- Verified. Investigating. The alignment should be 8 from what I can see: a -> 1st byte int :0 -> align to 4th byte b -> 5th byte c -> 6th byte align structure to 8th byte because of int :0. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 22:39:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #5 from echristo at apple dot com 2006-06-08 23:57 --- FWIW btw, the edge case only occurs when the bitfield is the full length of the array size. Guh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #6 from echristo at apple dot com 2006-06-09 00:00 --- Think I've got a patch. testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #7 from echristo at apple dot com 2006-06-09 01:12 --- Confirmed. Patch appears to work. I'll submit it a bit later. Short, one liner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug target/27542] [4.2 Regression] the ms_struct pragma is not documented
--- Comment #4 from echristo at apple dot com 2006-06-12 06:45 --- 2006-06-11 Eric Christopher <[EMAIL PROTECTED]> PR 27542 * doc/extend.texi (Structure-Packing Pragmas): Document ms_struct pragma. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #9 from echristo at apple dot com 2006-06-12 06:54 --- 2006-06-11 Eric Christopher <[EMAIL PROTECTED]> PR middle-end/27948 * stor-layout.c (place_field): Remove check for remaining_in_alignment when aligning at the end of a run. 2006-06-11 Eric Christopher <[EMAIL PROTECTED]> PR middle-end/27948 * gcc.dg/bf-ms-layout.c: Run on darwin. * gcc.dg/bf-no-ms-layout: Ditto. * gcc.dg/attr-ms_struct-2.c: New. * gcc.dg/bf-ms-layout-2.c: Ditto. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug libgomp/28296] libgomp fails to configure on Tru64 UNIX
--- Comment #2 from echristo at apple dot com 2006-07-08 01:04 --- Well, it shouldn't have mattered, but try re-adding the CFLAGS line that I think I accidentally deleted just after XPCFLAGS: CFLAGS="$CFLAGS -pthread" which is also just plain wrong, but perhaps this too should be moved inside the case block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug libgomp/28296] libgomp fails to configure on Tru64 UNIX
--- Comment #3 from echristo at apple dot com 2006-07-08 01:11 --- Oh yes, FWIW it worked on both x86-darwin and x86-linux which are the only platforms I can test :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug target/27543] attribute ms_struct is now also for rs6000 but not documented
--- Comment #2 from echristo at apple dot com 2006-07-10 21:01 --- Removing regression. -- echristo at apple dot com changed: What|Removed |Added Summary|[4.2 Regression] attribute |attribute ms_struct is now |ms_struct is now also for |also for rs6000 but not |rs6000 but not documented |documented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #5 from echristo at apple dot com 2006-07-10 21:03 --- Well, the original place isn't correct because -pthread isn't valid for all platforms, but it could be moved to where I have XPCFLAGS for non-darwin targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #6 from echristo at apple dot com 2006-07-17 08:52 --- Rainer, did you want to check building with the cflags inside the case statement? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug target/24323] _MM_TRANSPOSE4_PS could be improved
--- Comment #2 from echristo at apple dot com 2005-11-30 06:29 --- Patch committed. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24323
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #1 from echristo at apple dot com 2006-01-12 22:25 --- I'm testing it for Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug target/26877] configure switches --with-arch and --with-tune are broken on x86
--- Comment #1 from echristo at apple dot com 2006-07-19 21:59 --- I'll take this since I've submitted a patch. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-19 21:59:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
[Bug target/26877] configure switches --with-arch and --with-tune are broken on x86
--- Comment #3 from echristo at apple dot com 2006-07-20 07:40 --- Fixed thusly: 2006-07-20 Eric Christopher <[EMAIL PROTECTED]> PR target/26877 * config/i386/i386.h (OPTION_DEFAULT_SPECS): Reorder. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*
--- Comment #12 from echristo at apple dot com 2006-07-22 21:00 --- This looks fixed to me. -- echristo at apple dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #8 from echristo at apple dot com 2006-07-22 21:06 --- I believe a patch to libstdc++ to check for __Unwind_GetIPInfo was committed. Verify this still fails? -- echristo at apple dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #11 from echristo at apple dot com 2006-07-22 21:12 --- Waiting on Edmar's feedback for Alan's patch. -- echristo at apple dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #7 from echristo at apple dot com 2006-07-22 21:14 --- Jim, were you going to check this in or did you need some more testing on it? -- echristo at apple dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- Comment #6 from echristo at apple dot com 2006-07-22 21:16 --- Waiting on David's feedback. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
[Bug target/27543] attribute ms_struct is now also for rs6000 but not documented
--- Comment #3 from echristo at apple dot com 2006-07-23 20:28 --- Patch submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Comment #28 from echristo at apple dot com 2006-07-23 20:30 --- We're not going to support building 4.0 in the source directory. Closing. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug target/27681] [4.1 regression] Missing DImode float conversion functions with -msoft-float
--- Comment #4 from echristo at apple dot com 2006-07-24 03:20 --- I doubt we're going to backport that patch to 4.1 at all, should we just close this bug? -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug target/27303] crash at unalign access
--- Comment #9 from echristo at apple dot com 2006-07-24 03:22 --- No testcase after 3 mos. No need to keep this open. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*
--- Comment #14 from echristo at apple dot com 2006-07-24 04:54 --- The bug says c++, feel like opening another one or fixing the title on the bug you opened? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/27544] [4.0/4.1/4.2 Regression] attribute altivec is not documented
--- Comment #1 from echristo at apple dot com 2006-07-24 05:07 --- This can't possibly be a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug middle-end/23868] [4.1/4.2 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #8 from echristo at apple dot com 2006-07-24 05:45 --- Is this a problem with mainline? It has 4.2 regression marked on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers
--- Comment #11 from echristo at apple dot com 2006-07-24 05:51 --- Is libssp even assumed to be OK for non-native targets? I think that it should probably be turned off by default on the embedded targets and just left that way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
--- Comment #6 from echristo at apple dot com 2006-07-30 20:50 --- Fixed thusly: 2006-07-30 Eric Christopher <[EMAIL PROTECTED]> PR target/27543 * doc/extend.texi (i386 Variable Attributes): Add anchor. (PowerPC Variable Attributes): New section. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug c++/21308] [4.0 Regression] Very high compile time
--- Comment #16 from echristo at apple dot com 2006-08-26 00:10 --- Should this be closed as "unlikely to fix in 4.0"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug bootstrap/26999] [4.2 Regression] bootstrap failure with --disable-libdecnumber or --disable-libcpp
--- Comment #5 from echristo at apple dot com 2006-08-26 01:15 --- patch in testing -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-04 01:01:42 |2006-08-26 01:15:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
[Bug bootstrap/26999] [4.2 Regression] bootstrap failure with --disable-libdecnumber or --disable-libcpp
--- Comment #6 from echristo at apple dot com 2006-08-26 06:37 --- Patch submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
[Bug bootstrap/26999] [4.2 Regression] bootstrap failure with --disable-libdecnumber or --disable-libcpp
--- Comment #7 from echristo at apple dot com 2006-08-31 22:14 --- After discussion with DJ I'm going to mark this as WONTFIX. We'll just allow people to shoot themselves in the foot if they try to disable a directory that they shouldn't. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #2 from echristo at apple dot com 2006-09-09 08:12 --- Yup. A new cctools is needed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
-- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-09 04:22:58 |2006-09-09 08:40:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #3 from echristo at apple dot com 2006-09-09 08:53 --- FWIW I just hacked up a quick autoconf test for the feature as well if we'd prefer to have that as well... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #4 from echristo at apple dot com 2006-09-09 08:54 --- Created an attachment (id=12212) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12212&action=view) autoconf test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #7 from echristo at apple dot com 2006-09-09 18:57 --- You run autoheader and autoconf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #9 from echristo at apple dot com 2006-09-09 19:51 --- Yeah, might be better off just bracketing the literal16 code in darwin.c with #ifdef HAVE_GAS_LITERAL16. Want to do that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #11 from echristo at apple dot com 2006-09-09 20:09 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #13 from echristo at apple dot com 2006-09-09 21:27 --- Close, but I'd prefer to actually have the test for true as well in there. I'll go ahead and submit the patch similar. thanks for testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #15 from echristo at apple dot com 2006-09-10 07:11 --- So, just committed a patch for the 32-bit problems with literal16 sections. (No, they won't be valid for 32-bit.) I'm holding on the configure patch since 2.4 seems to work fine with the patch for people and I find it reasonable to assume that people will download that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug testsuite/28950] regex wrong for gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #1 from echristo at apple dot com 2006-09-10 07:18 --- But wouldn't that change make it fail on platforms that don't want an "r"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #16 from echristo at apple dot com 2006-09-10 07:48 --- I believe this is fixed with the above change. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
--- Comment #1 from echristo at apple dot com 2006-09-21 17:52 --- Yes, this should pass. -- echristo at apple dot com changed: What|Removed |Added CC|echristo at gcc dot gnu dot | |org | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-21 17:52:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #7 from echristo at apple dot com 2006-10-11 18:14 --- I'm testing it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #8 from echristo at apple dot com 2006-10-11 18:24 --- OK. Seems to be working (i.e. build succeeded and testing isn't blowing up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #10 from echristo at apple dot com 2006-10-11 19:34 --- Testing on darwin, the patch seems to get rid of the massive failures I was seeing. Thanks Ben. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug fortran/29516] Bug in character transpose
--- Comment #2 from echristo at apple dot com 2006-10-19 22:24 --- I'll take a look at this. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-19 22:16:23 |2006-10-19 22:24:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #6 from echristo at apple dot com 2007-04-05 23:56 --- Actually, I'll go ahead and take this, it was reported internally as well here and I've got a patch in testing :) -- echristo at apple dot com changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |echristo at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #11 from echristo at apple dot com 2007-04-06 20:31 --- Jan, Yeah, that's exactly the patch I had when it finishes testing ok (it did for me on i386), would you please commit it to the 4.2 branch as well? -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #13 from echristo at apple dot com 2007-04-10 01:57 --- Any hope of getting this in 4.2 as well? It's not a regression, but is a fairly longstanding bug that's easier to trip than we'd like. -- echristo at apple dot com changed: What|Removed |Added CC||mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #3 from echristo at apple dot com 2007-04-18 18:44 --- As a note, this is due to the make install bit of libgcc when putting things back into the gcc build dir we set $(slibdir) to null and then the darwin install name ends up being set to $(slibdir)/libgcc_s.1.dylib which ends up being /libgcc_s.1.dylib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
--- Comment #6 from echristo at apple dot com 2007-08-10 02:29 --- I hadn't but I have now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #6 from echristo at apple dot com 2007-08-20 17:11 --- No, I spoke to Daniel about it a while back, but he hasn't had time to look into it. It's definitely caused by the toplevel changes to libgcc. The basic idea is that the toplevel makefile re-installs libgcc into the gcc directory for some reason causing a relink of libgcc and since the is null the installed libgcc gets an install name of /libgcc_s.1.dylib. This is then used with libstdc++. When it's installed it is _again_ relinked and then has the proper install_name, but this won't fix the problem that libstdc++ has since it's already been linked in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug gcov-profile/31810] New: gcov returns wrong results
#include
// this global string causes gcov to think there's executable lines
// beyond the end of the file, and that they have not been executed
std::string globalVar = "";
std::string
doSomething()
{
// instantiating this string and calling a method on it causes the
// 'return' line to be marked as having never been executed
std::string localVar;
localVar.size();
return localVar;
}
int
main(int, char **)
{
doSomething();
return 0;
}
produces the wrong results:
a) it says that the return is never called
b) it executes past the end of the file
--
Summary: gcov returns wrong results
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: echristo at apple dot com
GCC build triplet: i386-apple-darwin
GCC host triplet: i386-apple-darwin
GCC target triplet: i386-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31810
[Bug gcov-profile/31810] gcov returns wrong results
-- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-04 02:32:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31810
[Bug gcov-profile/31810] gcov returns wrong results
--- Comment #2 from echristo at apple dot com 2007-05-04 02:38 --- Yeah, probably. Bah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31810
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #4 from echristo at apple dot com 2007-06-13 06:36 --- Patch looks reasonable. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #7 from echristo at apple dot com 2007-06-13 22:16 --- Um. Right. :) The new version is fine if it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #16 from echristo at apple dot com 2007-06-29 19:00 --- No, we shouldn't close it until we can get the compiler building on ppc with -mdynamic-no-pic. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug preprocessor/24531] preprocessor eats whitespace at end of line
--- Comment #5 from echristo at apple dot com 2005-10-25 21:58 --- To clarify this a bit more: http://gcc.gnu.org/ml/gcc/2005-10/msg00819.html Is Howard Hinnant's comment on the subject and the thread that started this. There's a space at the end of the line that the has the comment. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|echristo at gcc dot gnu dot |echristo at apple dot com |org | Last reconfirmed|2005-10-25 21:51:58 |2005-10-25 21:58:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
[Bug preprocessor/24531] preprocessor eats whitespace at end of line
--- Comment #6 from echristo at apple dot com 2005-10-25 21:59 --- Andrew will stop closing this bug. -- echristo at apple dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
[Bug preprocessor/24531] preprocessor eats whitespace at end of line
-- echristo at apple dot com changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2005-10-25 21:58:42 |2005-10-25 21:59:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
[Bug preprocessor/24531] preprocessor eats whitespace at end of line
--- Comment #9 from echristo at apple dot com 2005-10-25 22:03 --- Reopening. -- echristo at apple dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
[Bug preprocessor/24531] preprocessor eats whitespace at end of line
-- echristo at apple dot com changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2005-10-25 21:59:22 |2005-10-25 22:03:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24531
[Bug preprocessor/8270] back-slash newline extension can't be removed
--- Comment #9 from echristo at apple dot com 2005-10-26 00:24 --- reopening -- echristo at apple dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] back-slash newline extension can't be removed
-- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|-00-00 00:00:00 |2005-10-26 00:25:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] back-slash newline extension can't be removed
--- Comment #10 from echristo at apple dot com 2005-10-26 00:26 ---
int main (int argc, char * const argv[]) {
// |_||__\
if (1)
{
printf("Hello");
}
else
{
printf("There");
}
return 0;
}
Note that there's a space after the comment above.
To clarify this a bit more:
http://gcc.gnu.org/ml/gcc/2005-10/msg00819.html
Is Howard Hinnant's comment on the subject and the thread that started this.
There's a space at the end of the line that the has the comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #30 from echristo at apple dot com 2005-10-26 21:46 --- That would be the consensus from Andrew, not from people concerned that deal with language issues routinely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug middle-end/24514] ICE on bootstrap
--- Comment #2 from echristo at apple dot com 2005-10-31 18:17 --- Since I don't have access to an irix box anymore I'd really need the instruction it fails on at the least, some annotated assembly would be a good start (compile the failing file with -dap and attach the .s output). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] ICE on bootstrap
--- Comment #5 from echristo at apple dot com 2005-11-01 17:27 --- The patch to 23585 is likely the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #7 from echristo at apple dot com 2005-11-01 17:43 --- Changing to P1 since it's a regression that likely affects all mips (including primary platform mips-elf). -- echristo at apple dot com changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #9 from echristo at apple dot com 2005-11-01 18:06 --- Bringing down to P3 and letting Mark set the priority. -- echristo at apple dot com changed: What|Removed |Added CC||mark at codesourcery dot com Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #21 from echristo at apple dot com 2010-02-16 18:01 --- I remember that we originally ran into this warning in a huge number of places building OSX. Now I'd agree that null checking would be something good to have, but there should be some way to turn it off if it's on by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #23 from echristo at apple dot com 2010-02-16 18:09 --- That looks fine to me, though you'll probably want to use "null" instead of null in the command line option. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug target/36399] ABI bug on darwin/x86-32
--- Comment #8 from echristo at apple dot com 2009-12-29 22:21 --- That patch looks correct for at least x86-32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #9 from echristo at apple dot com 2007-11-01 17:09 --- I guess that would be a good workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #17 from echristo at apple dot com 2007-12-17 23:25 --- I rather like this patch... someone should ping Paolo about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug middle-end/34739] New: Need full backport of 28796
Found a testcase that ice's the ppc-darwin backend at -O3 -ffast-math that is
fixed by the full backport of the patches in 28796. In particular, this part:
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001
Log:
2006-10-24 Richard Guenther <[EMAIL PROTECTED]>
PR middle-end/28796
* builtins.c (fold_builtin_classify): Use HONOR_INFINITIES
and HONOR_NANS instead of MODE_HAS_INFINITIES and MODE_HAS_NANS
for deciding optimizations in consistency with fold-const.c
(fold_builtin_unordered_cmp): Likewise.
* gcc.dg/pr28796-1.c: New testcase.
* gcc.dg/pr28796-1.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/pr28796-1.c
trunk/gcc/testsuite/gcc.dg/pr28796-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
Testcase:
#include
int test2(double x, double y) {
return islessgreater(x, y);
}
--
Summary: Need full backport of 28796
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: echristo at apple dot com
GCC build triplet: powerpc-darwin9
GCC host triplet: powerpc-darwin9
GCC target triplet: powerpc-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] Need full backport of 28796
--- Comment #2 from echristo at apple dot com 2008-01-11 11:19 --- Doesn't ice under 4.0 so it is a regression. -- echristo at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] Need full backport of 28796
--- Comment #4 from echristo at apple dot com 2008-01-11 11:26 --- It's in the bug and I have assignment issues currently and he asked me to? -- echristo at apple dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-01-11 11:26:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] Need full backport of 28796
--- Comment #7 from echristo at apple dot com 2008-01-11 11:48 --- Created an attachment (id=14923) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14923&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #2 from echristo at apple dot com 2008-06-03 00:37 --- Confirmed. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 00:37:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #11 from echristo at apple dot com 2006-02-27 08:35 --- There are two ways to fix this, the easiest way is to pass -allow_stack_execute through to the linker when we want an executable stack. This is problematic since we'll not be specifying it on the command line. We can turn on an allowable stack at all times, but this is less safe than turning it on only when necessary. The other way is to use mprotect like the patch has below. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-21 20:49:38 |2006-02-27 08:35:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #13 from echristo at apple dot com 2006-02-28 01:48 --- Patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug bootstrap/26523] Can't bootstrap gcc 4.1.0 (SVN revision : 111569) at FreeBSD 6.0rc1
--- Comment #5 from echristo at apple dot com 2006-03-01 22:04 --- Confirmed. That's the error message if you use the configure from the gcc subdir. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26523
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #14 from echristo at apple dot com 2006-03-03 20:17 --- Fixed. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #26 from echristo at apple dot com 2006-03-09 03:13 --- GOFAST was a library shipped for mips that I added a configure option to continue to allow to compile. I fully doubt that it's in use anywhere now so can probably be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug target/29302] isfinite returns wrong result at -O1
--- Comment #26 from echristo at apple dot com 2006-11-08 00:06 --- I'll take this one since I've got the apple radar on it as well, removing Geoff. -- echristo at apple dot com changed: What|Removed |Added CC|geoffk at gcc dot gnu dot | |org | AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-05 08:20:07 |2006-11-08 00:06:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #4 from echristo at apple dot com 2006-11-09 23:49 --- I'm going to mark this down as wontfix since I just added a port for ppc64-darwin and we don't need the file since the issue that caused host-darwin.c in the rs6000 backend to be created was fixed with tiger. -- echristo at apple dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #5 from echristo at apple dot com 2006-11-09 23:51 --- This appears to work with the change to add powerpc64-darwin support. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
