[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer > I don't understand the assertion, given that removing it seems to > generate correct output for this test case. The problem is that this function PADS rather than EXTENDS data that's shorter than it's supposed to be, and it always pads in the same direction - IIRC little endian. Thus, it breaks on big endian machines, or machines that require sign extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug target/36321] Optimization higher or equal to -O2 produce wrong code
--- Comment #8 from dj at redhat dot com 2008-11-14 23:09 --- The test case segfaults on simulators that don't initialize argv[0] to the name of the running program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug middle-end/38756] New: 107t.ivopts introduces pointer truncation
When building gcc.c-torture/execute/2412-6.c with -mcpu=m32c (pointers are
24 bits), ivopts introduces a truncation to "unsigned short" (sizetype, which
is 16 bits) - truncating needed bits off the pointer. 107t.ivopts shows this:
tmp_9 = tmp_16 + 2;
D.1229_1 = (unsigned int) tmp_9;
tmp_13 = (short unsigned int *) D.1229_1;
if (bufend_6(D) > tmp_13)
which ends up being a PSI -> HI -> PSI conversion (PSI-SI-HI-SI-PSI in
128r.expand)
--
Summary: 107t.ivopts introduces pointer truncation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38756
[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables
--- Comment #3 from dj at redhat dot com 2009-01-26 19:46 --- Subject: Re: New: libiberty make_relative_prefix_1 mistakes directories for executables Your code conditionally includes but doesn't conditionally enable the other code. If sys/stat.h isn't found, perhaps the code could revert to the old access() code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #9 from dj at redhat dot com 2009-01-27 19:38 --- Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug target/40129] M16C invalid shift count used by pack_d -> ashldi3
--- Comment #1 from dj at redhat dot com 2009-05-14 02:52 --- Do you have a test case that shows an actual problem? Because the m32c port has special code that tests for shift counts outside -16..16 and pre-shifts the value to make the shift count fit (see gcc/config/m32c/m32c.c m32c_prepare_shift()). -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug target/40129] M16C invalid shift count used by pack_d -> ashldi3
--- Comment #4 from dj at redhat dot com 2009-05-18 19:16 --- Yes, those two changes are the fix you need. However, those fixes were over three years ago, so I consider this bug "already fixed". If you agree, please close this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug rtl-optimization/40626] New: -frename-registers causes register corruption
When compiled with -frename-registers, the TBA test case produces invalid code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h assumes it still has the value "a" in it. Compiling with -fno-rename-registers results in valid code. -- Summary: -frename-registers causes register corruption Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dj at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mep-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #1 from dj at redhat dot com 2009-07-02 21:41 --- Created an attachment (id=18129) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18129&action=view) test case for the above Compile with: ./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #2 from dj at redhat dot com 2009-07-02 21:42 --- Created an attachment (id=18130) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18130&action=view) resulting .s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #3 from dj at redhat dot com 2009-07-02 21:42 --- Created an attachment (id=18131) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18131&action=view) dump just before rnreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #4 from dj at redhat dot com 2009-07-02 21:43 --- Created an attachment (id=18132) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18132&action=view) dump just after rnreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #5 from dj at redhat dot com 2009-07-10 02:56 --- http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00546.html Fixed in revision 149455. -- dj at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug target/41000] Optional optimization error
--- Comment #4 from dj at redhat dot com 2009-08-07 16:26 --- m32c != m32r -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000
[Bug bootstrap/25842] Error in building libiberty
--- Comment #2 from dj at redhat dot com 2006-01-18 20:23 --- Subject: Re: New: Error in building libiberty Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #11 from dj at redhat dot com 2006-07-31 18:07 ---
(1) I can manage my own bugzilla account, thankyouverymuch, and (2) I'm not the
only build maintainer.
--
dj at redhat dot com changed:
What|Removed |Added
CC|dj at redhat dot com|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #14 from dj at redhat dot com 2006-08-01 17:35 --- First off, I was mostly just explaining that assertion. Second, I think that this code can be a valid initializer - the value we initialize to is, in this case, an 8 byte value which contains the least significant 4 bytes of an offset. Because of the masking, we can't expect the assembler to figure it out, but the value happens to fit in a 4 byte value (er, unless it's a HUGE structure ;) so the compiler should be able to. However, that doesn't mean it's a no-op conversion. What I mean here, is that we can't rely on the code where the assert is to do the "conversion" for us, because it does it wrong. That code is designed to pad structures and such, not do type conversions. If you give it a 4 byte initializer, and ask for an 8 byte space to be filled, it pads. It does NOT actually convert anything, which causes the problems I noted. The reason I discovered this is because it was padding out an ADDRESS on the m16c (pointers are smaller than the address space), and the address was truncated. Thus, not truly a no-op conversion. So, I added code to try to detect the cases where we *can* let the assembler do the right thing (i.e. if there's a .op for the larger type), and reject the cases that we know we can't handle. The solution is to either add more special cases to the code where the assertion is, or actually do the conversions beforehand (something like simplify_rtx, but for trees, and perhaps knowing about signed vs unsigned). I think the optimizer could do this for this case, because it knows that the resulting value is constrained to be known to fit and not be truncated by the conversions, but I don't think that output_constant should be expected to do those kinds of optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #16 from dj at redhat dot com 2006-08-01 18:37 --- I think it's acceptable to temporarily disable that assertion for this release, but (1) we should test that code on both big and little endian 64 bit machines and see if it produces wrong code (perhaps with a larger offset to see if the truncation is happening), and (2) we should consider re-enabling the assertion later if so. Ideally, the assertion only detects the case where it *will* produce wrong code, at least on a big endian machine. That might imply that more special cases are needed for what is truly a no-op conversion, or an extra optimization step before we check the initializers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug c/30741] Error when trying to compile under DOS on a Vista machine
--- Comment #1 from dj at redhat dot com 2007-02-09 03:10 --- For starters, gcc is case sensitive. When you passed it PROG1.C instead of prog1.c, you're telling it to compile a C++ program. Did you install the C++ compiler? Do you get the same error if you use prog1.c instead of PROG1.C ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
[Bug c/30741] Error when trying to compile under DOS on a Vista machine
--- Comment #3 from dj at redhat dot com 2007-02-09 19:14 --- Did you follow the zip-picker instructions? You have to use a djgpp-aware unzip program to install, or the filenames get all messed up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #8 from dj at redhat dot com 2007-02-20 15:20 --- Looks OK to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug target/31113] Problem while compiling gcc for m32c-elf
--- Comment #1 from dj at redhat dot com 2007-03-09 20:08 --- Subject: Re: New: Problem while compiling gcc for m32c-elf Fixed via revision 122759. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31113
[Bug c/31348] Error in compilation
--- Comment #3 from dj at redhat dot com 2007-03-26 21:36 --- 30972 is Windows, this is DJGPP - different operating systems. Are you using the stock 2.03 files, or the 2.04 (beta) files? There are known incompatibilities in XP and Vista that require the 2.04 builds of the GNU tools, so if you're still using 2.03 (current), please replace them with the 2.04 (beta) versions, and try again. If 2.04 solves it, then this is not a gcc bug. -- dj at redhat dot com changed: What|Removed |Added CC| |dj at redhat dot com Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31348
[Bug other/32783] gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice
--- Comment #5 from dj at redhat dot com 2007-07-17 17:52 --- Subject: Re: gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice I removed the duplicate from the msdosdjgpp case. svn rev 126704 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
--- Comment #3 from dj at redhat dot com 2007-07-23 17:29 --- Subject: Re: New: [4.3 Regression] "make info" fails in libiberty I've checked in a fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug target/31482] error: could not split insn, internal compiler error: in final_scan_insn
--- Comment #2 from dj at redhat dot com 2007-09-25 01:46 --- Patch applied. -- dj at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31482
[Bug target/33184] [4.3 Regression] m32c: ostream.tcc:92: error: unable to find a register to spill in class 'A_REGS'
--- Comment #3 from dj at redhat dot com 2007-09-25 01:46 --- Patch applied. -- dj at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33184
[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220
--- Comment #7 from dj at redhat dot com 2007-09-25 02:15 --- Seems to work for me now; could you recheck it with the patches I just committed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
[Bug tree-optimization/35834] New: building libiberty fails in build2_stat for -mcpu=m32c as of r133403
$ ./cc1 -fpreprocessed /tmp/cplus-dem.i -quiet -dumpbase cplus-dem.c -mcpu=m32cm -auxbase-strip cplus-dem.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -o cplus-dem.s ../../../../gcc/libiberty/cplus-dem.c: In function 'cplus_demangle_name_to_style': ../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in build2_stat, at tree.c:3107 -- Summary: building libiberty fails in build2_stat for -mcpu=m32c as of r133403 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dj at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403
--- Comment #1 from dj at redhat dot com 2008-04-05 15:36 --- Created an attachment (id=15433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15433&action=view) preprocessed cplus-dem.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #2 from dj at redhat dot com 2009-02-02 21:52 --- You should put the new code in a #ifdef HAVE_STDINT and use the old code otherwise. Else, any platforms without stdint.h would not compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug target/39182] ICE in gen_add2_insn, at optabs.c:4884
--- Comment #3 from dj at redhat dot com 2009-02-13 20:28 --- Fails with m32c-elf in 4.3.4 also. Note: does NOT fail in 4.4/trunk -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-13 20:28:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231 --- Comment #5 from DJ Delorie 2013-05-02 17:39:29 UTC --- I'm OK with it being committed, but it's not up to me, ping Jeff or Kazu. h8 portJeff Lawl...@redhat.com h8 portKazu Hiratak...@codesourcery.com
[Bug middle-end/54217] New: setup_save_areas() duplicates hard reg uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217 Bug #: 54217 Summary: setup_save_areas() duplicates hard reg uses Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@redhat.com Created attachment 27977 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27977 patch to check for duplicate hard reg uses setup_save_areas() in caller-save.c sometimes (with -fira-share-save-slots) maps one hard reg to two different saved regs. Since the save arrays are sized to [FIRST_PSEUDO_REGISTER] this means the arrays may overflow. The attached test case demonstrates the error, the attached patch checks for the error and forces an abort when it's detected. Note: at the time I discovered this, newlib (from whence the test case came) would show this error "somewhere" for these *-elf targets: bfin cris m32c rl78 rx sh sh64 v850
[Bug middle-end/54217] setup_save_areas() duplicates hard reg uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217 --- Comment #1 from DJ Delorie 2012-08-10 00:22:22 UTC --- Created attachment 27978 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27978 test case for rl78-elf, from newlib
[Bug target/54951] Incorrect pointer handling on 32K boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #1 from DJ Delorie 2012-10-18 02:14:48 UTC --- This is, unfortunately, the expected behavior for m32c. The m32c has 20-bit pointers but 16-bit math operations, so size_t is 16 bits resulting in many pointer math operations being truncated to 16 bits. So, a COUNT of 0x may be interpreted as -1 instead of 65536, etc.
[Bug target/54952] Program crash on M32C when stack frame is more then 128 bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54952 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #1 from DJ Delorie 2012-10-18 06:03:14 UTC --- FYI this looks like an assembler bug, not a gcc bug... The "add.l #128,sp" opcode is being assembled as "add.l #-128,sp" instead.
[Bug target/41456] unrecognized R constraint: R13
-- dj at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dj at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-24 20:42:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41456
[Bug c++/41916] psignal() declaration needs const char*
--- Comment #1 from dj at redhat dot com 2009-11-02 22:04 --- Subject: Re: New: psignal() declaration needs const char* Libiberty should not even try to compile psignal() on djgpp as djgpp already has one. This is noted in libiberty/configure.ac. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41916
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 --- Comment #5 from DJ Delorie 2011-01-18 01:46:00 UTC --- Created attachment 23014 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23014 alternate patch Alternate patch. The v850.md patch tests frame_related, which is set for REGS only to indicate that the value is a pointer, which "fixed" this bug only by coincidence. I think what's happening is that the v850 backend is generating a BB that starts with a label, so fixup_sched_groups uses prev_nonnote_nondebug_insn() and finds the label. However, the functions it calls expects only an INSN. This patch adds a check for an INSN, to avoid adding deps on labels.
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #7 from DJ Delorie 2011-01-21 22:21:48 UTC --- sched-deps:sched_analyze_2 has this: #ifdef HAVE_cc0 case CC0: /* User of CC0 depends on immediately preceding insn. */ SCHED_GROUP_P (insn) = 1; But the conditional before the setcc was deleted (that's insn 22). So the comment above is wrong in this case; there is no immediately preceeding insn.
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 DJ Delorie changed: What|Removed |Added Attachment #23014|0 |1 is obsolete|| Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dj at redhat dot com |gnu.org | --- Comment #8 from DJ Delorie 2011-01-21 22:31:37 UTC --- Created attachment 23074 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23074 alternate patch 2 This one checks to make sure there *is* an immediately preceeding insn. Better?
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 --- Comment #11 from DJ Delorie 2011-01-22 00:37:35 UTC --- I set a breakpoint on the delete of that insn; at that time, the following insn did not have the /S set on it. At the time when the /S is added, the previous insn had already been deleted. So, it's delete first, set /s second, crash third. And it's not the setcc that's delted, it's the (compare) before it. The setcc is the one with the /s on it.
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 --- Comment #12 from DJ Delorie 2011-01-22 00:40:44 UTC --- Of course, one could argue that perhaps the compare should *not* have been removed? I don't know how clever the new redundant compare removal code is.
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 DJ Delorie changed: What|Removed |Added Attachment #23074|0 |1 is obsolete|| --- Comment #16 from DJ Delorie 2011-01-25 23:41:53 UTC --- Created attachment 23126 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23126 alternate patch 3 Another patch attempt. In this case, we add a check for the implied dependency created by a cc0 setter/user pair to insn_a_feeds_b() so that try_combine() knows that the cc0 setter is needed if the user is needed.
[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 DJ Delorie changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #24 from DJ Delorie 2011-01-26 23:21:30 UTC --- Resolved in git commit 169307.
[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #1 from DJ Delorie 2011-02-01 01:06:43 UTC --- Created attachment 23192 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23192 Patch to avoid trying to validate interim patterns Try this one. If there are multiple reloads needed for an insn, we were validating the interim patterns, which I think is incorrect. With this patch, we allow invalid interim patterns.
[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #3 from DJ Delorie 2011-02-04 14:59:08 UTC --- That's odd. Could you take my patch back out, and verify the problem goes back to the original one? My patch shouldn't be able to affect anything earlier...
[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #5 from DJ Delorie 2011-02-04 15:21:40 UTC --- See if one of these other changes caused the problem. If so, yeah, I'll check this one in and we'll work on the other one separately. The new error you're seeing is one I've seen on and off for years. * config/m32c/m32c.h (PTRDIFF_TYPE): Remove extra definition. * config/m32c/m32c.c (m32c_regno_reg_class): Return smallest reg class for A0/A1.
[Bug c/57956] missing 'msgstr' section errors when building
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #2 from DJ Delorie --- I tracked this down to a PO file that requires a newer version of gettext than the gcc prereq page requires: http://gcc.gnu.org/ml/gcc/2013-07/msg00203.html
[Bug other/58238] cc1 crashes when built for ms-dos cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238 --- Comment #2 from DJ Delorie --- Please try the attached patch. I tested it with a simple "#include stdint.h" but we made the type names exact matches (way back when) for a reason...
[Bug other/58238] cc1 crashes when built for ms-dos cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-26 CC||dj at redhat dot com Assignee|unassigned at gcc dot gnu.org |dj at redhat dot com Ever confirmed|0 |1 --- Comment #1 from DJ Delorie --- Created attachment 30702 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30702&action=edit remove "signed" from internal type names It seems gcc no longer permits "signed" in internal type names, so this patch takes them out.
[Bug other/52100] New: CRTSTUFF_CFLAGS needs -fno-asynchronous-unwind-tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52100 Bug #: 52100 Summary: CRTSTUFF_CFLAGS needs -fno-asynchronous-unwind-tables Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@redhat.com Created attachment 26557 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26557 patch to add -fno-asynchronous-unwind-tables s390 and i386 set -fno-asynchronous-unwind-tables by default; this causes extra unwind tables to be emitted into crtendS.o after the manual terminator, which (for s390 at least) causes the linker to complain.
[Bug c/59304] #pragma diagnostic pop fails with -Wswitch-enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304 --- Comment #2 from DJ Delorie --- The diagnostic changes that happen with #pragmas are stored in a linear array, which corresponds (somehow) to the linear input source file representation. So, given a location in the source, we can find the spot in the array that corresponds to the state at that point, with earlier array entries being "before" that location, and later ones being "after". Once found, we scan backwards through the array looking for #pragmas that might affect the diagnostic. If we see one, that's what we use. If we see a DK_POP code, we skip over the chunk of the array to the matching PUSH ([i].option), i.e. it's as if those actions never happened. What's supposed to happen is that changing a diagnostic via a #pragma should push a change code onto that stack also, this should happen via a call to diagnostic_classify_diagnostic when the #pragma changes the handling (with WHERE set to a known location).
[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #1 from DJ Delorie 2012-01-09 18:02:53 UTC --- See if this helps: Index: gcc/config/h8300/h8300.h === --- gcc/config/h8300/h8300.h (revision 183004) +++ gcc/config/h8300/h8300.h(working copy) @@ -126,12 +126,13 @@ extern const char * const *h8_reg_names; /* The return address is pushed on the stack. */ #define INCOMING_RETURN_ADDR_RTX gen_rtx_MEM (Pmode, gen_rtx_REG (Pmode, STACK_POINTER_REGNUM)) #define INCOMING_FRAME_SP_OFFSET (POINTER_SIZE / 8) #define DWARF_CIE_DATA_ALIGNMENT 2 +#define DWARF2_ADDR_SIZE 4 /* Define this if addresses of constant functions shouldn't be put through pseudo regs where they can be cse'd. Desirable on machines where ordinary constants are expensive but a CALL with constant address is cheap.
[Bug target/31801] [dataflow] undefined reference to `gen_blockage'
--- Comment #2 from dj at redhat dot com 2007-05-03 20:01 --- Note that only 19 out of 33 target directories (trunk) even mention the word "blockage" and there's no mention of "blockage" in the trunk documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31801
[Bug target/31801] [dataflow] undefined reference to `gen_blockage'
--- Comment #4 from dj at redhat dot com 2007-05-03 22:55 --- Gak, the grep didn't show it earlier today, but does now. Sigh. Lesson: never buy quantum computers! We still have the problem that almost half the targets (on trunk) don't have gen_blockage(). Will updating all the targets be part of the dataflow branch's patchset when it merges? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31801
[Bug target/32055] reload failure building libgfortran
--- Comment #1 from dj at redhat dot com 2007-05-25 03:02 --- Indeed the SI is suspicious, since the m32c family doesn't have those types of pointers (it has HI or PSI pointers, but not SI). I've never tried to build FORTRAN for the m32c family though, so if there's a FORTRAN developer out there who could point me at a suitable starting point in the gcc/f95 code... -- dj at redhat dot com changed: What|Removed |Added CC| |dj at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-25 03:02:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32055
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #3 from dj at redhat dot com 2007-05-31 21:09 --- Subject: Re: sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B Note that m32c puts *.ld files in the *build* directory, not the *source* directory, unlike most targets. The m32c source directory only has templates. Also, please keep the comments around. You're deleting them from the m32c case, but not adding equivalent ones in the generic case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #5 from dj at redhat dot com 2007-06-01 01:08 --- m32c still needs -L$$r/$(TARGET_SUBDIR)/libgloss/m32c to find r8c.ld in the build directory. Your patch would only search in the source directory. Be careful with -B vs -L, and $$r vs $$s. You've also removed the special flags needed for a mep build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #6 from dj at redhat dot com 2007-06-20 17:35 --- Subject: Re: ICE in global_alloc, at global.c:514 It was a long time ago, I'm thinking that having too many hard regs live during reload causes problems on m32c because it has so few registers. You can try setting it to R0 and see what else breaks ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #21 from dj at redhat dot com 2007-06-27 21:28 --- Subject: Re: [4.3 Regression] ICE in global_alloc, at global.c:514 The patch in comment #9 is OK with me, please commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug other/32532] Warning: variable ret never used in writeargv
--- Comment #1 from dj at redhat dot com 2007-06-28 02:09 --- Ok to commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32532
[Bug c/32763] internal error - compiling DiskEditor (hed.c)
--- Comment #1 from dj at redhat dot com 2007-07-14 02:58 --- Subject: Re: New: internal error - compiling DiskEditor (hed.c) > gcc.exe: Internal error: (null) (program as) djgpp 2.03 (current) or 2.04 (beta) ? You might need the XP bugfixes in 2.04. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32763
[Bug libgcc/62269] m32c-elf libgcc fails to configure- setjmp/longjmp exception check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62269 --- Comment #2 from DJ Delorie --- Sorry for not being as responsive as I should be, but I've tried occasionally to fix the m32c-gcc issues and they just keep getting worse. I suspect m32c should be deprecated at this point, it's not one of of the mcu's Renesas is promoting these days, and there are some unsolveable ICEs building libgcc and newlib. OTOH C++ *is* supported.
[Bug target/78818] msp430 persistent attribute is not applied correctly in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78818 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dj at redhat dot com Resolution|--- |FIXED --- Comment #4 from DJ Delorie --- Fixed.
[Bug target/23746] m32c.h has a typo
--- Additional Comments From dj at redhat dot com 2005-09-06 02:34 --- Subject: Re: New: m32c.h has a typo > Note the misspelled "ALIGMNENT". Fixed. 2005-09-05 DJ Delorie <[EMAIL PROTECTED]> * config/m32c/m32c.h (TRAMPOLINE_ALIGNMENT): Correct misspelling of macro. Index: config/m32c/m32c.h === RCS file: /cvs/gcc/gcc/gcc/config/m32c/m32c.h,v retrieving revision 1.2 diff -p -U3 -r1.2 m32c.h --- config/m32c/m32c.h 26 Jul 2005 13:53:52 - 1.2 +++ config/m32c/m32c.h 6 Sep 2005 02:31:03 - @@ -517,7 +517,7 @@ typedef struct m32c_cumulative_args /* Trampolines for Nested Functions */ #define TRAMPOLINE_SIZE m32c_trampoline_size () -#define TRAMPOLINE_ALIGMNENT m32c_trampoline_alignment () +#define TRAMPOLINE_ALIGNMENT m32c_trampoline_alignment () #define INITIALIZE_TRAMPOLINE(a,fn,sc) m32c_initialize_trampoline (a, fn, sc) /* Addressing Modes */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23746
[Bug target/23746] m32c.h has a typo
--- Additional Comments From dj at redhat dot com 2005-09-06 02:35 --- Obvious fix applied to HEAD. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23746
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From dj at redhat dot com 2005-09-19 19:57 --- Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer > DJ, apparently you caused this one. Yup, and I had reservations about that portion of the patch at the time, too, which have turned out to be justified (the reservations, not the patch). I think the best option at this point is to just take the check out (leaving in the other part of the patch, which is needed for m32c). The code will still be buggy if the no-op converts to a larger size, though, because it doesn't take endianness into account when padding. I'm rather surprised that the test case works for sizeof(long) > sizeof(int), I'd expect the bytes to be truncated in amusing ways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From dj at redhat dot com 2005-09-23 17:22 --- Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer I recall that the opposite case is problematic; initializing a large int from a smaller one, because gcc always zero pads at the end. Perhaps a lt/gt comparison would be more appropriate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug libstdc++/22087] ctype tables are offset by one on DJGPP
--- Comment #4 from dj at redhat dot com 2005-10-10 19:31 --- Subject: Re: ctype tables are offset by one on DJGPP > If the proposed patch is regression tested and approved by the DJGPP > maintainers can certainly go in, since touches only the > target-specific files. I'm OK with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22087
[Bug bootstrap/24394] Bootstrap failure: conflicting types for 'floatformat_to_double', others
--- Comment #2 from dj at redhat dot com 2005-10-17 17:27 --- Subject: Re: New: Bootstrap failure: conflicting types for 'floatformat_to_double', others Please make sure you're not building the latest gcc sources (gcc/libiberty/floatformat.c) with older binutils sources (src/include/floatformat.h). The function signatures were changed on Aug 17th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24394
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #33 from dj at redhat dot com 2005-10-26 23:13 --- Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed > It looks like DJ is saying the same in the new thread which shows > the real issues with the other compilers implemenation. I would be in favor of treating \r differently from other whitespace for the purposes of reporting this error. The cr-lf-newline mess is different from the trailing space mess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug target/78804] [RX] -m64bit-doubles does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #24 from DJ Delorie --- "olegendo at gcc dot gnu.org" writes: > I don't know why it was decided to use this ABI. Maybe some legacy > stuff. Compatibility with Renesas's compiler.
[Bug c/78584] Bug in GCC argument parser expandargv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-29 CC||dj at redhat dot com Ever confirmed|0 |1 --- Comment #2 from DJ Delorie --- Confirmed on Fedora 24 with gcc 6.2.1, but agreed, the @file thing is for reading arguments from a file, not compiling a file that starts with @. It shouldn't fail like that though. gcc: out of memory allocating 9223372036854775808 bytes after a total of 0 bytes
[Bug c/78584] Bug in GCC argument parser expandargv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584 --- Comment #4 from DJ Delorie --- kernel-4.8.6-201.fc24.x86_64 glibc-2.23.1-11.fc24.x86_64 but I'm also working on a libiberty patch to detect the case and avoid it.
[Bug c/78584] Bug in GCC argument parser expandargv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584 DJ Delorie changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from DJ Delorie --- I'm using ext4
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #3 from DJ Delorie --- More likely, DJGPP just doesn't support more than 8-byte alignment. Either way, this is something that should be investigated on the djgpp list first, and brought back here only if it's proven to be a gcc problem.
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 --- Comment #5 from DJ Delorie --- DJGPP issues should be sent to the dj...@delorie.com mailing list, or comp.os.msdos.djgpp newsgroup.
[Bug target/77570] [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dj at redhat dot com Resolution|--- |FIXED --- Comment #2 from DJ Delorie --- Patch applied. Thanks!
[Bug c++/67529] rx-elf C++ inherited class malformed call to overridden methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67529 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #5 from DJ Delorie --- I tested this with rx-elf-g++ 6.0 (trunk) and it has the relevent vtables in it, and at that jsr it jumps to MyTemplate::check() (at least, in the simulator). That's using your linker script. You can add -Wl,-Map,test.map to generate a link map, and look for _ZTV10MyTemplate to see what the linker does with it. For example, it might be a bug in linker garbage collection, or the interim object files (or *.s if you -save-temps) might not have them, etc.
[Bug c/68119] GCC diagnostic push/pop interfere with control flow statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68119
DJ Delorie changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-10-27
CC||dj at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from DJ Delorie ---
Confirmed with git trunk as of today, even with -O0. Gimple shows:
test1 (unsigned int a)
{
unsigned int D.1764;
if (0 != 0) goto ; else goto ;
:
a = a + 1;
:
a = a + 1;
D.1764 = a;
return D.1764;
}
test2 (unsigned int a)
{
unsigned int D.1768;
if (0 != 0) goto ; else goto ;
:
:
a = a + 1;
a = a + 1;
D.1768 = a;
return D.1768;
}
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #8 from DJ Delorie --- There are a few regressions in the testsuite (pr26255.c with -mcpu=m32c for example) and libstdc++ still doesn't build, but ieee/920810-1 now passes and newlib builds. I suppose that's "better".
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #11 from DJ Delorie --- I see the "relocation out of range" error too. I'm configuring for m32c-elf
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #12 from DJ Delorie --- The reloc bug is caused when gcc puts a JMP.A at the very end of .text and also adds debug info; this puts a 3-byte reloc right at the end of a section (m32c-as pads the last section if it's a code section, the debug info makes .text not last) but BFD has no option for a non-power-of-two reloc in the HOWTO table, so it thinks it's 4 bytes and thus extends past the end of the section. I suspect the way to fix this is to handle that one reloc specially (the rest are handled by generic reloc handlers), unless someone has an alternate idea?
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #15 from DJ Delorie --- The binutils team has been working a lot on patching vulnerabilities in the binutils tools. The m32c, however, has a 3-byte reloc that might occur at the end of a section, and was implemented as three bytes of a four-byte "word", which would then be outside the bounds of the section. Recent patches check for such bounds crossings, hence the breakage. I've checked in a patch to binutils head to manually process the R_M32C_24 relocations so that the range checking is more appropriate to the three-byte relocation.
[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com Assignee|unassigned at gcc dot gnu.org |dj at redhat dot com --- Comment #3 from DJ Delorie --- Created attachment 33764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33764&action=edit proposed patch As there are places in the code that scan all of integer_type_kind[] without regard for whether those types are allowed or not, decline to create said types in the first place if they're not enabled. Unable to test at the moment due to PR 63307.
[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582 DJ Delorie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from DJ Delorie --- Patch committed to r216762.
[Bug libgcc/63682] m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682 --- Comment #1 from DJ Delorie --- m32c-elf supports C++. What is the contents of the failing config.log? Also, there's nothing m32c-specific in the sjlj checks, it's the same for all sjlj targets.
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #4 from DJ Delorie --- Perhaps you need this patch: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html
[Bug debug/69073] internal compiler error: in maybe_record_trace_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69073 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #3 from DJ Delorie --- I'm unable to reproduce this with today's sources. Could you add some details about the host you're running, on, and/or retest with a source update?
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #1 from DJ Delorie --- If elsewhere calls foo(500) you will get an actual out of bounds access. I think the warning is appropriate. Have you tried checking the value of 'order' in that function, before the loop, to validate its value? Such a check might fix your bug and silence the warning.
[Bug other/13906] genmodes.c:964: internal compiler error: Bus error in md5_process_block
--- Additional Comments From dj at redhat dot com 2005-07-07 14:56 --- Subject: Re: genmodes.c:964: internal compiler error: Bus error in md5_process_block I can build the latest CVS binutils on x86_64-linux. Please make sure you have the include files that correspond to the libiberty you're using; you can't mix and match them. If you are using a newer md5.c than md5.h you're bound to have problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13906
[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #4 from dj at redhat dot com 2010-01-08 20:51 --- Still present in 4.5 trunk, also fails for rx-elf-gcc with -m32bit-doubles but not with -m64bit-doubles. -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com Last reconfirmed|-00-00 00:00:00 |2010-01-08 20:51:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #20 from dj at redhat dot com 2010-08-12 16:57 --- Just for fun, I compiled this test case with various levels of optimization. It works fine without optimization or with -O1, but segfaults at -O2 or -O3. That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong. In this case, your assumption is that "bug_example_2" will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout. The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires. The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee. At least, it does when optimizing. Without optimization, it *happens* to do what you expect. It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the "cdecl" standard you refer to applies, because cross-object calls are limited by the compatibility standards. However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*. So, GCC is "cdecl" compliant because *if* there's a function call, *then* the *stack* is laid out the same. However, the "cdecl" standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope. Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works. Also, with full optimization enabled, your code crashes with MSVC also. Please file a bug report with Microsoft. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #28 from dj at redhat dot com 2010-08-12 18:08 --- I built your test case with gcc and g++ without optimizations, and it worked fine. I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version. Also, please provide an official spec for this "cdecl" you keep referring to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #5 from dj at redhat dot com 2010-09-22 20:13 --- Still fails for both h8300-elf and rx-elf, both on 4.5 branch and 4.6 trunk. -- dj at redhat dot com changed: What|Removed |Added Last reconfirmed|2010-01-08 20:51:02 |2010-09-22 20:13:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #6 from dj at redhat dot com 2010-09-22 20:22 --- Created an attachment (id=21866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21866&action=view) possible fix FYI I've been using this to silence the warning in my local tree... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug target/45800] [M32C] compile error on increment volatile long var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45800 DJ Delorie changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.28 21:18:10 date|| AssignedTo|unassigned at gcc dot |dj at redhat dot com |gnu.org | Ever Confirmed|0 |1
[Bug other/44435] gengtype: don't test undefined value after vasprintf failure
--- Comment #3 from dj at redhat dot com 2010-06-07 18:14 --- Subject: Re: gengtype: don't test undefined value after vasprintf failure > If the libiberty maintainers won't review the xvasprintf patch, I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
