Re: [Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf

2005-11-23 Thread Richard Earnshaw
On Wed, 2005-11-23 at 14:28, joseph at codesourcery dot com wrote:

> In that case the obvious solution is for the NetBSD configuration to start 
> using that one function from ieee754-df.S.  (I checked that the 
> implementations in GCC of __float* already had corresponding 
> implementations of __floatun* as required - missing rs6000/ppc64-fp.c in 
> the process - but couldn't check for any case where these functions came 
> from libc.)

Not that simple, because the implementation of __floatunsidf is tightly
integrated with the implementation of __adddf3.  And we don't want to
override that because the ieee754-df.S implementation does not support
raising signals.

R.


Re: (ARM) Wrong conditional codes when paired with tst instruction

2019-10-19 Thread Richard Earnshaw
On 18/10/2019 19:43, AlwaysTeachingable . wrote:
> The following C code:
> unsigned int wrong(unsigned int n){
> return (n%2) ? 0 : 42;
> }
> 
> should return 42 when n is odd and 0 when n is even.

No.  Your code returns 42 when n is even.

It's equivalent to "return ((n%2) != 0) ? 0 : 42;"

Now it's more obvious that when n is odd the expression is true so
returns 0.


> 
> But ARM gcc 8.2 with -O3 produces following assembly:
> 
> tst r0, #1
> moveq r0, #42
> movne r0, #0
> bx lr

Which, of course, is exactly what your source code asked for.


> 
> tst r0,#1 sets Z=1 iff r0 is even, and moveq r0,#42 executes iff Z=1,
> therefore
> it sets r0 to 42 when r0 is even, which is wrong given the C code above (
> it should return 0 ).
> 

R.


Re: Suggestions welcomed to get bootstrap to work

2014-11-05 Thread Richard Earnshaw
You would probably be better of discussing this on gcc-help.  gcc-bugs
is rather full of bugzilla traffic and normal mails are easily missed.

Have you tried setting CONFIG_SHELL in the environment?  Also, when
running the build use something like

make SHELL=/bin/bash

R.

On 03/11/14 20:22, Michael Felt wrote:
> What I have not yet found is how to get the SHELL variable to not use
> /bin/sh because this is causing a failure immediately at the start of
> make:
> 
> root@x064:[/data/prj/gnu/gcc/objdir/gcc-4.7.4]make
> [ -f stage_final ] || echo stage3 > stage_final
> /bin/sh[3]: 0403-057 Syntax error at line 1 : `-qlanglvl=extc89' is
> not expected.
> make: *** [all] Error 2
> 
> Setting a link from /bin/sh to "bash" is just a way of breaking the
> host. I hope there is be a normal way to resolve this.
> 
> regards,
> Michael
> 
> p.s. 4.5.4 fails elsewhere - it does not come as far as 4.7.4 or 4.6.4
> 
> On Mon, Nov 3, 2014 at 9:19 PM, Michael Felt  wrote:
>> I fear that after being set to "wontfix" an entry such as
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 will be completely
>> ignored.
>>
>>
>> That is not what I was expecting having spent nearly 8 hours yesterday
>> looking for something I may have missed.
>>
>> I do not understand how to move forward from: Don't bootstrap GCC with
>> IBM XLC. - considering that is the compiler I have.
>>
>> As I commented in the "bug" above, there are issues I have run into
>> with gcc from other sources. If it turns out there is no other way,
>> then that shall be the path forced upon me - but I prefer to research
>> and package my own so that the demands on the host finally get
>> documented - rather than libraries that step on each other and damage
>> existing programs.
>>
>> That my submission is on the "bug-list" is because that is what seemed
>> to be the correct path to submit a question. That gcc decides to never
>> include any result in the source tree is of course your choice.
>>
>> I merely wish to express my hope for some sort of assistance in moving
>> forward versus a stonewall of "don't care".
>>
>> FYI: I am trying 4.5.4 now as well, but I fear the same result.
>>
>> Maybe it is just a shell thing (e.g. needs a specific bash behavior)
>>
>> I shall continue to post, suggestions welcome.
>>
>> Michael




Re: [Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames

2004-12-13 Thread Richard Earnshaw
On Mon, 2004-12-13 at 15:28, opensource at artnaseef dot com wrote:
> --- Additional Comments From opensource at artnaseef dot com  2004-12-13 
> 15:28 ---
> Subject: Re:  Profiling optimized code causes segfaults on
>  ARM due to missing frames
> 
> Two things
> 
>   1. Why do you not think the  patch is correct?  It works great for 
> me.  Without
>  that information, I can only respond with "I think you are wrong," 
> and that
>  is not productive.
> 
Because I don't think profiling should need the a frame pointer to
work.  If it does, then my feeling is that it's the profiling code
that's broken, not the compiler.  The layout of a stack frame is private
to the function that built it, and any code outside of that function
that tries to probe it is simply broken.

>   2. The comment in the patch you show is that the Profiler clobbers the 
> Link
>  Register.  That is NOT this problem.
> 

Well, that patch was never applied to the 3.3 branch.  The bug it refers
to was reported against 3.0, so there's a strong likelihood that it will
be needed in 3.3 as well.

> In this problem, the profiler causes a segmentation fault when it reads 
> the wrong
> return address off the stack and uses it as an invalid function 
> address.  It does
> not use the link register value.
> 
> To reproduce the problem:
> 
>   - Build an arm-linux toolchain
> 
>   - Compile a program with optimization and profiling (try -O2 and -pg).
> 
>  - Make sure the program includes a function for which the optimizer
>drops its frame pointer (this can easily be verified by looking at
>the assembly output of the compiler).
> 
>   - Run the program.
> 
> If a trace is needed, I will be able to produce one within a few days
> and provide an example.  Note that this problem was quite easy for me
> to reproduce, so I would expect reproducing it to be simple enough for
> others.

I'm not in the business of trying to second guess how you encountered a
problem.  If you want us to investigate a bug then you need to send us
precise instructions (including source code) so that we can reproduce
it.


Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

2018-07-06 Thread Richard Earnshaw (lists)
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.


Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

2018-07-06 Thread Richard Earnshaw (lists)
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.


Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

2018-07-10 Thread Richard Earnshaw (lists)
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.


Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

2018-07-11 Thread Richard Earnshaw (lists)
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.


Re: [Bug other/86904] New: Column numbers ignore tab characters

2018-08-10 Thread Richard Earnshaw (lists)
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)
>   ~~
> 
> 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"
> 
> We should also handle erroneous leading spaces before a tab, so that e.g.
> 
>   "  \tfoo"
> 
> should be printed as if it were:
> 
>  "\tfoo"
> 
> (given that that's what the user's editor is probably printing it as).
> 
> Similarly, we should presumably print "8" for the column number for the '

Re: [Bug target/77308] surprisingly large stack usage for sha512 on arm

2016-11-02 Thread Richard Earnshaw (lists)
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.