Enquiry

Enquiry

[Vijay Holimath]

Dear Sir,

        I am using gcc compiler for v850e cpu. When I use the 
arrtribute: __attribute__ ((interrupt_handler)) or __attribute__ 
((interrupt); for interrupt function,  say for example

void swnmi() __attribute__ ((interrupt_handler));

void swnmi()
{
...
..
}

main()
{
..
..
}

I am getting following error messages when I compile:

main.o (.text+0xea): In function 'swnmi': undefined reference to '__ep'

main.o (.text+0xee): In function 'swnmi': undefined reference to '__ep'

collect2: Id returned 1 exit status


I will be grateful to you if you could help me to get rid of these error 
messages.  Probably I have to link some libraries?


Many thanks,
-Vijay

-- 
Vijay Holimath, Ph.D
National Institute of Informatics
2-1-2 Hitotsubashi Chiyoda-ku 
Tokyo 101-8430, Japan
Tel: +81-3-4212-2662 |Fax:+81-3-3556-1916
Mobile: +81-80-3542-1560
e-mail: vijay@nii.ac.jp
http://www.linkedin.com/in/vijayholimath
Skype name: vijay.holimath 

Re: Enquiry

[Vijay]

Thanks for the response Mukti.  I think the options could be: 
|-mlong-calls -mno-ep and ||-mno-prolog-function. Could please tell me 
how to sepcify these options in makefile?  Because I use gmake (in 
Cygwin shell)

Thanks,
-Vijay



|
mukti jain wrote:
> Can you experiment with optionmization options and -m850 and -m850e?
> have a look at this too if you are looking for quick fix.
>  http://sourceware.org/ml/binutils/2005-08/msg00214.html
>
> Thanks,
> Mukti
>
> On Tue, Jun 2, 2009 at 11:18 PM, mukti jain <muktijn@gmail.com 
> <mailto:muktijn@gmail.com>> wrote:
>
>
>
>     On Tue, Jun 2, 2009 at 7:22 PM, Vijay Holimath <vijay@nii.ac.jp
>     <mailto:vijay@nii.ac.jp>> wrote:
>
>         Dear Sir,
>
>               I am using gcc compiler for v850e cpu. When I use the
>         arrtribute: __attribute__ ((interrupt_handler)) or
>         __attribute__ ((interrupt); for interrupt function,  say for
>         example
>
>         void swnmi() __attribute__ ((interrupt_handler));
>
>         void swnmi()
>         {
>         ...
>         ..
>         }
>
>         main()
>         {
>         ..
>         ..
>         }
>
>         I am getting following error messages when I compile:
>
>         main.o (.text+0xea): In function 'swnmi': undefined reference
>         to '__ep'
>
>         main.o (.text+0xee): In function 'swnmi': undefined reference
>         to '__ep'
>
>         collect2: Id returned 1 exit status
>
>
>         I will be grateful to you if you could help me to get rid of
>         these error messages.  Probably I have to link some libraries?
>
>     No, __ep is a linker variable.
>
>         man page says..
>     (http://ftp.gnu.org/pub/pub/old-gnu/Manuals/gas-2.9.1/html_chapter/as_24.html)
>
>         This can either be set up automatically by the linker, or
>         specifically set by using the -defsym __ep=<value> command
>         line option].
>
>
>
>     Thanks,
>     Mukti
>
>
>
>         Many thanks,
>         -Vijay
>
>         -- 
>         Vijay Holimath, Ph.D
>         National Institute of Informatics
>         2-1-2 Hitotsubashi Chiyoda-ku Tokyo 101-8430, Japan
>         Tel: +81-3-4212-2662 |Fax:+81-3-3556-1916
>         Mobile: +81-80-3542-1560
>         e-mail: vijay@nii.ac.jp <mailto:vijay@nii.ac.jp>
>         http://www.linkedin.com/in/vijayholimath
>         Skype name: vijay.holimath
>
>
>

Enquiry

[Theodore Papadopoulo]

Before creating a bug report, I want to check with the GCC community 
(all the more that checking that the problem has not yet been reported 
is complicated at leat for me).

The following (admitedly buggy) program generates a segmentation 
violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 
11.2.1-7) (GCC))
when compiled with -O3 (other versions replacing unisgned by std::string 
may trigger the exception instead of the segv)

