Bug 46261 - avr-gcc: Segfaults when compiled with the -mint8 option
avr-gcc: Segfaults when compiled with the -mint8 option
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: target
4.5.1
: P3 normal
: 4.7.1
Assigned To: Not yet assigned to anyone
: ice-on-valid-code
: 47310 49530 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-01 18:36 UTC by Thibault North
Modified: 2014-02-16 13:14 UTC (History)
6 users (show)

See Also:
Host:
Target: avr
Build:
Known to work: 4.5.4, 4.6.4, 4.7.1
Known to fail: 4.5.3, 4.6.3, 4.7.0
Last reconfirmed: 2011-06-26 19:41:11


Attachments
CHAR16 and CHAR32 in avr with -mint8 (1.08 KB, patch)
2011-05-01 13:29 UTC, Iouri Kharon
Details | Diff
Attachment #24157 fixed to patch the right file (1.08 KB, patch)
2011-05-01 17:24 UTC, Thibault North
Details | Diff
Fixed the filenames in the patch header. (1.08 KB, patch)
2011-06-28 06:30 UTC, Joerg Wunsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thibault North 2010-11-01 18:36:18 UTC
The compiler segfaults when code is compiled with -mint8 option.

This bug was previously reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=626889

Arch: reported to happend on i686 and x86_64.
GCC build: see below.

How to reproduce: compile and run the following code, as shown below.

/** \file testmint8.c */
#include <avr/io.h>

int main(void) {
  DDRB=0xFF;
  while(1)
    {
    PORTB++;
    }
}

Output:
avr-gcc -v -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mint8 -mmcu=at90pwm3b -DF_CPU=8000000UL -MMD -MP -MF"testmint8.d" -MT"testmint8.d" -c -o"testmint8.o" "testmint8.c" -save-temps
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.1/lto-wrapper
Target: avr
Configured with: ../gcc-4.5.1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs --with-pkgversion='Fedora 4.5.1-2.fc14' --with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.5.1 (Fedora 4.5.1-2.fc14) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-g2' '-gstabs' '-O0' '-fpack-struct' '-fshort-enums' '-std=gnu99' '-funsigned-char' '-funsigned-bitfields' '-mint8' '-mmcu=at90pwm3b' '-DF_CPU=8000000UL' '-MMD' '-MP' '-MFtestmint8.d' '-MTtestmint8.d' '-c' '-o' 'testmint8.o' '-save-temps'
 /usr/libexec/gcc/avr/4.5.1/cc1 -E -quiet -v -imultilib avr4 -MMD testmint8.d -MFtestmint8.d -MP -MTtestmint8.d -MQ testmint8.o -DF_CPU=8000000UL testmint8.c -mint8 -mmcu=at90pwm3b -std=gnu99 -Wall -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -g2 -gstabs -fworking-directory -O0 -fpch-preprocess -o testmint8.i
ignoring nonexistent directory "/usr/lib/gcc/avr/4.5.1/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/4.5.1/include
 /usr/lib/gcc/avr/4.5.1/include-fixed
 /usr/lib/gcc/avr/4.5.1/../../../../avr/include
End of search list.
<built-in>:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugzilla.redhat.com/> for instructions.

preprocessed file (*.i*) is short and contains:
# 1 "testmint8.c"
# 1 "/tmp//"

avr-gcc --version -v
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.1/lto-wrapper
avr-gcc (Fedora 4.5.1-2.fc14) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: avr
Configured with: ../gcc-4.5.1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs --with-pkgversion='Fedora 4.5.1-2.fc14' --with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.5.1 (Fedora 4.5.1-2.fc14) 
COLLECT_GCC_OPTIONS='-fversion' '-v'
 /usr/libexec/gcc/avr/4.5.1/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version -fversion -o /tmp/ccfBxPus.s
GNU C (Fedora 4.5.1-2.fc14) version 4.5.1 (avr)
	compiled by GNU C version 4.5.1 20100907 (Red Hat 4.5.1-3), GMP version 4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-fversion' '-v'
 /usr/lib/gcc/avr/4.5.1/../../../../avr/bin/as --version -o /tmp/cc9BaGQj.o /tmp/ccfBxPus.s
