[Bug middle-end/28160] Bogus size of array 'foo' is too large error with -mms-bitfields
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-07-15 06:59 --- Subject: Bug 28160 Author: kkojima Date: Sat Jul 15 06:58:57 2006 New Revision: 115464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115464 Log: PR middle-end/28160 * stor-layout.c (place_field): Take the bit field with an excessive size into account in the ms-bitfiled case. PR middle-end/28161 * stor-layout.c (place_field): Use DECL_BIT_FIELD_TYPE of the previous bit field. Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #7 from kkojima at gcc dot gnu dot org 2006-07-15 06:59 --- Subject: Bug 28161 Author: kkojima Date: Sat Jul 15 06:58:57 2006 New Revision: 115464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115464 Log: PR middle-end/28160 * stor-layout.c (place_field): Take the bit field with an excessive size into account in the ms-bitfiled case. PR middle-end/28161 * stor-layout.c (place_field): Use DECL_BIT_FIELD_TYPE of the previous bit field. Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug c++/28387] [4.2 regression] ICE with attribute on invalid declaration
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-15 09:22 --- Subject: Bug 28387 Author: reichelt Date: Sat Jul 15 09:22:17 2006 New Revision: 115465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115465 Log: PR c++/28387 * decl2.c (cplus_decl_attributes): Check for invalid decls. * g++.dg/ext/attrib24.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/attrib24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28387
[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-15 09:29 --- Subject: Bug 28294 Author: reichelt Date: Sat Jul 15 09:29:32 2006 New Revision: 115466 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115466 Log: PR c++/28294 * semantics.c (finish_offsetof): Use TREE_OPERAND for COMPONENT_REFs only. * g++.dg/ext/offsetof1.C: Add test with function pointer arithmetic. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-15 09:34 --- Subject: Bug 28294 Author: reichelt Date: Sat Jul 15 09:34:27 2006 New Revision: 115467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115467 Log: PR c++/28294 * semantics.c (finish_offsetof): Use TREE_OPERAND for COMPONENT_REFs only. * g++.dg/ext/offsetof1.C: Add test with function pointer arithmetic. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-15 09:38 --- Subject: Bug 28294 Author: reichelt Date: Sat Jul 15 09:38:02 2006 New Revision: 115468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115468 Log: PR c++/28294 * semantics.c (finish_offsetof): Use TREE_OPERAND for COMPONENT_REFs only. * g++.dg/ext/offsetof1.C: Add test with function pointer arithmetic. Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/semantics.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug c++/28249] [4.0/4.1/4.2 regression] long long long accepted by catch
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-15 09:44 --- Subject: Bug 28249 Author: reichelt Date: Sat Jul 15 09:44:36 2006 New Revision: 115469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115469 Log: PR c++/28249 * parser.c (cp_parser_check_decl_spec): New function. (cp_parser_decl_specifier_seq): Factor out check for repeated decl-specifiers into cp_parser_check_decl_spec. Use it. (cp_parser_type_specifier_seq) Use it. * g++.dg/parse/catch1.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/catch1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28249
[Bug c++/28249] [4.0/4.1/4.2 regression] long long long accepted by catch
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-15 09:54 --- Subject: Bug 28249 Author: reichelt Date: Sat Jul 15 09:54:25 2006 New Revision: 115470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115470 Log: PR c++/28249 * parser.c (cp_parser_check_decl_spec): New function. (cp_parser_decl_specifier_seq): Factor out check for repeated decl-specifiers into cp_parser_check_decl_spec. Use it. (cp_parser_type_specifier_seq): Use it. * g++.dg/parse/catch1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/catch1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28249
[Bug c++/28249] [4.0/4.1/4.2 regression] long long long accepted by catch
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-15 09:58 --- Subject: Bug 28249 Author: reichelt Date: Sat Jul 15 09:58:47 2006 New Revision: 115471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115471 Log: PR c++/28249 * parser.c (cp_parser_check_decl_spec): New function. (cp_parser_decl_specifier_seq): Factor out check for repeated decl-specifiers into cp_parser_check_decl_spec. Use it. (cp_parser_type_specifier_seq): Use it. * g++.dg/parse/catch1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/catch1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28249
[Bug c++/28387] [4.2 regression] ICE with attribute on invalid declaration
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-15 10:08 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28387
[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-15 10:08 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug c++/28249] [4.0/4.1/4.2 regression] long long long accepted by catch
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-07-15 10:10 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28249
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #9 from tbm at cyrius dot com 2006-07-15 10:18 ---
(In reply to comment #6)
Could I get clarification if the following error is a desired effect of this
change. Prior to this, the included program gave no error. I believe the
change was caused by this patch.
e.c:1: error: previous declaration of 'int i' with 'C++' linkage
e.c:4: error: conflicts with new declaration with 'C' linkage
[hpclear8] $ cat e.c
extern int i;
extern C {
extern int i;
}
So apparently this is invalid code. However, I feel very strongly that a point
release of GCC should *not* introduce a new error - Mark, please modify the
patch applied to the 4.1 branch in a way to allow this code.
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-15 10:27 --- (In reply to comment #9) So apparently this is invalid code. However, I feel very strongly that a point release of GCC should *not* introduce a new error - Mark, please modify the patch applied to the 4.1 branch in a way to allow this code. Why? It is better to reject invalid code even than keeping backwards compatiblity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #95 from jakub at redhat dot com 2006-07-15 10:34 --- Can this be revisited now? namespaces now can have the visibility attribute, although it has to be present on each opening namespace. Guess sticking __attribute__((__visibility__(default))) into _GLIBCXX_BEGIN_NAMESPACE and similar macros could do the trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-15 10:41 --- Hmm, actually the defect report about the code in comment #6 is still active so I agree that we should not reject it on the release branch. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#563 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #12 from tbm at cyrius dot com 2006-07-15 10:42 --- (In reply to comment #10) Why? It is better to reject invalid code even than keeping backwards compatiblity. No, it's not - not in a minor point release. Users expect that a minor point release is backwards compatible. Upgrading from 4.1.1 to 4.1.2 should be painless, i.e. fix bugs only. But now we suddenly have 13 package build failures in Debian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/28389] New: [DR 563] linkage and variables
Testcase: extern int i; extern C int i; http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#563 is still active. We currently reject this on the 4.1 branch and the mainline but that is because of the patch for PR 27227. -- Summary: [DR 563] linkage and variables Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28389
[Bug c++/28389] [DR 563] linkage and variables
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-15 10:43:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28389
[Bug c++/28389] [DR 563] linkage and variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-15 10:43 --- Suspending until the Defect report is really closed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28389
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-15 10:48 --- (In reply to comment #12) Upgrading from 4.1.1 to 4.1.2 should be painless, i.e. fix bugs only. But now we suddenly have 13 package build failures in Debian. It is a bug fix, just not what normal people think about bug fix. If there was not a defect report still open about this case, I actually would say this was a bug fix but this one is a bit weird as the defect report was not resolved yet. I have a feeling Mark should not have changed the behavior until it was resolved as there was no comments on the defect report either. Anyways I filed PR 28389 about the defect report so that people know that the standard is ambiguous and that maybe we can get the behavior back to the orginal -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern C
--- Comment #14 from tbm at cyrius dot com 2006-07-15 10:58 --- (In reply to comment #13) Upgrading from 4.1.1 to 4.1.2 should be painless, i.e. fix bugs only. But now we suddenly have 13 package build failures in Debian. It is a bug fix, just not what normal people think about bug fix. That's right. Not what normal people, i.e. users of GCC, see as a bug fix. If code is invalid but it works, please leave it alone in a stable point release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug rtl-optimization/28386] [4.1 regression] Wrong code with if condition in loop
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-15 11:40 --- This is going wrong in RTL land. Tree optimization looks ok - we're merging the two IVs and using a wrapping unsigned IV going from 0xff81 to 127: bb 0: ivtmp.33D.1833 = 0ff81; jD.1769 = 0; L0:; if (ivtmp.33D.1833 = 127) goto L1; else goto L2; L1:; D.1775 = (intD.0) ivtmp.33D.1833; D.1776 = sD.1765[D.1775][0]; printf (%d [0], (intD.0) D.1776); jD.1769 = jD.1769 + 1; L2:; ivtmp.33D.1833 = ivtmp.33D.1833 + 1; if (ivtmp.33D.1833 != 128) goto L0; else goto L4; L4:; printf (\nj = %d\n[0], jD.1769); return 0; of course, it's the particular choice of IVs that triggers the bug later on. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28386
[Bug rtl-optimization/28386] [4.1 regression] Wrong code with if condition in loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-15 11:54 --- Goes away with -floop-optimize2. *sigh* -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28386
[Bug fortran/28384] ICE on non-existent COMMON block
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-07-15 13:40 ---
Index: gcc/fortran/trans-common.c
===
*** gcc/fortran/trans-common.c (revision 115409)
--- gcc/fortran/trans-common.c (working copy)
*** translate_common (gfc_common_head *commo
*** 962,967
--- 962,974
current_offset += s-length;
}
+ if (common_segment == NULL)
+ {
+ gfc_error (COMMON '%s' at %L does not exist,
+common-name, common-where);
+ return;
+ }
+
if (common_segment-offset != 0)
{
gfc_warning (COMMON '%s' at %L requires %d bytes of padding at
start,
Yes, please go ahead. Obvious, really :-)
Thomas
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-07-15 13:40:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28384
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #2 from ams at gnu dot org 2006-07-15 13:45 ---
Created an attachment (id=11892)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11892action=view)
Fixes #28102
(In reply to comment #1)
Why is GNU target including linux.h header at all?
TARGET_C99_FUNCTIONS should be overridden in gnu.h anyways.
Because the rules in config.gcc say so:
*-*-gnu*)
...
i[34567]86-*-*)
tm_file=${cpu_type}/${cpu_type}.h i386/unix.h i386/att.h dbxelf.h
elfos.\
h svr4.h linux.h i386/linux.h gnu.h ${tm_file}
...
Here is a patch that fixes the problem.
gcc/ChangeLog
2006-07-15 Alfred M. Szmidt [EMAIL PROTECTED]
* config/i386/gnu.h (TARGET_C99_FUNCTIONS): Undefine macro.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug c++/28292] [4.2 regression] ICE in acceptable_java_type
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-15 14:45 --- Subject: Bug 28292 Author: lmillward Date: Sat Jul 15 14:44:48 2006 New Revision: 115474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115474 Log: PR c++/28292 * decl2.c (acceptable_java_type): Robustify. Use proper Boolean return type instead of return 1. (check_java_method): Don't issue error about type not being an acceptable Java parameter if it's error_mark_node. * g++.dg/other/error12.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/error12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28292
[Bug c++/28292] [4.2 regression] ICE in acceptable_java_type
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-07-15 14:46 --- Fixed. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28292
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 15, 2006, at 10:45 PM, ams at gnu dot org wrote: Because the rules in config.gcc say so: And that is not why, but that is what is causing linux.h being included? Again why is Linux.h being included? -- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #3 from pinskia at gmail dot com 2006-07-15 14:56 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 15, 2006, at 10:45 PM, ams at gnu dot org wrote: Because the rules in config.gcc say so: And that is not why, but that is what is causing linux.h being included? Again why is Linux.h being included? -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug c++/28269] [4.2 regression] ICE on attribute for invalid template
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-15 15:00 --- Subject: Bug 28269 Author: lmillward Date: Sat Jul 15 15:00:28 2006 New Revision: 115475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115475 Log: PR c++/28269 * parser.c (cp_parser_elaborated_type_specifier): Return early if an invalid type was detected. * g++.dg/template/crash54.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash54.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28269
[Bug c++/28269] [4.2 regression] ICE on attribute for invalid template
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-07-15 15:01 --- Fixed. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28269
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #4 from ams at gnu dot org 2006-07-15 15:17 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Because the rules in config.gcc say so: And that is not why, but that is what is causing linux.h being included? Again why is Linux.h being included? GNU and GNU/Linux are similar enough not to warrant duplication of the code from linux.h in gnu.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 12:17 AM, ams at gnu dot org wrote:
GNU and GNU/Linux are similar enough not to warrant duplication of the
code from linux.h in gnu.h.
Depends, the duplication is small anyways as linux.h is only 129 lines
(including copyright and comments).
In fact it is way wrong now anyways as there is no uclibc for hurd.
So the duplication factor should not matter as there is hardly any
duplication.
Only the following code will be duplicated which is hardly any after
all:
/* Don't assume anything about the header files. */
#define NO_IMPLICIT_EXTERN_C
#undef ASM_APP_ON
#define ASM_APP_ON #APP\n
#undef ASM_APP_OFF
#define ASM_APP_OFF #NO_APP\n
#undef MD_EXEC_PREFIX
#undef MD_STARTFILE_PREFIX
#undef STARTFILE_SPEC
#if defined HAVE_LD_PIE
#define STARTFILE_SPEC \
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}
#else
#define STARTFILE_SPEC \
%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}
#endif
#undef ENDFILE_SPEC
#define ENDFILE_SPEC \
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
#ifndef CC1_SPEC
#define CC1_SPEC %{profile:-p}
#endif
#undef CPLUSPLUS_CPP_SPEC
#define CPLUSPLUS_CPP_SPEC -D_GNU_SOURCE %(cpp)
#if defined(HAVE_LD_EH_FRAME_HDR)
#define LINK_EH_SPEC %{!static:--eh-frame-hdr}
#endif
/* Define this so we can compile MS code for use with WINE. */
#define HANDLE_PRAGMA_PACK_PUSH_POP
#define LINK_GCC_C_SEQUENCE_SPEC \
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
/* Use --as-needed -lgcc_s for eh support. */
#ifdef HAVE_LD_AS_NEEDED
#define USE_LD_AS_NEEDED 1
#endif
#define TARGET_POSIX_IO
-- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #5 from pinskia at physics dot uc dot edu 2006-07-15 15:27
---
Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
On Jul 16, 2006, at 12:17 AM, ams at gnu dot org wrote:
GNU and GNU/Linux are similar enough not to warrant duplication of the
code from linux.h in gnu.h.
Depends, the duplication is small anyways as linux.h is only 129 lines
(including copyright and comments).
In fact it is way wrong now anyways as there is no uclibc for hurd.
So the duplication factor should not matter as there is hardly any
duplication.
Only the following code will be duplicated which is hardly any after
all:
/* Don't assume anything about the header files. */
#define NO_IMPLICIT_EXTERN_C
#undef ASM_APP_ON
#define ASM_APP_ON #APP\n
#undef ASM_APP_OFF
#define ASM_APP_OFF #NO_APP\n
#undef MD_EXEC_PREFIX
#undef MD_STARTFILE_PREFIX
#undef STARTFILE_SPEC
#if defined HAVE_LD_PIE
#define STARTFILE_SPEC \
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}
#else
#define STARTFILE_SPEC \
%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}
#endif
#undef ENDFILE_SPEC
#define ENDFILE_SPEC \
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
#ifndef CC1_SPEC
#define CC1_SPEC %{profile:-p}
#endif
#undef CPLUSPLUS_CPP_SPEC
#define CPLUSPLUS_CPP_SPEC -D_GNU_SOURCE %(cpp)
#if defined(HAVE_LD_EH_FRAME_HDR)
#define LINK_EH_SPEC %{!static:--eh-frame-hdr}
#endif
/* Define this so we can compile MS code for use with WINE. */
#define HANDLE_PRAGMA_PACK_PUSH_POP
#define LINK_GCC_C_SEQUENCE_SPEC \
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
/* Use --as-needed -lgcc_s for eh support. */
#ifdef HAVE_LD_AS_NEEDED
#define USE_LD_AS_NEEDED 1
#endif
#define TARGET_POSIX_IO
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #6 from ams at gnu dot org 2006-07-15 15:45 ---
Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
Only the following code will be duplicated which is hardly any
after all:
That is from [gcc]/gcc/config/linux.h, I'm talking about
[gcc]/gcc/config/i386/{linux,gnu}.h. Which is also the one causing
problems without the patch I sent.
I don't want/have time/etc to worry about this right now, it isn't a
very high priority thing anyway. I also don't think it is a very good
idea to copy the content form */linux.h into */gnu.h...
FYI, GNU/k*BSD also uses the GNU/Linux headers, and it doesn't support
uclibc AFAIK.
Cheers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 12:45 AM, ams at gnu dot org wrote:
That is from [gcc]/gcc/config/linux.h, I'm talking about
[gcc]/gcc/config/i386/{linux,gnu}.h. Which is also the one causing
problems without the patch I sent.
bzzz, wrong. TARGET_C99_FUNCTIONS is not defined anywhere in
config/i386/linux.h, it is defined in config/linux.h. Also
powerpc-gnu and alpha-gnu are going to have the same issue.
powerpc-gnu is worse though.
Please try again at actually looking into this issue.
It is obviously you did not look into that much.
Also kBSD is incorrect anyways and should be fixed in the same
matter but that is a different bug.
-- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #7 from pinskia at physics dot uc dot edu 2006-07-15 15:58
---
Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
On Jul 16, 2006, at 12:45 AM, ams at gnu dot org wrote:
That is from [gcc]/gcc/config/linux.h, I'm talking about
[gcc]/gcc/config/i386/{linux,gnu}.h. Which is also the one causing
problems without the patch I sent.
bzzz, wrong. TARGET_C99_FUNCTIONS is not defined anywhere in
config/i386/linux.h, it is defined in config/linux.h. Also
powerpc-gnu and alpha-gnu are going to have the same issue.
powerpc-gnu is worse though.
Please try again at actually looking into this issue.
It is obviously you did not look into that much.
Also kBSD is incorrect anyways and should be fixed in the same
matter but that is a different bug.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #8 from ams at gnu dot org 2006-07-15 16:07 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:07 AM, ams at gnu dot org wrote: Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. -- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #9 from pinskia at physics dot uc dot edu 2006-07-15 16:10 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 16, 2006, at 1:07 AM, ams at gnu dot org wrote: Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:10 AM, Andrew Pinski wrote: Why it is not obvious and I say the patch is incorrect. Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. If you want them be included. And I still say the patch is incorrect. I already explained why I thought it was incorrect as linux.h should not be included. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. -- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #10 from pinskia at physics dot uc dot edu 2006-07-15 16:14 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 16, 2006, at 1:10 AM, Andrew Pinski wrote: Why it is not obvious and I say the patch is incorrect. Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. If you want them be included. And I still say the patch is incorrect. I already explained why I thought it was incorrect as linux.h should not be included. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #11 from ams at gnu dot org 2006-07-15 16:25 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. If you don't want to commit the patch then that is fine, it isn't like GCC can even compile on the GNU system due to the other bugs with patches being neglected (mostly by me). Happy hacking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #12 from ams at gnu dot org 2006-07-15 16:27 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. Thanks. I'm actually quite aware of that. I haven't gotten around to cleaning it all up so that I can send it to gcc-patches@ in one go. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. Thanks. I confused it with config/alpha/linux which defines TARGET_C99_FUNCTIONS. Cheers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:25 AM, ams at gnu dot org wrote: The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. Actually you are incorrect about not being related to this bug as it is the reason why this bug showed up and it is not clean as shown by this bug. Move along and fix/post a correct fix to the mailing list. -- Pinski
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #13 from pinskia at physics dot uc dot edu 2006-07-15 16:29 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 16, 2006, at 1:25 AM, ams at gnu dot org wrote: The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. Actually you are incorrect about not being related to this bug as it is the reason why this bug showed up and it is not clean as shown by this bug. Move along and fix/post a correct fix to the mailing list. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #14 from ams at gnu dot org 2006-07-15 16:55 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I think we will have to agree to disagree on this, since neither you or I will change our minds. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #8 from mrs at gcc dot gnu dot org 2006-07-15 17:03 --- Subject: Bug 28280 Author: mrs Date: Sat Jul 15 17:03:44 2006 New Revision: 115479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115479 Log: Revert: PR c/28280 * c-parser.c (c_parser_typeof_specifier): Don't use c_finish_expr_stmt, open code desired semantics instead. Removed: trunk/gcc/testsuite/gcc.dg/vla-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
http://en.fon.com/ On 15 Jul 2006 16:14:34 - pinskia at physics dot uc dot edu [EMAIL PROTECTED] wrote: --- Comment #10 from pinskia at physics dot uc dot edu 2006-07-15 16:14 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 16, 2006, at 1:10 AM, Andrew Pinski wrote: Why it is not obvious and I say the patch is incorrect. Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. If you want them be included. And I still say the patch is incorrect. I already explained why I thought it was incorrect as linux.h should not be included. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #15 from wieseltux23 at gmail dot com 2006-07-15 18:00 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared http://en.fon.com/ On 15 Jul 2006 16:14:34 - pinskia at physics dot uc dot edu [EMAIL PROTECTED] wrote: --- Comment #10 from pinskia at physics dot uc dot edu 2006-07-15 16:14 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On Jul 16, 2006, at 1:10 AM, Andrew Pinski wrote: Why it is not obvious and I say the patch is incorrect. Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. If you want them be included. And I still say the patch is incorrect. I already explained why I thought it was incorrect as linux.h should not be included. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
http://en.fon.com/ On 15 Jul 2006 16:25:10 - ams at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #11 from ams at gnu dot org 2006-07-15 16:25 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. If you don't want to commit the patch then that is fine, it isn't like GCC can even compile on the GNU system due to the other bugs with patches being neglected (mostly by me). Happy hacking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #16 from wieseltux23 at gmail dot com 2006-07-15 18:01 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared http://en.fon.com/ On 15 Jul 2006 16:25:10 - ams at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #11 from ams at gnu dot org 2006-07-15 16:25 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. If you don't want to commit the patch then that is fine, it isn't like GCC can even compile on the GNU system due to the other bugs with patches being neglected (mostly by me). Happy hacking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug fortran/28390] New: Broken !$omp parallel do lastprivate(iterationvar)
! see OpenMP 2.5 spec, page 64 and A.30 on page 175 program tst_lastpriv integer nc parameter (nc=100) integer a(nc),i !$omp parallel do lastprivate(i) do i=1,nc a(i) = i end do if (i.ne.nc+1) then print *,'failed, i=',i else print *,'success ',a(nc),i endif end fails with current trunk and -fopenmp. -- Summary: Broken !$omp parallel do lastprivate(iterationvar) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28390
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- 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 c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-15 18:58 --- Reopening because Mike cannot do it himself as he does not know the trick of using his @gcc.gnu.org. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #9 from enrico dot scholz at informatik dot tu-chemnitz dot de 2006-07-15 19:22 --- *** Bug 28362 has been marked as a duplicate of this bug. *** -- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added CC||enrico dot scholz at ||informatik dot tu-chemnitz ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug target/28362] [ARM] Generates wrong code for ALSA kernel driver
--- Comment #1 from enrico dot scholz at informatik dot tu-chemnitz dot de 2006-07-15 19:22 --- *** This bug has been marked as a duplicate of 27363 *** -- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28362
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #10 from enrico dot scholz at informatik dot tu-chemnitz dot de 2006-07-15 19:26 --- Bug #28362 contains a self contained example. Basically, it needs only | some_struct = *some_other_struct; to trigger this bug. I wonder for how much other segfaults/brokeness this bug is responsible for. Btw, happens for every gcc release (3.4.6, 4.0.3, 4.1.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer
--- Comment #3 from tbm at cyrius dot com 2006-07-15 20:10 ---
Here's another test case, taken from maxdb:
50015:[EMAIL PROTECTED]: ~/tmp/src/gcc/delta/bin] gcc-4.1 -c -fPIC -O2 28243.c
28243.c: In function âpa01CompareKeywordWâ:
28243.c:25: fatal error: internal consistency failure
compilation terminated.
Preprocessed source stored into /tmp/cc4ogkHJ.out file, please attach this to
your bugreport.
zsh: exit 1 gcc-4.1 -c -fPIC -O2 28243.c
50016:[EMAIL PROTECTED]: ~/tmp/src/gcc/delta/bin] cat 28243.c
typedef struct tsp1_packet_header { } tsp81_UCS2Char;
typedef struct
{
short entry;
unsigned char keyword[(18)];
int order_type_key;
unsigned short keywordW[(18)];
}
api_keyword_tab;
static api_keyword_tab keyword_tab[] = {
};
pa01CompareKeywordW (const unsigned short * strp, int * order_type)
{
unsigned int i, len1, len2;
for (i = 0; keyword_tab[i].entry != (99); i++)
{
sp81UCS2strlen ((tsp81_UCS2Char *) (keyword_tab[i].keywordW));
len1 = len1 len2 ? len1 : len2;
if (memcmp (keyword_tab[i].keywordW, strp, len1) == 0)
{
*order_type = keyword_tab[i].order_type_key;
break;
}
}
}
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com,
||debian-gcc at lists dot
||debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #9 from paolo at gcc dot gnu dot org 2006-07-15 20:30 --- Subject: Bug 28277 Author: paolo Date: Sat Jul 15 20:30:50 2006 New Revision: 115485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115485 Log: 2006-07-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28277 (partial: ostream bits 1) * include/bits/ostream.tcc (operator(basic_ostream_CharT, const char*)): Avoid __builtin_alloca with no limit in the widening. * testsuite/27_io/basic_ostream/inserters_character/wchar_t/ 28277-1.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/ostream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug c++/28051] [4.0 regression] ICE on invalid conversion operator
--- Comment #11 from lmillward at gcc dot gnu dot org 2006-07-15 20:38 --- I've posted a patch which fixes the bug properly on the 4.0 branch and allows the testcase added to pass. URL - http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00689.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28051
[Bug bootstrap/27794] stack explosion
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-07-15 20:39 --- Eric, do you have any new information on this problem? I cannot reproduce it. I'm totally at a loss. I don't have any working debugger on the machine, the system debugger enters an infinite loop: azuma% /usr/ccs/bin/gdb32 xgcc Detected 64-bit executable. Invoking /usr/ccs/bin/gdb64. Detected 32-bit executable. Invoking /usr/ccs/bin/gdb32. Detected 64-bit executable. Invoking /usr/ccs/bin/gdb64. Detected 32-bit executable. Invoking /usr/ccs/bin/gdb32. Detected 64-bit executable. Invoking /usr/ccs/bin/gdb64. Detected 32-bit executable. Invoking /usr/ccs/bin/gdb32. Detected 64-bit executable. Invoking /usr/ccs/bin/gdb64. Detected 32-bit executable. Invoking /usr/ccs/bin/gdb32. [...] and building GDB 6.4 doesn't produce anything. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-07-15 20:39:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug bootstrap/27794] stack explosion
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-07-15 20:39:43 |2006-07-15 20:40:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-07-15 21:47 --- Created an attachment (id=11893) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11893action=view) Patch for 4.1 Adapted patch for 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-15 22:58 --- Probably latent on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
[Bug middle-end/28160] Bogus size of array 'foo' is too large error with -mms-bitfields
--- Comment #7 from kkojima at gcc dot gnu dot org 2006-07-15 23:12 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-07-15 23:13 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
