[Bug libgcc/62269] m32c-elf libgcc fails to configure- setjmp/longjmp exception check

[dj at redhat dot com]

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

[dj at redhat dot com]

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/78804] [RX] -m64bit-doubles does not work

[dj at redhat dot com]

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 target/79935] DJGPP: misaligned stack in static constructors

[dj at redhat dot com]

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/79935] DJGPP: misaligned stack in static constructors

[dj at redhat dot com]

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 c/78584] Bug in GCC argument parser expandargv

[dj at redhat dot com]

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 c/78584] Bug in GCC argument parser expandargv

[dj at redhat dot com]

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

[dj at redhat dot com]

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 target/77570] [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration

[dj at redhat dot com]

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 target/71338] [RL78] mulu instruction not used on G10

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338

--- Comment #4 from DJ Delorie  ---
Sure, the only dependencies might be on binutils/gdb releases, but they support
it and they're independent of gcc releases anyway.

[Bug debug/69073] internal compiler error: in maybe_record_trace_start

[dj at redhat dot com]

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 c/68119] GCC diagnostic push/pop interfere with control flow statements

[dj at redhat dot com]

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 c++/67529] rx-elf C++ inherited class malformed call to overridden methods

[dj at redhat dot com]

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 tree-optimization/66974] -Warray-bounds false positive with -O3

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #1 from DJ Delorie dj at redhat dot com ---
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 target/50928] m32c ICE building RTEMS

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

--- Comment #15 from DJ Delorie dj at redhat dot com ---
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 target/50928] m32c ICE building RTEMS

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

--- Comment #11 from DJ Delorie dj at redhat dot com ---
I see the relocation out of range error too.
I'm configuring for m32c-elf

[Bug target/50928] m32c ICE building RTEMS

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

--- Comment #12 from DJ Delorie dj at redhat dot com ---
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

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928

--- Comment #8 from DJ Delorie dj at redhat dot com ---
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 libgcc/63682] m32c: libgcc configure checks for SJLJ model even when C++ and Java are disabled

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63682

--- Comment #1 from DJ Delorie dj at redhat dot com ---
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 c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from DJ Delorie dj at redhat dot com ---
Patch committed to r216762.

[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582

DJ Delorie dj at redhat dot com 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 dj at redhat dot com ---
Created attachment 33764
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33764action=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 target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[dj at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #4 from DJ Delorie dj at redhat dot com ---
Perhaps you need this patch:

https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html

[Bug c/59304] #pragma diagnostic pop fails with -Wswitch-enum

[dj at redhat dot com]

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

--- Comment #2 from DJ Delorie dj at redhat dot com ---
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 other/58238] cc1 crashes when built for ms-dos cross-compiling

[dj at redhat dot com]

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

--- Comment #2 from DJ Delorie dj at redhat dot com ---
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

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com 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 dj at redhat dot com ---
Created attachment 30702
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30702action=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 c/57956] missing 'msgstr' section errors when building

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #2 from DJ Delorie dj at redhat dot com ---
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 bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

[dj at redhat dot com]

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



--- Comment #5 from DJ Delorie dj at redhat dot com 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 target/54952] Program crash on M32C when stack frame is more then 128 bytes

[dj at redhat dot com]

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



DJ Delorie dj at redhat dot com changed:



   What|Removed |Added



 CC||dj at redhat dot com



--- Comment #1 from DJ Delorie dj at redhat dot com 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/54951] Incorrect pointer handling on 32K boundary

[dj at redhat dot com]

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



DJ Delorie dj at redhat dot com changed:



   What|Removed |Added



 CC||dj at redhat dot com



--- Comment #1 from DJ Delorie dj at redhat dot com 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 middle-end/54217] New: setup_save_areas() duplicates hard reg uses

[dj at redhat dot com]

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

[dj at redhat dot com]

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

--- Comment #1 from DJ Delorie dj at redhat dot com 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 other/52100] New: CRTSTUFF_CFLAGS needs -fno-asynchronous-unwind-tables

[dj at redhat dot com]

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 bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #1 from DJ Delorie dj at redhat dot com 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 other/2222] option enable-target-optspace disables _GNU_SOURCE

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie dj at redhat dot com 2011-06-02 20:33:43 UTC 
---
Given that I forgot I had it, probably no

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #3 from DJ Delorie dj at redhat dot com 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

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie dj at redhat dot com 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 target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[dj at redhat dot com]

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

--- Comment #1 from DJ Delorie dj at redhat dot com 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 rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #24 from DJ Delorie dj at redhat dot com 2011-01-26 23:21:30 UTC 
---
Resolved in git commit 169307.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

  Attachment #23074|0   |1