bool assert_sthg(const unsigned s) {
     if (s==123)
         throw 1;
}

int main() {
     assert_sthg(0);
     return 0;
}

When compiling, we indeed get a warning:

test.C:4:1: warning: control reaches end of non-void function 
[-Wreturn-type]

I can well understand that the program being buggy that the optimizer is 
allowed to do anything including the observed segmentation violation.
Yet the result is quite surprising....
The question is, in that case, wouldn't it be better to turn the warning 
into an error at -O3 ?

     Thank's for any input.

         Theo.

Re: Enquiry

[Jakub Jelinek]

On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> Before creating a bug report, I want to check with the GCC community (all
> the more that checking that the problem has not yet been reported is
> complicated at leat for me).
> 
> The following (admitedly buggy) program generates a segmentation violation
> on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string may
> trigger the exception instead of the segv)
> 
> bool assert_sthg(const unsigned s) {
>     if (s==123)
>         throw 1;
> }
> 
> int main() {
>     assert_sthg(0);
>     return 0;
> }
> 
> When compiling, we indeed get a warning:
> 
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> 
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising....

Undefined behavior can have any kind of surprising behavior.

> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?

No, it can't be an error by default, it is undefined behavior only at
runtime, if you never call the function or always call it with
assert_sthg(123), then the program can be valid.

	Jakub

Re: Enquiry

[Jonathan Wakely]

On Sun, 30 Jan 2022, 10:42 Jakub Jelinek via Gcc, <gcc@gcc.gnu.org> wrote:

> On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> > Before creating a bug report, I want to check with the GCC community (all
> > the more that checking that the problem has not yet been reported is
> > complicated at leat for me).
> >
> > The following (admitedly buggy) program generates a segmentation
> violation
> > on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> > when compiled with -O3 (other versions replacing unisgned by std::string
> may
> > trigger the exception instead of the segv)
> >
> > bool assert_sthg(const unsigned s) {
> >     if (s==123)
> >         throw 1;
> > }
> >
> > int main() {
> >     assert_sthg(0);
> >     return 0;
> > }
> >
> > When compiling, we indeed get a warning:
> >
> > test.C:4:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
> > I can well understand that the program being buggy that the optimizer is
> > allowed to do anything including the observed segmentation violation.
> > Yet the result is quite surprising....
>
> Undefined behavior can have any kind of surprising behavior.
>
> > The question is, in that case, wouldn't it be better to turn the warning
> > into an error at -O3 ?
>
> No, it can't be an error by default, it is undefined behavior only at
> runtime, if you never call the function or always call it with
> assert_sthg(123), then the program can be valid.
>

We could put a trap instruction at the end of the function though, which
would make the result a bit less arbitrary.

I've come around to thinking that's preferable for cases like this.

Re: Enquiry

[Jakub Jelinek]

On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
> We could put a trap instruction at the end of the function though, which
> would make the result a bit less arbitrary.
> 
> I've come around to thinking that's preferable for cases like this.

Depends on which exact cases.
Because for
int foo (int s) { if (s == 123) return 1; }
we want to optimize it into
return 1;
rather than if (s == 123) return 1; else __builtin_trap ();
For debugging we have -fsanitize=undefined

	Jakub

Re: Enquiry

[Jonathan Wakely]

On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, <jakub@redhat.com> wrote:

> On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
> > We could put a trap instruction at the end of the function though, which
> > would make the result a bit less arbitrary.
> >
> > I've come around to thinking that's preferable for cases like this.
>
> Depends on which exact cases.
> Because for
> int foo (int s) { if (s == 123) return 1; }
> we want to optimize it into
> return 1;
> rather than if (s == 123) return 1; else __builtin_trap ();
> For debugging we have -fsanitize=undefined