GNU assembler (GNU Binutils) 2.20
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `avr'.
COMPILER_PATH=/usr/libexec/gcc/avr/4.5.1/:/usr/libexec/gcc/avr/4.5.1/:/usr/libexec/gcc/avr/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.5.1/../../../../avr/bin/
LIBRARY_PATH=/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-fversion' '-v'
 /usr/libexec/gcc/avr/4.5.1/collect2 --version -L/usr/lib/gcc/avr/4.5.1 -L/usr/lib/gcc/avr/4.5.1/../../../../avr/lib /tmp/cc9BaGQj.o -lgcc -lc -lgcc
GNU ld (GNU Binutils) 2.20
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
Comment 1 Eric Weddington 2010-11-02 18:39:59 UTC
The -mint8 option also does not work with building avr-libc. There has been discussion (on the avr-gcc-list mailing list) about eventually removing this. There has been no interest by the AVR port maintainers (that I'm aware of) in continuing to maintain this switch.

Closed as WONTFIX.
Comment 2 Thibault North 2010-11-02 18:45:08 UTC
Ok, I was not aware of that. However, it should not crash gcc.
Thanks!
Comment 3 Alex Godko 2011-01-25 16:56:26 UTC
*** Bug 47310 has been marked as a duplicate of this bug. ***
Comment 4 Iouri Kharon 2011-05-01 13:29:35 UTC
Created attachment 24157 [details]
CHAR16 and CHAR32 in avr with -mint8

This patch correct bug 46261 in gcc-4.5.x
Comment 5 Thibault North 2011-05-01 17:24:57 UTC
Created attachment 24158 [details]
Attachment #24157 [details] fixed to patch the right file
Comment 6 Thibault North 2011-05-01 17:25:52 UTC
(I seems that the file gcc/defaults.h is the one which must be patched by the second part of your patch)
Comment 7 Thibault North 2011-05-01 17:27:20 UTC
It works for me, thanks.
Comment 8 Georg-Johann Lay 2011-06-26 09:57:36 UTC
*** Bug 49530 has been marked as a duplicate of this bug. ***
Comment 9 Georg-Johann Lay 2011-06-26 19:41:11 UTC
(In reply to comment #1)
> The -mint8 option also does not work with building avr-libc. There has been
> discussion (on the avr-gcc-list mailing list) about eventually removing this.
> There has been no interest by the AVR port maintainers (that I'm aware of) in
> continuing to maintain this switch.
> 
> Closed as WONTFIX.

I strongly oppose the WON'T FIX.

Either we keep that option and is is functional.
Or we keep it and say sorry("-mint8 is discontinued") when it is used.
Or we remove it.

By no means the compiler is supposet to run into ICE/segfault, so allow me to reopen this issue.
Comment 10 Eric Weddington 2011-06-27 05:43:20 UTC
Hi All,

Johann is correct in his comment to bug #46261 (below).

The -mint8 compiler switch is now causing the compiler to give an ICE.

We need to finally make a decision from one of these options:

1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, even though avr-libc doesn't build with it.

2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with -mint8 (eventually).

3. Remove -mint8, because avr-libc will never be changed to work with it.

Or suggest an alternative option.

Personally, I vote for #3. What's your option?

Thanks,
Eric Weddington

> -----Original Message-----
> From: gjl at gcc dot gnu.org [mailto:gcc-bugzilla@gcc.gnu.org]
> Sent: Sunday, June 26, 2011 1:42 PM
> To: Weddington, Eric
> Subject: [Bug target/46261] avr-gcc: Segfaults when compiled with the -
> mint8 option
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
> 
> Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> --------------------------------------------------------------------------
> --
>            Keywords|                            |ice-on-valid-code
>              Status|RESOLVED                    |NEW
>    Last reconfirmed|                            |2011.06.26 19:41:11
>          Resolution|WONTFIX                     |
>      Ever Confirmed|0                           |1
>       Known to fail|                            |4.5.2, 4.6.1
> 
> --- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-06-26
> 19:41:11 UTC ---
> (In reply to comment #1)
> > The -mint8 option also does not work with building avr-libc. There has
> been
> > discussion (on the avr-gcc-list mailing list) about eventually removing
> this.
> > There has been no interest by the AVR port maintainers (that I'm aware
> of) in
> > continuing to maintain this switch.
> >
> > Closed as WONTFIX.
> 
> I strongly oppose the WON'T FIX.
> 
> Either we keep that option and is is functional.
> Or we keep it and say sorry("-mint8 is discontinued") when it is used.
> Or we remove it.
> 
> By no means the compiler is supposet to run into ICE/segfault, so allow me
> to
> reopen this issue.
> 
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
Comment 11 chertykov 2011-06-27 06:41:24 UTC
2011/6/27 Weddington, Eric <Eric.Weddington@atmel.com>:
> Hi All,
>
> Johann is correct in his comment to bug #46261 (below).
>
> The -mint8 compiler switch is now causing the compiler to give an ICE.
>
> We need to finally make a decision from one of these options:
>
> 1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, even though avr-libc doesn't build with it.
>
> 2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with -mint8 (eventually).
>
> 3. Remove -mint8, because avr-libc will never be changed to work with it.
>
> Or suggest an alternative option.
>
> Personally, I vote for #3. What's your option?

Let's remove it.

Denis.
Comment 12 Joerg Wunsch 2011-06-27 08:02:15 UTC
(In reply to comment #11)

> Let's remove it.

Two things to consider:

. Regardless of whether someone votes to remove an option, a segfault
  should always be analyzed.  It's easy enough to otherwise just hide
  an error that will only reappear later on.

. As long as the AVR backend has a substantial number of PRs open about
  "missed optimization", related to [u]int8_t -> int promotions, the
  -mint8 option should stay, as it appears to be useful in particular
  to people using very small controllers (ATtiny13, also think about
  the new ATtiny4/5/6/9 series).  Non-applicability of this option to
  avr-libc is not a serious issue for those targets anyway, so this
  (counter-)argument doesn't count here.
Comment 13 Georg-Johann Lay 2011-06-27 08:30:12 UTC
(In reply to comment #10)
> Hi All,
> 
> Johann is correct in his comment to bug #46261 (below).
> The -mint8 compiler switch is now causing the compiler to give an ICE.
> We need to finally make a decision from one of these options:
> 
> 1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, even
> though avr-libc doesn't build with it.
> 
> 2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with
> -mint8 (eventually).
> 
> 3. Remove -mint8, because avr-libc will never be changed to work with it.

What's avr-libc to do with it?
-mint8 has never been a multilib option and I don't know if avr-libc was  supposed to build with -mint8 in the past.

Johann

> Thanks,
> Eric Weddington



(In reply to comment #11)
> Let's remove it.
> 
> Denis.

Note that the option is broken in 4.5 and 4.6 already, so the option would have to be removed in stage 3/4 of the compiler that is intended for bugs/documentation updates only. It's up to the maintainers, of course.

If the patches above it all that needs to be done, it's maybe not that hard to get it to work again, and mybe it's even possible without frontend changes.

Johann
Comment 14 Eric Weddington 2011-06-27 21:49:18 UTC
> 
> Two things to consider:
> 
> . Regardless of whether someone votes to remove an option, a segfault
>   should always be analyzed.  It's easy enough to otherwise just hide
>   an error that will only reappear later on.

Except that this is a segfault on a compiler switch that is unmaintained, and there are little to no user complaints about it. I would say remove the offending item and then fix anything if needed.

 
> . As long as the AVR backend has a substantial number of PRs open about
>   "missed optimization", related to [u]int8_t -> int promotions, the
>   -mint8 option should stay, 

There are PRs open regarding missed optimization in this category. I'm not sure what is required to meet "substantial".

> as it appears to be useful in particular
>   to people using very small controllers (ATtiny13, also think about
>   the new ATtiny4/5/6/9 series).  Non-applicability of this option to
>   avr-libc is not a serious issue for those targets anyway, so this
>   (counter-)argument doesn't count here.

Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I would call "experimental", in that they are only in distros and not upstream, and you know as well as I do that there is a serious wrong-code bug with them anyway. So those users don't even count. As to the other small device users, those devices still use avr-libc and there has been opportunity for users to complain through various channels (gcc, avr-gcc-list, avr-libc-dev) that -mint8 doesn't work. While we have had some complaints in the past, there haven't been much recently. You and I have also been telling users that -mint8 doesn't work with avr-libc and that it is unmaintained.

We all know that the ideal solution is to fix the avr backend regarding optimizing (removing) unnecessary promotion. We can start by biting the bullet and removing -mint8.

Eric
Comment 15 Joerg Wunsch 2011-06-28 06:27:17 UTC
(In reply to comment #14)

> > . Regardless of whether someone votes to remove an option, a segfault
> >   should always be analyzed.

> Except that this is a segfault on a compiler switch that is unmaintained,

Did you analyze it to make sure there is no chance for this to happen
also without -mint8?

OK, I did, and it's indeed the case.

"unmaintained" — by the original maintainers.  The people contributing
(patches!) to this bug report demonstrate there actually *is* some
effort to still maintain it — by the users.

Why ignore this effort, and do it away as "we don't want to maintain
that anymore"?

The only drawback I could see with that patch is that it introduces a
couple of #ifdefs outside of the AVR code path in the compiler, to
give the AVR backend an override option for the type sizes.

> and
> there are little to no user complaints about it.

That's simply because all the compiler versions that are "out in the
field" (4.3.x, 4.4.x) still have a working (within their known
limitations, of course) -mint8 option.

Be assured, we will get complaints about it if you release another
WinAVR with a non-working -mint8 option, or with the option dropped.

> Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I
> would call "experimental", in that they are only in distros and not upstream,
> and you know as well as I do that there is a serious wrong-code bug with them
> anyway.

That doesn't matter much.  The wrong-code bug can (probably) be fixed,
but the integer promotion issues won't be affected by that fix.

If you don't like the reference to ATtiny10 (&Co.), just keep the
ATtiny13 (and probably also ATtiny2313, ATtiny25, ATtiny45) in your
mind by now.

> As to the other small device users,
> those devices still use avr-libc

They *can* use it.  We've always told them however, that using -mint8
and avr-libc doesn't mix.  Nevertheless, it appears to be useful
enough to some users to decide pro -mint8 (and thus against using the
library).  (It isn't even entirely true that both don't mix: a lot of
the library stuff just comes as inline functions and macros within the
header files, and this part is likely working to a large degree even
with -mint8.)

> We all know that the ideal solution is to fix the avr backend regarding
> optimizing (removing) unnecessary promotion. We can start by biting the bullet
> and removing -mint8.

I'd do it the other way around: fix the optimization issues, until the
users don't benefit from the -mint8 hack anymore.  By that time, it can
be removed without anyone complaining.

You cannot impose any pressure to the *developers* (to fix the
optimization issues) by removing the option now, but you'll cause some
impact for users of that option — users who can't do anything about it
other than voicing their complaints in public that more recent
versions of GCC get worse and worse in their usability.  I'd like to
avoid this situation.
Comment 16 Joerg Wunsch 2011-06-28 06:30:42 UTC
Created attachment 24611 [details]
Fixed the filenames in the patch header.

Fixed the filenames in the patch header (there have been two .orig too many).

I can confirm the patch fixes the issue in question on GCC trunk.
Comment 17 Georg-Johann Lay 2011-06-28 18:26:26 UTC
Instead of defining CHAR16_TYPE, I think it's preferred to define UINT_LEAST16_TYPE appropriately and use logic in defaults.h so that defaults.h need not to be changed. CHAR16_TYPE is not used in many places, and it appears that defaults.h is included after tm.h.

UINT_LEAST16_TYPE comes from config/newlib-stdint.h which is merged into avr headers in config.gcc.

So a fix inside AVR sandbox could be: 

A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.

or

B) Include newlib-stdint.h prior to avr.h and override as needed.

IMO A) is best because almost anything will have to be overwritten to render -min8 functional again.

Moreover, note independant of this PR, that newlib-stdint.h makes some definitions that are not correct for AVR like
   #define SIG_ATOMIC_TYPE "int" // should be "char" for AVR
So it's desired to have AVR-specific stdint.h, anyway.

The major drawback of -mint8 is that it's not covered by the testsuite at all -- like most other AVR gadgets (ISR, progmem, ...)

If maintainers are willing to support this, I am sure someone will supply according patch.

Johann
Comment 18 Georg-Johann Lay 2011-06-28 18:34:54 UTC
(In reply to comment #17)
> A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.
> 
> or
> 
> B) Include newlib-stdint.h prior to avr.h and override as needed.

or

C) Omit newlib-stdint.h altogether and to the defines in avr.h.

C) and A) are better than B)

Johann
Comment 19 joseph@codesourcery.com 2011-06-28 19:05:00 UTC
On Tue, 28 Jun 2011, gjl at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
> 
> --- Comment #18 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-06-28 18:34:54 UTC ---
> (In reply to comment #17)
> > A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.
> > 
> > or
> > 
> > B) Include newlib-stdint.h prior to avr.h and override as needed.
> 
> or
> 
> C) Omit newlib-stdint.h altogether and to the defines in avr.h.
> 
> C) and A) are better than B)

Indeed, I simply made all bare-metal targets use newlib-stdint.h as a 
default, but since AVR has its own libc it seems more appropriate to put 
the defines in avr-stdint.h or avr.h and not use newlib-stdint.h.  (And 
the point of having separate headers such as newlib-stdint.h is that there 
may not otherwise be a header shared between all relevant targets.  If all 
AVR targets use avr-libc, putting the defines in avr.h makes sense, but if 
avr-rtems is using newlib like other RTEMS targets then you probably want 
a separate header only for AVR targets using avr-libc.)
Comment 20 Georg-Johann Lay 2011-07-02 17:29:23 UTC
(In reply to comment #19)

> Indeed, I simply made all bare-metal targets use newlib-stdint.h as a 
> default, but since AVR has its own libc it seems more appropriate to put 
> the defines in avr-stdint.h or avr.h and not use newlib-stdint.h.  (And 
> the point of having separate headers such as newlib-stdint.h is that there 
> may not otherwise be a header shared between all relevant targets.  If all 
> AVR targets use avr-libc, putting the defines in avr.h makes sense, but if 
> avr-rtems is using newlib like other RTEMS targets then you probably want 
> a separate header only for AVR targets using avr-libc.)

The extra header is not needed because of avr-libc; there is nothing special about avr-libc and it conforms to the standard (except when you explicitely link some lean implementation of *printf* or so. Jörg will correct me if I'm wrong).

The extra avr specific header is just needed to avoid shredding avr-gcc with -mint8 and arrange for int=QI.

-mint8 it not a multilib option, and isn't supported by avr-libc except that it provides conditional type definitions in stdint.h et al.
Comment 21 joseph@codesourcery.com 2011-07-04 10:58:14 UTC
On Sat, 2 Jul 2011, gjl at gcc dot gnu.org wrote:

> > Indeed, I simply made all bare-metal targets use newlib-stdint.h as a 
> > default, but since AVR has its own libc it seems more appropriate to put 
> > the defines in avr-stdint.h or avr.h and not use newlib-stdint.h.  (And 
> > the point of having separate headers such as newlib-stdint.h is that there 
> > may not otherwise be a header shared between all relevant targets.  If all 
> > AVR targets use avr-libc, putting the defines in avr.h makes sense, but if 
> > avr-rtems is using newlib like other RTEMS targets then you probably want 
> > a separate header only for AVR targets using avr-libc.)
> 
> The extra header is not needed because of avr-libc; there is nothing special
> about avr-libc and it conforms to the standard (except when you explicitely

Headers such as newlib-stdint.h tell GCC about the details of choices made 
by the libc implementation where more than one choice would conform to the 
standard.  Thus, if avr-libc has made any choices relating to stdint.h 
different from the choices made by newlib, a separate header may be 
needed for that reason alone.  (All the gcc.dg/c99-stdint-*.c tests should 
pass; if any fail, that suggests either a header bug or a requirement for 
GCC to change how these types are configured in GCC for AVR.)
Comment 22 Georg-Johann Lay 2012-06-04 09:48:37 UTC
Author: gjl
Date: Mon Jun  4 09:48:34 2012
New Revision: 188172

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188172
Log:
	PR target/46261
	* config/avr/avr-stdint.h: New file.
	* config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of
	newlib-stdint.h


Added:
    trunk/gcc/config/avr/avr-stdint.h
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config.gcc
Comment 23 Georg-Johann Lay 2012-06-04 09:51:05 UTC
Author: gjl
Date: Mon Jun  4 09:51:00 2012
New Revision: 188173

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188173
Log:
	Backport from 2012-06-04 mainline r188172
	PR target/46261
	* config/avr/avr-stdint.h: New file.
	* config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of
	newlib-stdint.h


Added:
    branches/gcc-4_7-branch/gcc/config/avr/avr-stdint.h
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config.gcc
Comment 24 Georg-Johann Lay 2012-06-04 09:53:14 UTC
Author: gjl
Date: Mon Jun  4 09:53:04 2012
New Revision: 188174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188174
Log:
	Backport from 2012-06-04 mainline r188172
	PR target/46261
	* config/avr/avr-stdint.h: New file.
	* config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of
	newlib-stdint.h


Added:
    branches/gcc-4_6-branch/gcc/config/avr/avr-stdint.h
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/config.gcc
Comment 25 Georg-Johann Lay 2012-06-04 09:55:44 UTC
Author: gjl
Date: Mon Jun  4 09:55:35 2012
New Revision: 188175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188175
Log:
	Backport from 2012-06-04 mainline r188172
	PR target/46261
	* config/avr/avr-stdint.h: New file.
	* config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of
	newlib-stdint.h


Added:
    branches/gcc-4_5-branch/gcc/config/avr/avr-stdint.h
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config.gcc
Comment 26 Georg-Johann Lay 2012-06-04 09:59:53 UTC
Fixed in: 4.7.1, 4.6.4, 4.5.4.
Comment 27 Jackie Rosen 2014-02-16 13:14:27 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.