Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
cu, Rudi
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
Ciao, Marcus
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?
cu, Rudi
Ruediger Meier sweet_f_a@gmx.de writes:
It's a gcc bug.
Is it?
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code?
Andreas.
On Thursday 27 February 2014, Andreas Schwab wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
It's a gcc bug.
Is it?
Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
cu, Rudi
On 27 February 2014 15:52, Ruediger Meier sweet_f_a@gmx.de wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega reddwarf@opensuse.org wrote:
On 27 February 2014 15:52, Ruediger Meier sweet_f_a@gmx.de wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)?
On 27 February 2014 16:26, Andrey Borzenkov arvidjaar@gmail.com wrote:
On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega reddwarf@opensuse.org wrote:
On 27 February 2014 15:52, Ruediger Meier sweet_f_a@gmx.de wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)?
My bad. Having gcc at my side I didn't think this through...
Cristian Morales Vega reddwarf@opensuse.org writes:
On 27 February 2014 15:52, Ruediger Meier sweet_f_a@gmx.de wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
There is a sequence point before the function call.
Andreas.
On Thu, Feb 27, 2014 at 7:52 PM, Ruediger Meier sweet_f_a@gmx.de wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
It's a gcc bug.
Is it?
Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.
Is adding pragma around this code an option? I do not have example ready right now, but would be something like
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code?
I think yes:
#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wsequence-point"
v->rvsn = hextou(++bp, &bp);
#pragma GCC diagnostic pop
Ruediger Meier sweet_f_a@gmx.de writes:
v->rvsn = hextou(++bp, &bp);
What is hextou?
Andreas.
Le Thursday 27 February 2014 à 17:25 +0100, Andreas Schwab a écrit :
Ruediger Meier sweet_f_a@gmx.de writes:
v->rvsn = hextou(++bp, &bp);
What is hextou?
Some kind of curse probably, beware!
On 02/27/2014 04:52 PM, Ruediger Meier wrote:
v->rvsn = hextou(++bp, &bp);
At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement.
Have a nice day, Berny
El 27/02/14 13:33, Bernhard Voelker escribió:
On 02/27/2014 04:52 PM, Ruediger Meier wrote:
v->rvsn = hextou(++bp, &bp);
At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement.
Also, ++bp may be evaluated more than once in the case of a macro.. and that's extremely difficult to debug.
On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?
Can you point me to your source code / project/package in OBS, then I can check this?
gcc is usually right for this warning.
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?
- suppress the gcc warning - #!BuildIgnore post-build-checks
I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format.
Ciao, Marcus
Marcus Meissner meissner@suse.de writes:
- #!BuildIgnore post-build-checks
This is too big of a hammer.
Andreas.
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?
Can you point me to your source code / project/package in OBS, then I can check this?
gcc is usually right for this warning.
See my other email in this thread in reply to Andreas. The complete source is in home:rudi_m:devel-snap/dateutils dateutils-0.2.7.git*.tar.xz
[ 97s] build-aux/yuck-scmver.c: In function 'git_version': [ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?
- suppress the gcc warning
Ok thanks, I do this now because it has minimal impact: ... # work around false positive post-build-checks %if 0%{?sles_version} export CFLAGS="$RPM_OPT_FLAGS -Wno-sequence-point" %endif ... But it looks really ugly within spec file. I was hoping I could hide this in rpmlinrc or wherever.
- #!BuildIgnore post-build-checks
I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format.
Maybe this is something which needs to be fixed for SLE_11. I have already ugly lines in the spec file because it does not understand this rpmlintrc: ... # rpmlint complains about our release tarballs in / addFilter(".*-release-tarball.* suse-filelist-forbidden-fhs23 /release_obs_.*") ... while this works for all other distros. Actually it looks like SLE does not understand rpmlintrc at all.
cu, Rudi
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
Andreas.
On 27 February 2014 16:36, Andreas Schwab schwab@suse.de wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
Cristian Morales Vega reddwarf@opensuse.org writes:
On 27 February 2014 16:36, Andreas Schwab schwab@suse.de wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
It was just a guess, since hextou is a static function.
Andreas.
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab schwab@suse.de wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
cu, Rudi
Hi,
On Thu, 27 Feb 2014, Ruediger Meier wrote:
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab schwab@suse.de wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
The link you posted doesn't indicate a gcc bug, Diego was confused, it used macros, not function calls and amounted basically to
*c++ = *c;
and _that_ does correctly cause a warning (there really is no sequence point between lhs and rhs of assignments).
Your case is different, there you had hextou(++bp, &bp);
And now comes the guesses: probably hextou (a static function, not macro) uses the value of *arg2 (i.e. bp), as well as the incremented value. With a little inlining and depending on how hextou's code looks like, that can very well result in effectively the same code as the invalid one above. But as there's a sequence point right before calling the function, there actually is no problem, also not after inlining. So your case does show a gcc bug (in not properly maintaining sequence point rules over inlining, as Andreas said), the link you posted does not.
Now, of course, nothing of that helps you in your problem, but perhaps is entertaining :)
Ciao, Michael.
On Thursday 27 February 2014, Michael Matz wrote:
Hi,
On Thu, 27 Feb 2014, Ruediger Meier wrote:
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab schwab@suse.de wrote:
Ruediger Meier sweet_f_a@gmx.de writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
The link you posted doesn't indicate a gcc bug,
I just thought they are going to bug report this http://gcc.gnu.org/ml/gcc-help/2008-02/msg00320.html
cu, Rudi
Ruediger Meier sweet_f_a@gmx.de Thu, 27 Feb 2014 18:29:11 +0300:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
cu, Rudi
Hello. It is a post build check: https://en.opensuse.org/openSUSE:Packaging_checks#post-build-checks_and_brp-...
rpm -qf /usr/lib/build/checks-data/check_gcc_output
post-build-checks-1.0-119.1.2.noarch
-
Andreas Schwab -
Andrey Borzenkov -
Bernhard Voelker -
Cristian Morales Vega -
Cristian Rodríguez -
Dmitriy Perlow -
Jean Delvare -
Marcus Meissner -
Michael Matz -
Ruediger Meier