What if we inserted the trap for -O0?

1. Not everybody uses ubsan even when they should use it.

2. The code can use unreachable annotations if it really needs to leave
some paths unhandled, but really can't live with the branch and trap
instructions. (The C++ standard is getting std::unreachable and std::assume
to do that in a portable way, so there is less excuse for not doing it).

Re: Enquiry

[Jakub Jelinek]

On Sun, Jan 30, 2022 at 11:11:15AM +0000, Jonathan Wakely wrote:
> On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, <jakub@redhat.com> wrote:
> 
> > On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
> > > We could put a trap instruction at the end of the function though, which
> > > would make the result a bit less arbitrary.
> > >
> > > I've come around to thinking that's preferable for cases like this.
> >
> > Depends on which exact cases.
> > Because for
> > int foo (int s) { if (s == 123) return 1; }
> > we want to optimize it into
> > return 1;
> > rather than if (s == 123) return 1; else __builtin_trap ();
> > For debugging we have -fsanitize=undefined
> 
> 
> What if we inserted the trap for -O0?

Adding a trap for -O0 looks reasonable to me, after all, we aren't going to
do too many optimizations with __builtin_unreachable at -O0 anyway.

	Jakub

Re: Enquiry

[Andreas Schwab]

On Jan 30 2022, Jonathan Wakely via Gcc wrote:

> On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, <jakub@redhat.com> wrote:
>
>> On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
>> > We could put a trap instruction at the end of the function though, which
>> > would make the result a bit less arbitrary.
>> >
>> > I've come around to thinking that's preferable for cases like this.
>>
>> Depends on which exact cases.
>> Because for
>> int foo (int s) { if (s == 123) return 1; }
>> we want to optimize it into
>> return 1;
>> rather than if (s == 123) return 1; else __builtin_trap ();
>> For debugging we have -fsanitize=undefined
>
>
> What if we inserted the trap for -O0?

Note that in C it is not an error to fall through the end of a non-void
function if the caller does not use the return value.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Enquiry

[Jonathan Wakely]

On Mon, 31 Jan 2022 at 10:25, Andreas Schwab wrote:
>
> On Jan 30 2022, Jonathan Wakely via Gcc wrote:
>
> > On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, <jakub@redhat.com> wrote:
> >
> >> On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
> >> > We could put a trap instruction at the end of the function though, which
> >> > would make the result a bit less arbitrary.
> >> >
> >> > I've come around to thinking that's preferable for cases like this.
> >>
> >> Depends on which exact cases.
> >> Because for
> >> int foo (int s) { if (s == 123) return 1; }
> >> we want to optimize it into
> >> return 1;
> >> rather than if (s == 123) return 1; else __builtin_trap ();
> >> For debugging we have -fsanitize=undefined
> >
> >
> > What if we inserted the trap for -O0?
>
> Note that in C it is not an error to fall through the end of a non-void
> function if the caller does not use the return value.

Indeed. Theo's program is undefined in C++ and valid in C.

I would love to see the trap inserted for C++ though.

Re: Enquiry

[Theodore Papadopoulo]

On 1/30/22 11:58, Jakub Jelinek wrote:
> On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
>> We could put a trap instruction at the end of the function though, which
>> would make the result a bit less arbitrary.
>>
>> I've come around to thinking that's preferable for cases like this.
> Depends on which exact cases.
> Because for
> int foo (int s) { if (s == 123) return 1; }
> we want to optimize it into
> return 1;
> rather than if (s == 123) return 1; else __builtin_trap ();
> For debugging we have -fsanitize=undefined
>
> 	Jakub
>
I understand completely, it is undefined behaviour.  What I had not 
realized is that undefined behaviour
is not a property of the function itself, but of the function call when 
parameters are specified. That seems
more difficult to handle from the compiler perspective, but if that is 
the rule, so be it...