is obsolete||

--- Comment #16 from DJ Delorie dj at redhat dot com 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 target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #7 from DJ Delorie dj at redhat dot com 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

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com 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 dj at redhat dot com 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

[dj at redhat dot com]

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

--- Comment #11 from DJ Delorie dj at redhat dot com 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

[dj at redhat dot com]

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

--- Comment #12 from DJ Delorie dj at redhat dot com 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

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie dj at redhat dot com 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/45800] [M32C] compile error on increment volatile long var

[dj at redhat dot com]

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

DJ Delorie dj at redhat dot com 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 c/35649] Incorrect printf warning: expect double has float

[dj at redhat dot com]

--- 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

[dj at redhat dot com]

--- 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=21866action=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 c++/45265] GCC has an intermittent bug when computing the address of function parameters

[dj at redhat dot com]

--- 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

[dj at redhat dot com]

--- 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/44884] RX tst insn has been not fixed yet.

[dj at redhat dot com]

--- Comment #2 from dj at redhat dot com  2010-07-09 05:03 ---
I've got a patch for it, just haven't sent it in yet.  See
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg3.html too


-- 

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 |2010-07-09 05:03:34
   date||


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

[Bug c/44884] RX tst insn has been not fixed yet.

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2010-07-09 05:12 ---
Right, I haven't sent the patch in yet.  The other bug needs to be fixed first;
the TST patch triggers an ICE otherwise.


-- 


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

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

[dj at redhat dot com]

--- 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

[Bug c/35649] Incorrect printf warning: expect double has float

[dj at redhat dot com]

--- 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++/41916] psignal() declaration needs const char*

[dj at redhat dot com]

--- 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/41456] unrecognized R constraint: R13

[dj at redhat dot com]

-- 

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 target/41000] Optional optimization error

[dj at redhat dot com]

--- 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 rtl-optimization/40626] -frename-registers causes register corruption

[dj at redhat dot com]

--- 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 rtl-optimization/40626] New: -frename-registers causes register corruption

[dj at redhat dot com]

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

[dj at redhat dot com]

--- 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=18129action=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

[dj at redhat dot com]

--- 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=18130action=view)
resulting .s


-- 


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

[Bug rtl-optimization/40626] -frename-registers causes register corruption

[dj at redhat dot com]

--- 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=18131action=view)
dump just before rnreg


-- 


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

[Bug rtl-optimization/40626] -frename-registers causes register corruption

[dj at redhat dot com]

--- 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=18132action=view)
dump just after rnreg


-- 


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

[Bug target/40129] M16C invalid shift count used by pack_d - ashldi3

[dj at redhat dot com]

--- 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 target/40129] M16C invalid shift count used by pack_d - ashldi3

[dj at redhat dot com]

--- 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/39182] ICE in gen_add2_insn, at optabs.c:4884

[dj at redhat dot com]

--- 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 target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t

[dj at redhat dot com]

--- 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 testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[dj at redhat dot com]

--- 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 other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[dj at redhat dot com]

--- 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 sys/stat.h 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 middle-end/38756] New: 107t.ivopts introduces pointer truncation

[dj at redhat dot com]

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 target/36321] Optimization higher or equal to -O2 produce wrong code

[dj at redhat dot com]

