stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-939) [aCC 3.63/HP-UX 11.11] SEGV when comparing pointers.
Date Wed, 21 May 2008 18:31:55 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598741#action_12598741
] 

Martin Sebor commented on STDCXX-939:
-------------------------------------

Here's what HP says:

{quote}
-------- Original Message --------
Subject: Re:  aCC 3.73 SIGSEGV comparing function pointers
Date: Fri, 16 May 2008 17:03:30 -0700 (PDT)
From: Dennis Handly <dhandly AT cup DO hp DOT com>
To: acxx AT cup DOT hp DOT com, sebor AT roguewave DOT com

>From: Martin Sebor <sebor@roguewave.com>
>Here's a test case for for a problem on PA we just ran into, distilled
>from our implementation of signal handlers where f is the rough
>equivalent of SIG_IGN (I know it's defined differently on HP-UX).

That's the problem.  The only values you can have for pointers to functions
are real pointers and the ones defined in <signal.h>.  All others are
illegal.

I've seen this issue years and years ago.  There used to be millicode
that would do bunch of mickey mouse to compare pointers.

This was mysteriously removed without discussion, in the backend.
So both C and C++ fail.

The last time it was brought up, I think they fixed the case of a
constant but you have stored it into a variable.  (So only +O3 will work.)
You can of course (illegally) cast them both to void* and compare.

{noformat}
#ifdef __cplusplus
extern "C" {
#endif
typedef void F(int);
void bar(int p) {}
#ifdef __cplusplus
} // extern "C"
#endif
int main() {
   F* const f = (F*)-2;
#ifdef WORK
   return (F*)-2 == bar;
#else
   return f == bar;
#endif
}
{noformat}
{quote}

> [aCC 3.63/HP-UX 11.11] SEGV when comparing pointers.
> ----------------------------------------------------
>
>                 Key: STDCXX-939
>                 URL: https://issues.apache.org/jira/browse/STDCXX-939
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: External
>         Environment: HP-UX B.11.11 U
> aCC: HP ANSI C++ B3910B A.03.63 
>            Reporter: Travis Vitek
>             Fix For: 4.2.2
>
>
> {noformat}
> $ cat t.cpp; aCC -g t.cpp; ./a.out
> typedef void user_proc_t (int);
> user_proc_t* const _sentinel_proc = (user_proc_t*)-2;
> void my_user_proc (int)
> {
> }
> int main ()
> {
>     return my_user_proc != _sentinel_proc;
> }
> Segmentation fault (core dumped)
> [vitek@jenga tests]$ gdb a.out
> HP gdb 5.0 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
> and target hppa1.1-hp-hpux11.00.
> Copyright 1986 - 2001 Free Software Foundation, Inc.
> Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
> GNU General Public License. Type "show copying" to see the conditions to
> change it and/or distribute copies. Type "show warranty" for warranty/support.
> ..
> (gdb) run
> Starting program: /build/vitek/4.2.2/12s/tests/a.out 
> Program received signal SIGSEGV, Segmentation fault
>   si_code: 0 - SEGV_UNKNOWN - Unknown Error.
> 0x2dac in main () at t.cpp:11
> 11          return my_user_proc != _sentinel_proc;
> (gdb) where
> #0  0x2dac in main () at t.cpp:11
> (gdb) disassemble
> Dump of assembler code for function main:
> ;;; File: t.cpp
> ;;;  10 {
> 0x2d54 <main>:  nop
> 0x2d58 <main+0x4>:      stw %rp,-0x14(%sp)
> 0x2d5c <main+0x8>:      ldo 0x40(%sp),%sp
> 0x2d60 <main+0xc>:      call 0x2d44 <_main>
> 0x2d64 <main+0x10>:     nop
> ;;;  11     return my_user_proc != _sentinel_proc;
> 0x2d68 <main+0x14>:     addil L'-0x800,%dp,%r1
> 0x2d6c <main+0x18>:     ldw 0x700(%r1),%r31
> 0x2d70 <main+0x1c>:     addil L'-0x800,%dp,%r1
> 0x2d74 <main+0x20>:     ldw 0x768(%r1),%r19
> 0x2d78 <main+0x24>:     copy %r31,%r20
> 0x2d7c <main+0x28>:     extrw,u %r31,31,2,%r21
> 0x2d80 <main+0x2c>:     cmpib,<>,n 2,%r21,0x2d94 <main+0x40>
> 0x2d84 <main+0x30>:     ldi 0x1000,%r22
> 0x2d88 <main+0x34>:     cmpb,<<,n %r31,%r22,0x2d94 <main+0x40>
> 0x2d8c <main+0x38>:     depw %r0,31,2,%r20
> 0x2d90 <main+0x3c>:     ldw 0(%r20),%r20
> 0x2d94 <main+0x40>:     copy %r19,%r1
> 0x2d98 <main+0x44>:     extrw,u %r19,31,2,%r31
> 0x2d9c <main+0x48>:     cmpib,<>,n 2,%r31,0x2db0 <main+0x5c>
> 0x2da0 <main+0x4c>:     ldi 0x1000,%r21
> 0x2da4 <main+0x50>:     cmpb,<<,n %r19,%r21,0x2db0 <main+0x5c>
> 0x2da8 <main+0x54>:     depw %r0,31,2,%r1
> 0x2dac <main+0x58>:     ldw 0(%r1),%r1
> 0x2db0 <main+0x5c>:     cmpclr,= %r20,%r1,%r22
> 0x2db4 <main+0x60>:     ldi 1,%r22
> 0x2db8 <main+0x64>:     depw,z %r22,31,1,%ret0
> ;;;  12 }
> 0x2dbc <main+0x68>:     copy %ret0,%ret0
> 0x2dc0 <main+0x6c>:     ldw -0x54(%sp),%rp
> 0x2dc4 <main+0x70>:     ret 
> 0x2dc8 <main+0x74>:     ldo -0x40(%sp),%sp
> End of assembler dump.
> (gdb) 
> {noformat}
> I've checked and I get the same failure with aCC 3.73 also, but not with aCC 6.16

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message