It seems to me that this is a case that just makes things more 
complicated for programmers (and compiler developers) for the benefit
of only a small community which will know the precise limits of the 
undefined behaviour and would like to play at the boundary of the cliff.
Honestly, for the user perspective (or more exactly a majority of 
users), it would be nice if there was a way to catch such situations at
compile time (making of course more strict assumptions on the compiler 
side). Of course, I can fire gdb or -fsanitize=undefined, but
whatever can be caught earlier is better.... I will turn that specific 
warning into a an error with -Werrror=XXX for my own usage.

Thank's for the explanations. At least, I learned something. Hope I did 
not waste too much of your time.

     Theo.

Re: Enquiry

[Jonathan Wakely]

On Mon, 31 Jan 2022 at 10:16, Theodore Papadopoulo wrote:
>
> On 1/30/22 11:58, Jakub Jelinek wrote:
> > On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
> >> We could put a trap instruction at the end of the function though, which
> >> would make the result a bit less arbitrary.
> >>
> >> I've come around to thinking that's preferable for cases like this.
> > Depends on which exact cases.
> > Because for
> > int foo (int s) { if (s == 123) return 1; }
> > we want to optimize it into
> > return 1;
> > rather than if (s == 123) return 1; else __builtin_trap ();
> > For debugging we have -fsanitize=undefined
> >
> >       Jakub
> >
> I understand completely, it is undefined behaviour.  What I had not
> realized is that undefined behaviour
> is not a property of the function itself, but of the function call when
> parameters are specified. That seems
> more difficult to handle from the compiler perspective, but if that is
> the rule, so be it...
>
> It seems to me that this is a case that just makes things more
> complicated for programmers (and compiler developers) for the benefit
> of only a small community which will know the precise limits of the
> undefined behaviour and would like to play at the boundary of the cliff.

No, not really. You're looking at a very simple example, but the
general case can be much more complicated, and undecidable by the
compiler.

The rules of the standard tend to be consistent, and not depend on how
close the compiler can get to solving the halting problem. If there is
a possible set of arguments to the function that avoids undefined
behaviour, the compiler assumes the user only plans to use those
arguments, and so will only warn and not give an error. Otherwise
valid programs would be rejected.


> Honestly, for the user perspective (or more exactly a majority of
> users), it would be nice if there was a way to catch such situations at
> compile time (making of course more strict assumptions on the compiler
> side).

How can the compiler tell the difference between "the user forgot to
handle a case" and "the user knows this case cannot happen and doesn't
need to be handled"?

Re: Enquiry

[Jonathan Wakely]

Meta-comment: a subject line of "Enquiry" is very vague, and most commonly
used by spammers and phishers. Your enquiry is about undefined behaviour
due to a missing return, which would have been a much better subject.




On Sun, 30 Jan 2022, 09:48 Theodore Papadopoulo, <
Theodore.Papadopoulo@inria.fr> wrote:

> Before creating a bug report, I want to check with the GCC community
> (all the more that checking that the problem has not yet been reported
> is complicated at leat for me).
>
> The following (admitedly buggy) program generates a segmentation
> violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat
> 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string
> may trigger the exception instead of the segv)
>
> bool assert_sthg(const unsigned s) {
>      if (s==123)
>          throw 1;
> }
>
> int main() {
>      assert_sthg(0);
>      return 0;
> }
>
> When compiling, we indeed get a warning:
>
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising....
> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?
>
>      Thank's for any input.
>
>          Theo.
>
>

Re: Enquiry

[Theodore Papadopoulo]

On 1/30/22 12:17, Jonathan Wakely wrote:
> Meta-comment: a subject line of "Enquiry" is very vague, and most 
> commonly used by spammers and phishers. Your enquiry is about 
> undefined behaviour due to a missing return, which would have been a 
> much better subject.
Indeed. Did not realize that.

Will make more attention next time.

     Theo.

Enquiry

[Paul]

Hello,

We are interested in importing your products to Costa Rica.

Please send your product catalog to (epicroom@protonmail.com)
for further information.