--- 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 target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #14 from dj at redhat dot com  2008-07-18 00:22 ---
Subject: Re:  [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload


Seems to work for m32c too.


-- 


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

[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #11 from dj at redhat dot com  2008-07-16 19:08 ---
Subject: Re:  [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload


Last night's builds showed a flaw in the patch.  The ++rii address
created by m32c_legitimize_reload_address is *not* legitimate, it's
used as a marker for addresses that need to be reloaded into an
address register.  If I fix m32c_print_operand() to print those, it
ends up printing an address that exceeds the displacement range of the
FB register:

regex.s:11903: Error: unrecognized keyword/register name `mov.w mem0,-198[fb]'

The original idea was to reload $fb of $sp itself into an address
register, and use a displacement off that, so that only one address
register is needed for all frame address reloads.  I never quite got
gcc to do it right.


-- 


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

[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2008-07-15 15:38 ---
Yes, 137639 and 137640 are the same patch, to trunk and 4.3, respectively.


-- 


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

[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #7 from dj at redhat dot com  2008-07-16 02:07 ---
Subject: Re:  [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload


It fixes the newlib compile failure, but there are regressions since
it last built.  I'll have to check each of them to see if they're
caused by this patch or something else that's happened since then.

Meanwhile, please apply your m32c patch. newlib doesn't build is
certainly a bigger problem than some regressions :-)

Thanks!


-- 


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

[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #8 from dj at redhat dot com  2008-07-16 03:04 ---
Subject: Re:  [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload


The regressions all show up in v850 and iq2000 too, except one that I
can't reproduce, so I'm not going to worry about them.


-- 


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

[Bug c/36827] New: newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

as of rev 137639:

cc1 -fpreprocessed k_rem_pio2.i -quiet -dumpbase k_rem_pio2.c -auxbase-strip
lib_a-k_rem_pio2.o -Os -fno-builtin -o k_rem_pio2.s

src/newlib/libm/math/k_rem_pio2.c: In function '__kernel_rem_pio2':
newlib/libm/math/k_rem_pio2.c:318: error: unable to find a register to spill in
class 'A_REGS'
newlib/libm/math/k_rem_pio2.c:318: error: this is the insn:
(jump_insn 1098 1096 2868 9 newlib/libm/math/k_rem_pio2.c:186 (set (pc)
(if_then_else (gt (subreg:HI (reg/v:SI 1108 [ i ]) 2)
(subreg:HI (reg/v:SI 1105 [ m ]) 2))
(label_ref:HI 3007)
(pc))) 48 {cbranchhi4} (expr_list:REG_BR_PROB (const_int 5000
[0x1388])
(nil)))
newlib/libm/math/k_rem_pio2.c:318: internal compiler error: in spill_failure,
at reload1.c:1995


-- 
   Summary: newlib:libm/math/k_rem_pio2.c fails in reload
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
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=36827

[Bug c/36827] newlib:libm/math/k_rem_pio2.c fails in reload

[dj at redhat dot com]

--- Comment #1 from dj at redhat dot com  2008-07-14 22:31 ---
Created an attachment (id=15908)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15908action=view)
preprocessed file for description


-- 


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

[Bug tree-optimization/35834] New: building libiberty fails in build2_stat for -mcpu=m32c as of r133403

[dj at redhat dot com]

$ ./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

[dj at redhat dot com]

--- 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=15433action=view)
preprocessed cplus-dem.i


-- 


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

[Bug c++/34687] as crashed

[dj at redhat dot com]

--- Comment #5 from dj at redhat dot com  2008-01-08 21:26 ---
Subject: Re:  as crashed


Have you tried the 2.04 version?


-- 


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

[Bug c++/34687] as crashed

[dj at redhat dot com]

--- Comment #7 from dj at redhat dot com  2008-01-08 22:00 ---
Subject: Re:  as crashed


DJGPP 2.04 is newer than djgpp 2.03.  You need to try the gcc 4.2.2
that's built with djgpp 2.04 (it's in the beta subdir, instead of
current).  You have installed the gcc 4.2.2 that's built with djgpp
2.03, which doesn't work as well with XP and Vista.


-- 


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

[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a

[dj at redhat dot com]

--- Comment #10 from dj at redhat dot com  2007-11-02 17:41 ---
Subject: Re:  [4.3 Regression] Arg list too long building libgcc.a


You could try splitting that one in two with gmake's $(filter ) and
$(filter-out ) functions.  The only trick would be finding a simple
pattern that matches half the objects.


-- 


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

[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a

[dj at redhat dot com]

--- Comment #12 from dj at redhat dot com  2007-11-02 18:56 ---
Created an attachment (id=14472)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14472action=view)
test patch 3

This one just breaks up #15 into three chunks, with everything else in a single
chunk.


-- 

dj at redhat dot com changed:

   What|Removed |Added

  Attachment #14457|0   |1
is obsolete||


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

[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a

[dj at redhat dot com]

--- Comment #13 from dj at redhat dot com  2007-11-02 18:58 ---
Created an attachment (id=14473)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14473action=view)
sclsh - short command line shell

Here's a short perl script that acts as a short command line shell - it
complains about any command line longer than 3k bytes.  Use make SHELL=sclsh
  Edit as needed.  It also tells you how long each command line is,
although it doesn't work around command lines that exceed system limits.


-- 


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

[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a

[dj at redhat dot com]

--- Comment #3 from dj at redhat dot com  2007-11-01 16:03 ---
Created an attachment (id=14453)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14453action=view)
test patch

Could you give this a try on IRIX?  It's just an officialized copy of Jakub's
suggestion.  My only concern is using the c flag to ar more than once - it
doesn't purge the archive under Linux, but who knows what other OSs will do.


-- 


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

[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a

[dj at redhat dot com]

--- Comment #5 from dj at redhat dot com  2007-11-01 20:02 ---
Created an attachment (id=14457)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14457action=view)
test patch 2

Here's another try.  We collect the libgcc.a objects in multiple variables (18
of them) so that we can invoke $(AR) multiple times.  Hopefully, this will
result in individual command lines that meet IRIX's limits.  What is your
systune'd command line limit, anyway?
If needed, we can apply this technique to other libraries too.


-- 

dj at redhat dot com changed:

   What|Removed |Added

  Attachment #14453|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot gnu   |dj at redhat dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2007-10-31 18:03 ---
Subject: Re:  iv folding fails with pointer iterations


Oops, sorry, I have a local patch.  Apparently I'm trying to support
pointer math the same size as pointers (pointers are 24 bits) as an
option for the future, which lowers the priority for this bug, but I'd
appreciate it if it worked anyway - I'm getting requests for this
functionality.  By default, pointers are 24 bits but size_t is only
16, which causes wrong-code in some cases.

Index: config/m32c/m32c.h
===
--- config/m32c/m32c.h  (revision 129762)
+++ config/m32c/m32c.h  (working copy)
@@ -170,12 +170,15 @@ machine_function;

 #define DEFAULT_SIGNED_CHAR 1

 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE (TARGET_A16 ? int : long int)

+#undef SIZE_TYPE
+#define SIZE_TYPE (TARGET_A16 ? unsigned int : long unsigned int)
+
 /* REGISTER USAGE */

 /* Register Basics */

 /* Register layout:



-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #6 from dj at redhat dot com  2007-10-31 18:36 ---
Subject: Re:  iv folding fails with pointer iterations


Hmmm... pointers are PSImode (24 bits) with --mcpu=m32c.  How do you
make sizetype that size?  The chip doesn't have enough 24 bit math
opcodes to do all the things gcc wants.


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #8 from dj at redhat dot com  2007-10-31 22:27 ---
Subject: Re:  iv folding fails with pointer iterations


Right, that's why I was trying to use 32 bit math instead, which led
to the original iv bug.


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #2 from dj at redhat dot com  2007-10-30 04:30 ---
Subject: Re:  iv folding fails with pointer iterations


Yup.  I did a source update, rebuilt the natives, and tried to build...

m32c-elf-gcc -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/ -isystem
/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/targ-include -isystem
/greed/dj/m32c/newlib/src/newlib/libc/include
-B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/m32c
-L/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/libnosys
-L/greed/dj/m32c/newlib/src/libgloss/m32c  -mcpu=m32cm
-DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\
-DPACKAGE_VERSION=\1.15.0\ -DPACKAGE_STRING=\newlib\ 1.15.0\
-DPACKAGE_BUGREPORT=\\  -I. -I../../../../../../src/newlib/libc/stdlib -Os
-DPREFER_SIZE_OVER_SPEED -DABORT_PROVIDED -DSMALL_MEMORY
-DMISSING_SYSCALL_NAMES -fno-builtin  -O2 -g -O2-mcpu=m32cm -c -o
lib_a-wcstombs_r.o `test -f 'wcstombs_r.c' || echo
'../../../../../../src/newlib/libc/stdlib/'`wcstombs_r.c
../../../../../../src/newlib/libc/stdlib/wcstombs_r.c: In function
'_wcstombs_r':
../../../../../../src/newlib/libc/stdlib/wcstombs_r.c:11: internal compiler
error: in build2_stat, at tree.c:3110

I'm using a 32-bit build OS, though.


-- 


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

[Bug tree-optimization/33915] New: iv folding fails with pointer iterations

[dj at redhat dot com]

void
cyg_hal_plf_serial_write(void* __ch_data, const unsigned char* __buf,
 unsigned long __len)
{
while(__len--  0)
cyg_hal_plf_serial_putc(__ch_data, *__buf++);
}
cc1 -O3 -mcpu=m32c dj.c

fails in build2_stat trying to add two pointers.
See also http://gcc.gnu.org/ml/gcc/2007-10/msg00435.html


-- 
   Summary: iv folding fails with pointer iterations
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: rakdver at kam dot mff dot cuni dot cz
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=33915

[Bug target/31482] error: could not split insn, internal compiler error: in final_scan_insn

[dj at redhat dot com]

--- 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'

[dj at redhat dot com]

--- 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

[dj at redhat dot com]

--- 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 other/32859] [4.3 Regression] make info fails in libiberty

[dj at redhat dot com]

--- 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 other/32783] gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice

[dj at redhat dot com]

--- 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 c/32763] internal error - compiling DiskEditor (hed.c)

[dj at redhat dot com]

--- 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 target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514

[dj at redhat dot com]

--- 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

[dj at redhat dot com]

--- 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 target/32418] ICE in global_alloc, at global.c:514

[dj at redhat dot com]

--- 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