From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, September 26, 2013 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Re: Looking for help with an obscure C integer problem
Hello,
I told you at end of July that an IBM employ
..."
Would work for me anyway.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, September 26, 2013 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Re: Looking for help with an obscure C int
with an obscure C integer problem
Datum: Sat, 27 Jul 2013 21:11:38 +0200
Von:Bernd Oppolzer
An: IBM Mainframe Discussion List
Hello,
I would like to tell you about the steps needed until I discovered the
HGPR option as the source of the problem.
First I tried the function below, but
me Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Sunday, July 28, 2013 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Sounds almost like we work for the same company. It is all about cost,
nothing about quality. This is w
Excellent work Bernd!
-Steve Comstock
On 7/27/2013 10:07 AM, Bernd Oppolzer wrote:
I was able to reproduce the problem with a little test program:
#include
#include
static void longtest (long long lwert)
{
int test;
test = lwert & 0xLL;
if (test != 0)
{
In <001001ce8b97$9def20a0$d9cd61e0$@mcn.org>, on 07/28/2013
at 09:37 AM, Charles Mills said:
>Here was the first battle I had to fight. The program in question is
>a STC that installs exits and so I implemented Signal handling so
>that in the event of a problem it could shut down gracefully. T
In <3399683725614169.wa.paulgboulderaim@listserv.ua.edu>, on
07/27/2013
at 02:08 PM, Paul Gilmartin said:
>Thinking back on the recent "SR Policy" thread which I started,
>and to which you contributed, should the customer entertain the
>question, "...let me know what impact this issue ha
In <51f3e14d.20...@t-online.de>, on 07/27/2013
at 05:03 PM, Bernd Oppolzer said:
>don't know for C, but for problems or questions concerning the PL/1
>compiler, IBM support was always very responsive and helpful. That's
>my experience, at least.
My experience is that the quality of the suppor
izette
>
>-----Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Charles Mills
>Sent: Sunday, July 28, 2013 6:38 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Looking for help with an obscure C integer problem
>
>
Sounds almost like we work for the same company. It is all about cost,
nothing about quality. This is why Wintel is "the best thing in the
market".
On Jul 28, 2013 9:07 AM, "Bernd Oppolzer"
wrote:
> I understand Charles' attitude fully and respect it;
> it's driven by the experiences he made in
-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Okay, everyone is beating me up for not reporting this problem. Let me tell you
the story that put me off to PMRs.
In January of 2012 or so I sent a note to IBMMAIN saying that that CEE3DMP was
printing garbage and
I understand Charles' attitude fully and respect it;
it's driven by the experiences he made in the past.
I for myself have made other experiences, and so
for the moment I (still) act differently, but that is subject
to change in the future, too.
I would like to tell you about a talk I had with th
y not sufficiently cost/benefit
effective to work for me.
Thanks for listening.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Saturday, July 27, 2013 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Look
On Sat, 27 Jul 2013 14:59:15 -0500, Ed Gould wrote:
>
>This is in my opinion a fuzzy error. Where the C issue is a classic
>bug(probably) your SR Policy is a gray area and it is harder to
>define a right/wrong answer (although probably you are right).
>Spelling & such is a issue but not a real bug.
... he is in fact an IBM employee,
and we hopefully will be informed when there is a PTF for this problem ...
Thanks again
Bernd
Am 27.07.2013 23:07, schrieb Bernd Oppolzer:
Hello,
another follower of IBM main just informed me offline,
that he open a problem with IBM support and included my
Hello,
another follower of IBM main just informed me offline,
that he open a problem with IBM support and included my documentation.
So there is no need to discuss this further.
Thank you, kind regards
Bernd
Am 27.07.2013 21:11, schrieb Bernd Oppolzer:
So I think we will not do anything abo
On Jul 27, 2013, at 2:08 PM, Paul Gilmartin wrote:
Thinking back on the recent "SR Policy" thread which I started, and
to which
you contributed, should the customer entertain the question,
"...let me know
what impact this issue has on your day to day business...", or
should the
customer ex
-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote:
>Charles,
>
>You are a vendor and may have found a problem with the C integer process. It
>would be of benefit to the community when you fi
Hello,
I would like to tell you about the steps needed until I discovered the
HGPR option as the source of the problem.
First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply
printed the result, so there was no com
On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote:
>Charles,
>
>You are a vendor and may have found a problem with the C integer process. It
>would be of benefit to the community when you find something like this to
>report even if you do not get benefit directly.
>
>Instead you get an
ent: Saturday, July 27, 2013 7:22 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Looking for help with an obscure C integer problem
>
>last bug I reported I invested hours and hours and ultimately received zero
>benefit.
>
>Charles
>Composed on a mobile: please excuse my brev
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Saturday, July 27, 2013 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
last bug I reported I invested hours and hours and ultimately received zero
benefit.
Charles
Composed
I was able to reproduce the problem with a little test program:
#include
#include
static void longtest (long long lwert)
{
int test;
test = lwert & 0xLL;
if (test != 0)
{
printf ("lwert right = %x\n", test);
}
else
{
test = lwert >> 32;
p
don't know for C, but for problems or questions concerning
the PL/1 compiler, IBM support was always very responsive
and helpful. That's my experience, at least.
You could help them by isolating the problem with a small
test program (containing for example only this function and
a little main wit
ALUE,GNU_COMPUTEDGOTO,TRAILENUM,T
>> YPED
>> VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX,
>> NOC9
>> NOGNU_COMPLEX,GNU_SUFFIXIJ)
>>
>>
>> Charles
>> -Original Message-
>> From: IBM Mainframe Discussion List [mai
help with an obscure C integer problem
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
yford
Sent: Thursday, July 25, 2013 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
--
For IBM-MAIN subs
On 26/07/2013 8:36 AM, Bernd Oppolzer wrote:
I guess that LANGLVL(LONGLONG) is already in effect,
because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED);
if not, the compiler would not accept the long long declarations, I
guess,
and it handles the long long variables in the beginnin
uly 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest >> 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody en
gt; From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Sunday, July 21, 2013 8:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
>
> Here is exact cut and paste with zero
the error on the part of the optimizer could be:
an unsigned int value shifted right by 32 is always zero
(which is right, if there are no 64 bit values around,
but wrong in this case).
Could this be the reason for the optimizer deciding here
that the argument in this case will always be zero?
T
DS 0H
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut an
0H
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with z
ion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The c
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Monday, July 22, 2013 2:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I can see nothing obviously wrong with your code. Because the func
A.EDU
Sent: Monday, July 22, 2013 12:18:25 PM
Subject: Re: Looking for help with an obscure C integer problem
That is another case, because the right side operands are not ints.
For ints, I saw references that all operands are promoted to ints,
if they can be represented as an int (that is true for cha
That is another case, because the right side operands are not ints.
For ints, I saw references that all operands are promoted to ints,
if they can be represented as an int (that is true for chars, shorts etc.).
Don't know for sure about longs, for example; if long differs in size
from int, and t
.
- Original Message -
From: "Charles Mills"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sunday, July 21, 2013 1:26:54 PM
Subject: Re: Looking for help with an obscure C integer problem
You are 100% correct. You nailed it. Stroustrup p. 263: "If both operands
have arithmetic type, th
Before complaining somewhere about a compiler error,
I would strongly recommend to take a look at the assembly listing.
Not one look, but better: have another person take a second look.
It once happened to me that by looking at the assembly listing
I believed to see the evidence of a compiler erro
@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include
#include
#include
#include
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n >> 32;
printf( &quo
On Sun, 21 Jul 2013 17:03:55 -0400, John Gilmore wrote:
>
>
>It is at the compiler's and optimizer's discretion to decide the order
>of execution for code that the C++ standard does not specifically
>define. This includes overlapping execution.
>
>
>and this may be conceded. What is not "in the co
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Monday, July 22, 2013 4:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
On 22/07/2013 12:17 PM, Charles Mills wrote:
>
> #
C++ per OP.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of retired-mainfra...@q.com
Sent: Monday, July 22, 2013 6:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Are you
t of the assignment process, what purpose does the cast
> serve?
>
> - Original Message -
> From: "David Crayford"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Saturday, July 20, 2013 8:06:37 PM
> Subject: Re: [MVS-OE] Looking for help with an obscure C integer p
21, 2013 11:44:11 AM
Subject: Re: Looking for help with an obscure C integer problem
BTW:
I think I remember from an old book on C programming:
"if the target of an assignment is int, all operands on the right side
are converted to int - if the target of an assignment is long, all opera
I use them so that the reader of the code knows for certain sure that I did
intend to change from one precision to another, with possible loss of
information. Also, I like to compile with all messages enabled and still
get no warnings. I do a fair amount of "unnecessary" coding to get an RC of
0, r
ubject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should
cast to the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT
Are you coding in C or C++? static_cast is a C++ feature.
- Original Message -
From: "Charles Mills"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 5:36:01 PM
Subject: Re: Looking for help with an obscure C integer problem
Thanks. How would I solve this with a c
08X\n", b);
> LARL r1,F'26'
> Lr15,=V(PRINTF)(,r3,74)
> ST r1,#MX_TEMP1(,r13,152)
> ST r0,#MX_TEMP1(,r13,156)
> LA r1,#MX_TEMP1(,r13,152)
> BASR r14,r15
> * }
>
I can check.
regards, Tom
On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford
Subject: Re: [MVS-OE] Looking for help with an
obscure C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour
J.) wrote:
>In<51
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in
the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Look
Should be this way in a perfect world. But this reminds me of
the Pascal compiler on the IBM PC-RT (RS-6000 predecessor),
which produced correct results on opt level 0, incorrect results
on opt level 1 and a crashing program on opt level 2. We stopped
trying to use this machine and waited for the
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with ze
final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer pro
: Re: Looking for help with an obscure C integer problem
Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++.
"Sequence points" should not be confuse
Harry Wahl wrote:
It is at the compiler's and optimizer's discretion to decide the order
of execution for code that the C++ standard does not specifically
define. This includes overlapping execution.
and this may be conceded. What is not "in the compiler's and
optimizer's discretion" is to pro
ussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Harry Wahl
Sent: Sunday, July 21, 2013 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C&quo
point.
Thanks!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Sunday, July 21, 2013 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
BTW:
I think I remember
, that we are
underlings"
Cassius in Shakespeare's Julius Caesar
Harry
> Date: Sat, 20 Jul 2013 13:24:29 -0700
> From: charl...@mcn.org
> Subject: Looking for help with an obscure C integer problem
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Cross-posted to IBM-MAIN and MVS
BTW:
I think I remember from an old book on C programming:
"if the target of an assignment is int, all operands on the right side
are converted to int - if the target of an assignment is long, all operands
on the right side are converted to long"
If I remember correctly, this would perfectly ex
Sorry for jumping late into this thread.
Why not spend another variable of type long long to do the shift there?
like
unsigned long long valueToTest;
unsigned int testWord;
unsigned long long x;
x = valueToTest >> 32; /* here */
testWord = (int) x;
If now in the expression marked with /*
ion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Sunday, July 21, 2013 7:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote:
>Went that route on the las
On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote:
>Went that route on the last C compiler problem I found. Life is too short.
>Or at the very least, the project deadline is too short.
>
View it as an act of generosity to others who may encounter the problem.
Of course, if they're likely to
, 2013 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
at 09:33 AM, David Crayford said:
>I don't like it because it's a hack to work around an puzzling issue. I
&g
On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote:
In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
at 09:33 AM, David Crayford said:
I don't like it because it's a hack to work around an puzzling
issue. I want to know why the optimizer is not generating the
correct code.
Why not repor
In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
at 09:33 AM, David Crayford said:
>I don't like it because it's a hack to work around an puzzling
>issue. I want to know why the optimizer is not generating the
>correct code.
Why not report it as a bug?
--
Shmuel (Seymour J.) Metz, Sys
] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).
I've just tried
Okay. What do you think of the union approach?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an
---
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_cast(valueToTest >> 32) doesn't fix it then the compiler
is broken
scussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of David Crayford
> Sent: Saturday, July 20, 2013 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
>
> As a general ROT I always use explicit casts.
>
> On
] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills wrote:
> Cross-posted to IBM-MAIN and MVS-OE.
&
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills wrote:
> Cross-posted to IBM-MAIN and MVS-OE.
>
> I have the following code fragment in an inline function, compiled by the
> IBM XLC compiler as C++:
>
> unsigned long long valueToTest;
> unsigned int testW
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by the
IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest >> 32;
It *appears* to me (from somewhat circumstantial evidence in a much more
co
74 matches
Mail list logo