Awaiting...

Regards,

Paul

Enquiry

[Vijay Holimath]

Dear Sir,

          I am using gcc compiler for v850e cpu. When I use the 
arrtribute: __attribute__ ((interrupt_handler)) or __attribute__ 
((interrupt); for interrupt function,  say for example

void swnmi() __attribute__ ((interrupt_handler));

void swnmi()
{
...
..
}

main()
{
..
..
}

 I am getting following error messages when I compile:

main.o (.text+0xea): In function 'swnmi': undefined reference to '__ep'

main.o (.text+0xee): In function 'swnmi': undefined reference to '__ep'

collect2: Id returned 1 exit status


I will be grateful to you if you could help me to get rid of these error 
messages.  Probably I have to link some libraries?


Many thanks,
-Vijay
 

Vijay Holimath, Ph.D
National Institute of Informatics
2-1-2 Hitotsubashi Chiyoda-ku 
Tokyo 101-8430, Japan
Tel: +81-3-4212-2662 |Fax:+81-3-3556-1916
Mobile: +81-80-3542-1560
e-mail: vijay@nii.ac.jp
http://www.linkedin.com/in/vijayholimath
Skype name: vijay.holimath 

ENQUIRY

[Dr.Richard Lovward]

 
 

Hello,
It gives me a great deal of pleasure to write you this mail and even when it might come to you as a surprise, .I hope you find  it of interest.
Let me first introduce myself.  My name is Richard  Lovward, and I am an Executive Auditor with an Auditing and Risk Management Firm, here  in   Europe ,  I should like to  use this means to ask your assistance  in moving some fund over to your country. I have in the course of my duties come in contact with a good amount of Fund that have been inactive for some years now and careful investigation proved the original depositor of the fund  died five years ago  and all attempt to reach the suppose beneficiary of the deposit were fruitless and before it is forfeited to the state I decided to move it.
It is of interest to inform you  also that I have already moved this fund out of the Establishment  and now in safe keeping with a Finance and security house,  I will  like to move it outside now.and this is were I need your your assistance.
After legal consultation, I have established  modalities for a  secured way for  a perfect transaction., but be most assured that  for your  assistance and partnership  you will get a  good percentage of the fund, it is  important  to let you know that fifty percent of  the rest will be invested over there under your management. for a negotiable  period of time and we will open a fruitful dialog very soon to that effect.
I  look forward to our working closely in practically  seeing this transaction come to a perfect end.  For effective communication , please kindly include  in your reply, your complete Names ,Address,Occupation, Age  and most especially your contact number. and I will contact you as soon as I get your reply.
I  look forward to hearing from you and  my gratitude for your Patience
Respectfully yours
Dr. Richard  Lovward

enquiry

[Adarsh MP]

I am Adarsh. I am doing my masters in Computers, at Bradley Univ. I am now in the midst of developing a project, ie. simulation of an operating system shell. I am facing the problem with GCC compiler. I am not able to use the command getch() even though it is specified in help. 
  i am trying to use it coz i have to accept the passwords from the user without echoing it. Can u plz suggest me a method
thanking u
Adarsh

_________________________________________________
Get Your Free Email At, http://www.rediffmail.com

For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html

Re: enquiry

[Erik Mouw]

On 22 Sep 2000 03:23:25 -0000, Adarsh MP wrote:
> I am Adarsh. I am doing my masters in Computers, at Bradley Univ. I am now in
> the midst of developing a project, ie. simulation of an operating system shell.
> I am facing the problem with GCC compiler. I am not able to use the command
> getch() even though it is specified in help. 

This is actually the wrong mailing list, this list is about the
development of GCC itself.

>   i am trying to use it coz i have to accept the passwords from the user
> without echoing it. Can u plz suggest me a method
> thanking u

The getch() function is not a standard libc function. The correct way
depends on your target system. If you're using a UNIX like system, the
proper way is to use the function getpass(), or build such a function
yourself by using select() and read() on stdin.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/