[Bug target/42894] [4.5/4.6 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 --- Comment #21 from richard.earnshaw at arm dot com 2011-01-28 19:37:17 UTC --- I shall be out of the office until Monday 28 February; I will not have email access during most of that time, so I will read your message when I return. For managerial issues please contact Roger Teague. For internal engineering issues please contact Matthew Gretton-Dann.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #3 from richard.earnshaw at arm dot com --- On 06/07/18 11:32, Kamil Rytarowski wrote: > On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >> >> --- Comment #2 from Richard Earnshaw --- >> I'm not sure how relevant the netbsd-elf port is these days. I believe >> they've >> now moved onto an EABI based ABI. But no GCC port of that has been >> contributed. >> > > NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A > user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre > ARMv4 CPUs use OABI only. > GCC-9 will drop support for pre-armv4 CPUs. Such support has been marked as deprecated for about 3 years now.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #4 from richard.earnshaw at arm dot com --- On 06/07/18 12:11, Kamil Rytarowski wrote: > On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >> On 06/07/18 11:32, Kamil Rytarowski wrote: >>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >>>> >>>> --- Comment #2 from Richard Earnshaw --- >>>> I'm not sure how relevant the netbsd-elf port is these days. I believe >>>> they've >>>> now moved onto an EABI based ABI. But no GCC port of that has been >>>> contributed. >>>> >>> >>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A >>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre >>> ARMv4 CPUs use OABI only. >>> >> >> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >> marked as deprecated for about 3 years now. >> > > We verify these ports on real hardware. > > NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is > obsoleting it and surprisingly LLVM soon might have support for a wider > range of ARM CPUs. > Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, but it is considered deprecated these days.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #7 from richard.earnshaw at arm dot com --- On 10/07/18 10:57, Kamil Rytarowski wrote: > On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: >> On 06/07/18 12:11, Kamil Rytarowski wrote: >>> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >>>> On 06/07/18 11:32, Kamil Rytarowski wrote: >>>>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >>>>>> >>>>>> --- Comment #2 from Richard Earnshaw --- >>>>>> I'm not sure how relevant the netbsd-elf port is these days. I believe >>>>>> they've >>>>>> now moved onto an EABI based ABI. But no GCC port of that has been >>>>>> contributed. >>>>>> >>>>> >>>>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A >>>>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre >>>>> ARMv4 CPUs use OABI only. >>>>> >>>> >>>> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >>>> marked as deprecated for about 3 years now. >>>> >>> >>> We verify these ports on real hardware. >>> >>> NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is >>> obsoleting it and surprisingly LLVM soon might have support for a wider >>> range of ARM CPUs. >>> >> >> Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, >> but it is considered deprecated these days. >> > > Shark doesn't use all instructions that are generated by GCC (I forgot > the CPU property name of it) and thus it has to be switched to Clang/LLVM. > You're not making sense. Please be more explicit as to what you mean and give an example. GCC can generate instructions for ARMv4 and StrongARM (used by the shark) is an ARMv4 part. I've run gcc generated code on shark boards for years and not seen problems. R.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #8 from richard.earnshaw at arm dot com --- On 10/07/18 18:53, Kamil Rytarowski wrote: > On 10.07.2018 19:49, richard.earnshaw at arm dot com wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >> >> --- Comment #7 from richard.earnshaw at arm dot com --- >> On 10/07/18 10:57, Kamil Rytarowski wrote: >>> On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: >>>> On 06/07/18 12:11, Kamil Rytarowski wrote: >>>>> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >>>>>> On 06/07/18 11:32, Kamil Rytarowski wrote: >>>>>>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >>>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >>>>>>>> >>>>>>>> --- Comment #2 from Richard Earnshaw --- >>>>>>>> I'm not sure how relevant the netbsd-elf port is these days. I >>>>>>>> believe they've >>>>>>>> now moved onto an EABI based ABI. But no GCC port of that has been >>>>>>>> contributed. >>>>>>>> >>>>>>> >>>>>>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A >>>>>>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre >>>>>>> ARMv4 CPUs use OABI only. >>>>>>> >>>>>> >>>>>> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >>>>>> marked as deprecated for about 3 years now. >>>>>> >>>>> >>>>> We verify these ports on real hardware. >>>>> >>>>> NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is >>>>> obsoleting it and surprisingly LLVM soon might have support for a wider >>>>> range of ARM CPUs. >>>>> >>>> >>>> Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, >>>> but it is considered deprecated these days. >>>> >>> >>> Shark doesn't use all instructions that are generated by GCC (I forgot >>> the CPU property name of it) and thus it has to be switched to Clang/LLVM. >>> >> >> You're not making sense. Please be more explicit as to what you mean >> and give an example. GCC can generate instructions for ARMv4 and >> StrongARM (used by the shark) is an ARMv4 part. >> >> I've run gcc generated code on shark boards for years and not seen problems. >> >> R. >> > > I got a feedback that it's called: armv4t. > From whom? StrongARM is ARMv4. It is *not* ARMv4t as it does not support Thumb. Whatever, GCC can support both ARMv4 and ARMv4t. R.
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 --- Comment #1 from richard.earnshaw at arm dot com --- On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 > > Bug ID: 86904 >Summary: Column numbers ignore tab characters >Product: gcc >Version: unknown > Status: UNCONFIRMED > Keywords: diagnostic > Severity: normal > Priority: P3 > Component: other > Assignee: unassigned at gcc dot gnu.org > Reporter: dmalcolm at gcc dot gnu.org > Target Milestone: --- > > As noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c21 : > > /* Both gcc and emacs number source *lines* starting at 1, but >they have differing conventions for *columns*. > >GCC uses a 1-based convention for source columns, >whereas Emacs's M-x column-number-mode uses a 0-based convention. > >For example, an error in the initial, left-hand >column of source line 3 is reported by GCC as: > > some-file.c:3:1: error: ...etc... > >On navigating to the location of that error in Emacs >(e.g. via "next-error"), >the locus is reported in the Mode Line >(assuming M-x column-number-mode) as: > > some-file.c 10% (3, 0) > >i.e. "3:1:" in GCC corresponds to "(3, 0)" in Emacs. */ > > In terms of 0 vs 1, GCC complies with the GNU standards here: > https://www.gnu.org/prep/standards/html_node/Errors.html > > However our "column numbers" are also simply a 1-based byte-count, so a tab > character is treated by us as simply an increment of 1 right now. > > (see also PR 49973, which covers the case of multibyte characters). > > It turns out that we convert tab characters to *single* space characters when > printing source code. > > This behavior has been present since Manu first implemented > -fdiagnostics-show-caret in r186305 (aka > 5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985), where it was this logic > (there in diagnostic.c's diagnostic_show_locus): > char c = *line == '\t' ? ' ' : *line; > pp_character (context->printer, c); > > (that logic is now in diagnostic-show-locus.c in layout::print_source_line) > > This is arguably a bug, but it's intimately linked to the way in which we > track > "column numbers". > > Our "column numbers" are currently simply a 1-based byte-count, I believe, so > a > tab character is treated by us as simply an increment of 1 right now. > > There are similar issues with encodings that aren't 1 byte per character (e.g. > non-ASCII unicode characters), which are being tracked in PR 49973. > > Presumably, when we print source lines containing tab characters, we should > emit a number of spaces to reach a tab stop. > > Consider a diagnostic with a multiline range covering the > following source (and beyond): > > indent: 6 (tabs: 0, spaces: 6) >indent: 7 (tabs: 0, spaces: 7) > indent: 8 (tabs: 1, spaces: 0) > indent: 9 (tabs: 1, spaces: 1) > > i.e.: > > " indent: 6 (tabs: 0, spaces: 6)\n" > " indent: 7 (tabs: 0, spaces: 7)\n" > "\tindent: 8 (tabs: 1, spaces: 0)\n" > "\t indent: 9 (tabs: 1, spaces: 1)\n" > > Currently diagnostic_show_locus prints: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ >indent: 9 (tabs: 1, spaces: 1) >~~ > > i.e: > " indent: 6 (tabs: 0, spaces: 6)\n" > " ~~\n" > "indent: 7 (tabs: 0, spaces: 7)\n" > "~~\n" > " indent: 8 (tabs: 1, spaces: 0)\n" > " ~~\n" > " indent: 9 (tabs: 1, spaces: 1)\n" > " ~~\n" > > which misrepresents the indentation of the user's code. > > It should respect tabstops, and print: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ > indent: 9 (tabs: 1, spaces: 1) > ~~~
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #53 from richard.earnshaw at arm dot com --- On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 > > --- Comment #52 from Bernd Edlinger --- > (In reply to wilco from comment #51) >> >> Indeed, that's the reason behind the existing check. However it disables all >> profitable bswap cases while still generating unaligned accesses if no bswap >> is needed. So I am looking for a callback that gives the correct answer. It >> would need to check -mno-unaligned-access and the target capabilities (eg. >> if unaligned accesses are supported in hardware but really expensive we want >> to avoid them). > > Yes. I think ARM is becoming a non-strict-alignment platform. > While x86_64 is moving in the opposite direction. It can never be a non-strict alignment platform while some memory access instructions do not support unaligned accesses. However, it is progressively becoming a less slow unaligned access platform. R.
[Bug target/43872] VLAs are not aligned correctly on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43872 --- Comment #6 from richard.earnshaw at arm dot com 2011-04-23 08:37:21 UTC --- I shall be out of the office until Tuesday 3rd May and will not have email access during most of that time, so I will read your message when I return. For urgent managerial issues please contact Roger Teague. For internal engineering issues please contact Matthew Gretton-Dann.
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #10 from richard.earnshaw at arm dot com 2010-10-08 12:53:40 UTC --- I shall be out of the office from Monday 11 October until Monday 1 November; I will not have email access during most of that time, so I will read your message when I return. For urgent issues, please contact Roger Teague or Matthew Gretton-Dann.
