Is this really the right error message?
$ cat p.cc char c[2] = "a"; char d[2] = c; $ g++ -c p.cc p.cc:2: error: cannot convert ‘char [2]’ to ‘char [2]’ in initialization -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: GCC optimizes integer overflow: bug or feature?
Paul Eggert wrote: > Also, such an approach assumes that unsigned long long int > has at least as many bits as long long int. But this is an > unportable assumption; C99 does not require this. We have > run into hosts where the widest signed integer type has much > greater range than the widest unsigned type. I hope these > hosts go away in the long run, but they're in production use > today. (The platform I'm thinking of is Tandem NSK/OSS.) Is this correct? Doesn't C99's 6.2.5#6 mandate that unsigned long long int has exactly the same number of bits as long long int? Perhaps you mean that in Tandem NSK/OSS unsigned long long ints do not use several bits of the representation? Am I missing something else? All the best, Roberto ISO/IEC 9899:1999 6.2.5 [...] 4 There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. [...] [...] 6 For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements. [...] [...] -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: GCC optimizes integer overflow: bug or feature?
Paul Eggert wrote: Roberto Bagnara <[EMAIL PROTECTED]> writes: (The platform I'm thinking of is Tandem NSK/OSS.) Is this correct? Doesn't C99's 6.2.5#6 mandate that... This is straying from the subject of GCC and into the problems of writing portable C code, but since you asked The Tandem NSK/OSS environment does not claim full conformance to C99. The NSK/OSS community is conservative (fault-tolerance does that do you :-) and has introduced only some C99 features, more as time progresses. The NSK/OSS developers did not introduce 64-bit unsigned int until last year. I'm no expert in the area, but I'd guess that most NSK/OSS production shops are still running older releases, which have 64-bit signed int but only 32-bit unsigned int. I now understand that Tandem NSK/OSS is not conformant, thanks. But he reason I asked is that I interpreted what you wrote, i.e., > Also, such an approach assumes that unsigned long long int > has at least as many bits as long long int. But this is an > unportable assumption; C99 does not require this. as "C99 does not require that unsigned long long int has at least as many bits as long long int." My reading, instead, is that C99 requires unsigned long long int to have exactly the same number of bits as long long int. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Miscompilation of remainder expressions
Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bug (which, to me, looks quite serious)? All the best, Roberto P.S. I checked whether this bug affects my code and it does. Before yesterday I was completely unsuspecting of such a fundamental flaw... I wonder how many know about it. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Andrew Haley wrote: Paolo Carlini writes: > > I would like to understand the issue better, however... What more is there to understand? It's an integer overflow. The processor generates a trap on integer overflows during division operations. Just because the wrong code is generated for the remainder expression. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Paolo Carlini wrote: Andrew Haley wrote: Paolo Carlini writes: > > I would like to understand the issue better, however... What more is there to understand? It's an integer overflow. The processor generates a trap on integer overflows during division operations. Yes, sorry, now I see that in the specific case it's just an overflow, like INT_MAX + 1. I was more interested in % in general for negative operands: for actual CPUs what do we know beyond the standard? No, Paolo: the result of INT_MIN % -1 is zero, according to the standard. There is no overflow whatsoever involved. The overflow that you see is simply an artifact of GCC that produces assembly code that does not implement remainder expressions correctly. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Andrew Haley wrote: Roberto Bagnara writes: > > Reading the thread "Autoconf manual's coverage of signed integer > overflow & portability" I was horrified to discover about GCC's > miscompilation of the remainder expression that causes INT_MIN % -1 > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > fix this bug (which, to me, looks quite serious)? No, there aren't. It would make more sense for you to wrap % in some code that checks for this, rather than for us to slow down every division for this one special case. This sounds like saying that you don't care about the standard. (Moreover, INT_MIN % -1 is no more a special case than 5 * 3.) I very strongly disagree with this view: standard compliance and correctness are far more important than speed. I believe the default behavior of GCC (of any serious C/C++ compiler, for that matter) should be to do the right thing. For those that care more about speed than safety or that are willing to program in a language that is not C/C++, something like the -ffast-math option can be provided. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Andrew Haley wrote: Roberto Bagnara writes: > > Reading the thread "Autoconf manual's coverage of signed integer > overflow & portability" I was horrified to discover about GCC's > miscompilation of the remainder expression that causes INT_MIN % -1 > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > fix this bug (which, to me, looks quite serious)? No, there aren't. It would make more sense for you to wrap % in some code that checks for this, rather than for us to slow down every division for this one special case. With all due respect, I must say I am shocked. I always thought (and taught) that we, Free Software people, value standard conformance and getting things right. Now we have a bug that can shut down airplanes and dealing with it is (in extreme synthesis) assimilated to nitpicking. I have not found a mention of this bug in the "Known Bugs" section of http://gcc.gnu.org: perhaps I missed it, but I think it definitely should be brought to the attention of the users since, IMHO, no one really expects a remainder expression to cause a SIGFPE. I have also looked at the bug database, and I did not find any report concerning this bug, so I created one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484 A final remark: I think that today the problem is safety, not speed. I don't think doing the right thing for remainder expression will have such a high cost with the help of the optimizer and, maybe, assistance from the kernel. But even if the cost turns out to be high, the actual state of things is unacceptable: mentioning the bug prominently in the documentation, trying to change the standard, ..., whatever; but not leaving things as they are. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Andrew Haley wrote: Roberto Bagnara writes: > Andrew Haley wrote: > > Roberto Bagnara writes: > > > > > > Reading the thread "Autoconf manual's coverage of signed integer > > > overflow & portability" I was horrified to discover about GCC's > > > miscompilation of the remainder expression that causes INT_MIN % -1 > > > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > > > fix this bug (which, to me, looks quite serious)? > > > > No, there aren't. It would make more sense for you to wrap % in some > > code that checks for this, rather than for us to slow down every division > > for this one special case. > > With all due respect, I must say I am shocked. I always thought > (and taught) that we, Free Software people, value standard conformance > and getting things right. This is a disgreement about interpretation of the langauge in the standard, which is: "The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded.87) If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a." If the quotient a/b is *not* representable, is the behaviour of % well-defined or not? It doesn't say. To the point that, when a/b is not representable, raising SIGFPE for a%b is standard conformant behavior? Note however that I am not saying that the standard is not defective. Who knows how to write and submit C/C++ standard defect reports? Let us do that, assuming that such a report has not been submitted already. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Robert Dewar wrote: Roberto Bagnara wrote: Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bug (which, to me, looks quite serious)? All the best, Roberto P.S. I checked whether this bug affects my code and it does. Before yesterday I was completely unsuspecting of such a fundamental flaw... I wonder how many know about it. It's truly amazing for real code to be computing remainders in this domain ... seems a bad idea to me, since very few people are comfortably aware of what remainder means for such cases. Everyone knows that dividing a number by -1 or 1 gives a 0 remainder. To the contrary, no one expects a%b to raise SIFPE when b != 0. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Robert Dewar wrote: Roberto Bagnara wrote: Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bug (which, to me, looks quite serious)? Seems ultra-non-serious to me, hard to believe this case appears in real code, despite surprising claim by Roberto. How do you test if a number is a multiple of another one? What about rounding toward zero to a multiple of k? I guess x - x%k looks like unreal code to you. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
Robert Dewar wrote: Roberto Bagnara wrote: Andrew Haley wrote: Roberto Bagnara writes: > > Reading the thread "Autoconf manual's coverage of signed integer > overflow & portability" I was horrified to discover about GCC's > miscompilation of the remainder expression that causes INT_MIN % -1 > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > fix this bug (which, to me, looks quite serious)? No, there aren't. It would make more sense for you to wrap % in some code that checks for this, rather than for us to slow down every division for this one special case. With all due respect, I must say I am shocked. I always thought (and taught) that we, Free Software people, value standard conformance and getting things right. Now we have a bug that can shut down airplanes Please do not indulge in excessive rhetoric, planes do not get shut down by compiler bugs. If you really think that the integrity of avionics software depends on bug free compilers you have no idea what you are talking about (I would guess you are for example unfamiliar with DO-178B certification). You are right: I am not familiar with DO-178B certification. Yes, it's a bug, is it a serious bug, no? Will real software be affected? no. Indeed I find any program that actually does this remainder operation in practice to be highly suspect. But I am not wrong if I say that a bug is a bug and must be fixed. I was answering to a message saying (basically) "we won't fix it since there is a performance penalty to be paid." I do not feel to be excessively rhetoric if I say that others, not us, are said to knowingly disregard standards, whether it be for performance reasons or for other reasons. Of course, this is a matter of taste. A final remark: I think that today the problem is safety, not speed. I don't think doing the right thing for remainder expression will have such a high cost with the help of the optimizer and, maybe, assistance from the kernel. But even if the cost turns out to be high, the actual state of things is unacceptable: mentioning the bug prominently in the documentation, trying to change the standard, ..., whatever; but not leaving things as they are. Yes, it should probably be fixed, but making a major fuss about it seems peculiar at best. I think it is perfectly reasonable for you to propose a patch to fix this if you are specially concerned, but don't expect the community to rush to fix this particular bug at high priority in response to this complaint. I am sorry if I brought you to think that I am asking something for me. There is no longer a problem for me personally: I will simply stop using % in my projects (which, by the way are in C++) and will use custom functions instead. I have almost finished an Autoconf test to check for this bug. Most importantly, I am now perfectly aware of the problem. I have filed a couple of bug reports, one for GCC and the other for the Intel C/C++ compiler. I have been told that a C Standard Defect Report already exists on this subject. So, it is the end of the story, as far as I am personally concerned. Concerning the community (to which I belong, by the way) I propose that, to start with, the documentation is modified to mention this problem in a prominent way. The text can be borrowed from the new Autoconf's documentation that has been recently discussed on this list. There are lots of known bugs far more important than this one. Wow! I hope they are all in Bugzilla: the one we are talking about was apparently not there until a couple of hours ago. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
David Daney wrote: Roberto Bagnara wrote: Robert Dewar wrote: Roberto Bagnara wrote: Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bug (which, to me, looks quite serious)? All the best, Roberto P.S. I checked whether this bug affects my code and it does. Before yesterday I was completely unsuspecting of such a fundamental flaw... I wonder how many know about it. It's truly amazing for real code to be computing remainders in this domain ... seems a bad idea to me, since very few people are comfortably aware of what remainder means for such cases. Everyone knows that dividing a number by -1 or 1 gives a 0 remainder. To the contrary, no one expects a%b to raise SIFPE when b != 0. On the contrary, since the beginning of time SIGFPE has been generated on GCC/x86/linux under these conditions. This is wildly known. Just because you just found out about it does not mean that 'no one' expects it. OK: so it is my fault. But even if it is so wildly known, I think the GCC documentation should still mention it, for the sake of the few morons like me that are unsuspecting. From http://en.wikipedia.org/wiki/SIGFPE A common oversight is to consider division by zero the only source of SIGFPE conditions. On some architectures (IA-32 included), integer division of INT_MIN, the smallest representable negative integer value, by -1 triggers the signal because the quotient, a positive number, is not representable. Hmmm, it says nothing about the remainder. Can some Google guru suggest how to prove or disprove the claim that what we are talking about is wildly known? -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Miscompilation of remainder expressions
David Daney wrote: MIPS does *not* seem to suffer from this 'defect', [...] In my opinion, if this is not a defect, then the only thing that needs to be done is writing a few lines in some "Known Issues" section of the documentation. This because, at least for me, standard conformance is the first and foremost value. By the way, I was not able to find the C Standard Defect Report concerning this issue: do you have a pointer? It would be interesting to have the advice of someone who is in the standardization commitee. So, a possible plan for dealing with this issue could be: document it so that users can know about it; when the standard has been clarified if the standard implies INT_MIN % -1 should give 0 resume the discussion about how to implement that; resume the discussion about the default behavior of GCC else do nothing -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Call the following snippet `bug.cc':
struct a {
static const int size = 0;
};
template
struct p {
int a[T::size]; // Here it says "error: creating array with size zero (`0')"
};
p n;
template
struct q {
int a[0]; // Here it says nothing!
};
q m;
$ g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ../gcc-3.4.2/configure --prefix=/usr/local
Thread model: posix
gcc version 3.4.2
$ g++ -c bug.cc
bug.cc: In instantiation of `p':
bug.cc:10: instantiated from here
bug.cc:7: error: creating array with size zero (`0')
$ /opt/beta/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0/gcc/configure --prefix=/opt/beta
Thread model: posix
gcc version 4.0.0 20050226 (prerelease)
$ /opt/beta/bin/g++ -c bug.cc
bug.cc: In instantiation of 'p':
bug.cc:10: instantiated from here
bug.cc:7: error: creating array with size zero ('0')
Should I report this as a bug?
If so, which kind of bug is it?
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Paolo Carlini wrote: Should I report this as a bug? If so, which kind of bug is it? Isn't this c++/19989? Hi Paolo, yes, I think it is that one. Thanks, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Reporting bugs: there is nothing to gain in frustrating reporters
Stimulated by the discussion about fixing bugs and frustrated potential developers, I thought it could be useful to briefly share my recent experience of frustrated bug reporter with the subscribers of this list. Until the recent past, I have never given up investigating any suspicious behavior of GCC and I have always tried hard to come up with a testcase, check the standard documents and write decent bug reports. But this activity has recently been so frustrating that I now see it as a loss of time. In the past, we had the list of open bug reports that was growing beyond control; to improve the situation now we have people sitting on the bug database on a 24/7 basis, with an apparent anxiety to close bug reports as quickly as possible. The pattern I went through lately goes more or less as follows: 1) I submit a bug report; 2) someone looks at it superficially, too superficially, and posts a comment that tends to deny there is a problem; 3) I and/or someone else explain that the problem is indeed there, possibly citing the points of the standards that are being violated; 4) the person who said the bug was not (exactly) a bug does not even care to reply, but the superficial comments remain there, probably killing the bug report. I wonder what is the rationale here. Discouraging bug reporters may be an effective way to avoid bug reports pile up, but this is certainly not good for GCC. Examples of the pattern I described above are in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963 My advice to people filtering bug reports is: if you only had time to look at the issue superficially, either do not post any comment or be prepared to continue the discussion on more serious grounds if the reporter or someone else comes back by offering more insight and/or precise clauses of the relevant standards. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Andrew Pinski wrote:
>
> On Jun 16, 2005, at 10:58 AM, Scott Robert Ladd wrote:
>
>> Daniel Berlin wrote:
>>
>>> Again, *please* provide examples other than "The bugmasters are mean".
>>
>>
>> Don't invent quotes. I never said anyone was "mean." And other people
>> have provided explicitly links to germane bugs.
>
>
> Four out of how many?
> The explantion for all of those four:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
> "
> Note GCC does not know about the rounding mode, in fact the round mode
> is only changeable in C99
> by the #pragma which GCC does not do right now and I thought that is a
> different PR already."
>
> How could this be considered rude, I was just stating a fact.
First, I would like to clarify I do not consider it rude.
But I do not consider it a good thing that, after this superficial comment
of yours, you did not even care to reply to my further arguments and question.
This is precisely the kind of behavior that frustrates me and, I guess,
frustrates most other bug reporters.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
>
> "
> Note neg just flips a bit so it is correct anyways and there is no loss
> of precession.
>
> This also happens on ppc darwin, I don't know what to make of this. A C
> person has to comment to say
> something about this.
> "
>
> I said someone else has to comment on this, so I was saying I don't know
> for sure.
You said something incorrect ("Note neg just flips a bit so it is correct
anyways and there is no loss of precession"), then again you failed to reply
to an explicit question and to further arguments I added. You also failed
to reply when I pointed out, in another comment, that this was indeed
a regression from 3.3. Then leaving the bug UNCONFIRMED for months...
OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
> Huh, there was no negative thing in there at all from me or either
> Wolfgang.
> Maybe "This should be low priority, since we only accept invalid code.
> " but Wolfgang
> found a rejects valid case in about an hour.
That link was included by mistake, in fact. I apologize.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
> This is the only one which was closed, in fact I still think it should
> be a warning
> unconditional.
As I said above, perhaps it is the word "bugmaster" that should be changed.
It is hard to believe that a master can advocate an unconditional,
architecture-dependent warning that a user cannot switch off without
switching of _all_ the other warnings and that can only be avoided
by writing non-portable code. This concerning the substance.
Concerning the form, you closed the bug without even caring, again,
to address the points I raised and the explicit questions I have asked.
To summarize, why should I, simple user, spend hours investigating a
suspicious behavior of GCC when you, bugmaster, take the liberties
of giving superficial and/or wrong answers without even apologizing,
of not answering altogether, of not looking at the standard documents,
of not even reading carefully what me and others write? It is not
a matter of rudeness, but rather a matter of technical and social
carelessness. Why you seem to feel an obligation to intervene
on bug reports for which you appear to have neither the competences
nor a willingness to obtaining them by careful consideration of
the issues that are brought to your attention and of the standards?
Now please do not tell me that you are a volunteer: we all are
volunteers here and we are all contributing to Free Software in
one way or another. Being a volunteer is not an excuse for not
paying attention to the technical and human aspects of our
volunteer work.
> -- Hitler (just to stop this thread)
I don't believe that stopping the thread would solve the problem.
You probably want to say that continuing it would not solve it
either. This is sad, if it means we have to live with it...
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: Parma Polyhedra Library 0.11.1
On 02/21/2011 04:42 AM, Jack Howarth wrote:
On Sun, Feb 20, 2011 at 06:32:30PM +0100, Prof. Roberto Bagnara wrote:
We announce the availability of PPL 0.11.1, a new release of the Parma
Polyhedra Library. This release includes several important bug fixes
and performance improvements.
Roberto,
Have you had any reports of installation problems?
Hi Jack.
No, your report was the first one.
After installing
doxygen, texlive for pdflatex and graphviz for dot, I am still running into
installation failures for the documentation. These currently appear as...
Writing index file refman.idx
No file refman.aux.
(/sw/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/sw/share/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/sw/share/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/sw/share/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/sw/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/sw/share/texmf-dist/tex/latex/graphics/color.sty
(/sw/share/texmf-dist/tex/latex/latexconfig/color.cfg))
(/sw/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/refcount.sty)
(/sw/share/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/sw/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/sw/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
(/sw/share/texmf-dist/tex/latex/stmaryrd/Ustmry.fd) [1{/sw/var/lib/texmf/fonts/
map/pdftex/updmap/pdftex.map}] (/sw/share/texmf-dist/tex/latex/psnfss/ts1ptm.fd
) (/sw/share/texmf-dist/tex/latex/psnfss/t1pcr.fd) (./main.texpdfTeX warning (e
xt4): destination with the same identifier (name{page.1}) has been already used
, duplicate ignored
\relax
l.17 ...ry.Parma\_\-Polyhedra\_\-Library}};\item S
tarting from version 0.11,...
[1]
Underfull \hbox (badness 1337) in paragraph at lines 26--26
[]\T1/ptm/m/n/10 boxes which con-sist of Int8_-Box, Int16_-Box, Int32_-Box, Int
64_-Box, Uint8_-Box,
Hmmm... this is very strange. I would like to reproduce the issue:
which version of Doxygen are you using?
) (/sw/src/fink.build/ppl9-0.11.1-0/ppl-0.11.1/build/../doc/GPL.tex
! LaTeX Error: Can be used only in preamble.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1 \documentclass
[a4paper,12pt]{article}
?
This is even stranger: the file name should be `gpl.tex', not `GPL.tex'
Can you please double check in the `doc' subdirectory?
Cheers,
Roberto
--
Prof. Roberto Bagnara CEO & CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, ItalyI-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: Parma Polyhedra Library 0.11.1
On 02/22/2011 06:04 AM, Dongsheng Song wrote:
When I build on i686-w64-mingw32 target:
libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2
Here is my patch:
$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
#include "fpu.defs.hh"
#include
#include
+#include
namespace {
Hi Dongsheng,
I don't see any occurrences of NULL in fpu-ia32.cc.
Perhaps this is a bug in the or related header file
in your system?
And I'm doubt the assumption GMP does not support exception when cross
compiling:
$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
ac_cv_gmp_supports_exceptions=yes,
AC_MSG_RESULT(no)
ac_cv_gmp_supports_exceptions=no,
- AC_MSG_RESULT([assuming not])
- ac_cv_gmp_supports_exceptions=no)
+ AC_MSG_RESULT([assuming yes])
+ ac_cv_gmp_supports_exceptions=yes)
gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
if test x"$gmp_supports_exceptions" = xyes
How does this affect you? I mean, that setting only affects
the PPL testsuite and if you are cross-compiling you are
not using it.
All the best,
Roberto
--
Prof. Roberto Bagnara CEO & CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, ItalyI-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: [PPL-devel] Parma Polyhedra Library 0.11.1
On 02/22/2011 03:00 AM, Jack Howarth wrote: The problems seems to stem from the absence of pre-generated files for... ppl-user-java-interface-0.11.1-html.tar.gz ppl-user-java-interface-0.11.1.pdf ppl-user-java-interface-0.11.1.ps.gz in the doc directory of the source tarball. The fink ppl9 package builds using --with-java="$JAVA_HOME" so that those missing files are autogenerated by make install. Can you post a new tarball with those missing files added? Hi Jack. You are right: this is indeed the problem. I have uploaded the missing files to the PPL 0.11 release directory. Please let us know if you have further problems. Cheers, Roberto -- Prof. Roberto Bagnara CEO & CTO Applied Formal Methods Laboratory BUGSENG srl Department of Mathematics Parco Area delle Scienze 53/A University of Parma, ItalyI-43124 Parma, Italy http://www.cs.unipr.it/~bagnara/ http://bugseng.com/ mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
Richard Guenther wrote: On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote: On Sun, 26 Oct 2008, David Edelsohn wrote: Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked by g++, this effectively requires that libgmpxx must be a shared library. libgmp I hope the Graphite people are working on fixing this for 4.4. As I said in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following Ian's slides), libstdc++ should be statically linked into cc1 by default - which probably means that if static libgmpxx is available then it should be used. I'm also concerned that we still don't have any documentation in install.texi concerning these libraries and pointing to suitable release tarballs of them in the infrastructure directory - we're nearly two months into Stage 3 and these libraries should be subject to much the same development stage rules as in-tree optimizers with the versions documented to be used and associated configure checks changing only to update to new bug-fix minor releases, not major feature releases, while in Stage 3. I think we are still waiting for the final ppl release, but otherwise I agree that instructions and tarballs should be provided rather yesterday than tomorrow. The first release candidate of the PPL has just been published: http://www.cs.unipr.it/pipermail/ppl-announce/2008/20.html If you want, I can draft a patch for install.texi during next weekend. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Parma Polyhedra Library 0.10
It has been released: see http://www.cs.unipr.it/pipermail/ppl-announce/2008/21.html All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Parma Polyhedra Library 0.10
Jack Howarth wrote: Now that ppl 0.10 is release, what are the plans for merging the cloog-ppl changes into an actual cloog release so that tarballs are available for both? This is a good question for the CLooG maintainers. Are they on this list? -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Sebastian Pop wrote: Q3) Why is there C++ in my libppl? Have I done something wrong to get it there in the first place, or is it supposed to work somehow? At the end of stage 1, I can work around the problem by manually running the final link command, but using the (native compiler's) g++ driver instead of the plain gcc driver, or by manually adding -lstdc++. But I can't do anything like that to get past the link failure at the end of stage 2; we're not using the native compiler any more but the stage 1 compiler and so we've only got a crude xgcc that doesn't understand "-x c++", and of course target libstdc++ hasn't been built yet. Something's really wrong here - I can't understand why there's C++ involved or how it could work. Maybe the default configure options of PPL have changed to include some C++ interface that wasn't built by default at the time the wiki page was written? Anyway, TIA for any enlightenment anyone can provide. I could file PRs or patches for the first two bugs if desired, I would highly appreciate this. but the third part has me totally confused, I don't know what to do with it. I'm forwarding this third question to the PPL folks, hoping that they already dealt with similar cases and probably already have a solution. Hi there, I am not sure I understand the question (and I am not familiar with Cygwin). The answer to the question "Why is there C++ in my libppl" is that libppl is written in C++. The C interface to the PPL, libppl_c, is also written in C++. Your description of the problem confuses me, as it seems to be system-independent; however, I have no problems bootstrapping HEAD on my GNU/Linux system. What am I missing? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Dave Korn wrote: Roberto, what does ldd show on the various cc1 binaries in the different stage directories of your most recent bootstrap? I'm guessing you'll see that the stage 2 cc1 is linked against the system libstdc++ rather than the newly-bootstrapped one. $ find . -name cc1 ./prev-gcc/cc1 ./gcc/cc1 ./stage1-gcc/cc1 $ find . -name cc1 | xargs ldd ./prev-gcc/cc1: linux-vdso.so.1 => (0x7fffb37ff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x02027000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x015e7000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x0278a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0188) /lib64/ld-linux-x86-64.so.2 (0x003e3380) ./gcc/cc1: linux-vdso.so.1 => (0x7fff4e3fe000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x02fbc000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x064f1000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x06d01000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0110b000) /lib64/ld-linux-x86-64.so.2 (0x003e3380) ./stage1-gcc/cc1: linux-vdso.so.1 => (0x7fff7bdff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x7f9f736e1000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x7f9f734dc000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x7f9f73256000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f9f7303f000) /lib64/ld-linux-x86-64.so.2 (0x003e3380) This is from HEAD of 20 minutes ago. Notice that I had to work around the multiple definition of debug_value() you already reported. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] PPL broken for Canadian-cross builds
Joseph S. Myers wrote: I tried building GCC with Graphite enabled and all the libraries it requires in a Canadian cross configuration (build = i686-pc-linux-gnu, host = i686-mingw32, target = arm-none-eabi). This failed with: configure:11279: checking for the possibility to control the FPU configure:11282: error: in `/scratch/gcc/nightly-2009-03-19-mainline/arm-none-eabi/obj/ppl-mainline-0-arm-none-eabi-i686-mingw32': configure:11285: error: cannot run test program while cross compiling See `config.log' for more details. If you use AC_RUN_IFELSE you need to have a (safe) default (fourth argument) for cross compiling. An individual case is of course straightforward to fix, but it appears there are other such problems in PPL. For example, the GMP checks appear to treat GMP as not available in the cross compiling case; they should fall back to a compile/link test if they can't do an execution test; having found that I didn't go on to try to work out whether other defaults are safe or not. While the cross case may result in slightly less efficient code (if workarounds have to be enabled for bugs that may in fact not be present), it needs to allow the library to be built and to have all its features (or at least all the features used by GCC: the behavior of GCC on a host must not depend on whether PPL was cross compiled). Hi Joseph, thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe? Would it be possible to have an official 0.10.1 bug-fix release with this fixed (and preferably without changes that would affect the code generated by GCC) for use with GCC 4.4 so that it is possible to enable Graphite in such configurations? Work has already started for producing an official PPL 0.11 release. This will contain fixes for all the problems we discovered since the release of PPL 0.10 (mainly portability ones), a new "formatted output" feature that is needed in the MELT branch, plus other improvements, none of which affecting the code generated by GCC. I will write again when we can be more precise about the release schedule. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] PPL broken for Canadian-cross builds
Joseph S. Myers wrote: On Fri, 20 Mar 2009, Roberto Bagnara wrote: Work has already started for producing an official PPL 0.11 release. This will contain fixes for all the problems we discovered since the release of PPL 0.10 (mainly portability ones), a new "formatted output" feature that is needed in the MELT branch, plus other improvements, none of which affecting the code generated by GCC. I will write again when we can be more precise about the release schedule. I suggested a minimally fixed 0.10.1 to provide something maximally safe to use with 4.4 (or 4.4.1, etc., depending on the timing) without needing --disable-ppl-version-check; I'd be wary of explicitly approving multiple versions for use with 4.4, or increasing the recommended version from 0.10 to 0.11, at this late stage. For development for GCC 4.5, increasing the recommended version to 0.11 would seem appropriate. The point is that we had since long decided to make PPL 0.11, due to the many little glitches people has reported and due to the fact that the changes would not allow to preserve the ABI. Backporting all the changes to PPL 0.10 would be a lot of work and error-prone. Given that the release of GCC 4.4 is being delayed, what is the problem in having PPL 0.11 has a prerequisite instead of PPL 0.10? Notice that we can give a strong guarantee that no change is going to affect the code generated by GCC. Unfortunately building with a cross-compiler is so much a normal way of building GCC and the libraries it uses to me I didn't think PPL would need specific testing with it or that the portability testing of PPL done when support for using it was added to GCC would not have included it, so didn't test it before now. It is probably embarassing, but all this is completely new to us. We announced the PPL 0.10 release candidate on October 27th, 2008 on gcc-patc...@gcc.gnu.org and the PPL 0.10 release on gcc@gcc.gnu.org on November 4th, 2008; no one raised this issue before. Anyway we are working on this full time now. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] PPL broken for Canadian-cross builds
Joseph S. Myers wrote: On Fri, 20 Mar 2009, Roberto Bagnara wrote: thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe? I can test whether a candidate fixed tarball works (to build PPL and GCC in such an environment) in this case; [...] Hi there, the PPL 0.10.1 snapshots available at ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ contain all the fixes to problems and glitches that have been reported to us and may affect GCC. Concerning cross-compilation, we have fixed the configuration procedure and made several portability improvements: we have tested these changes cross-compiling for arm-elf and i686-pc-mingw32. Please let us know if this is OK as far as GCC 4.4 is concerned. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
First PPL 0.10.1 release candidate
We have uploaded the first PPL 0.10.1 release candidate to ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ You can check the NEWS file via Gitweb: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob_plain;f=NEWS;hb=ppl-0_10-branch If all goes well, the release of PPL 0.10.1 will happen on April 14, 2009. In case problems arise, the above mentioned snapshot will be replaced by a new one and only announced on ppl-de...@cs.unipr.it (of course the real release will be properly announced). Please report any problem you may encounter to ppl-de...@cs.unipr.it Beta-testing is especially important on this occasion because PPL 0.10.1 will be the last release in the PPL 0.10 series. The following release will be PPL 0.11. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: First PPL 0.10.1 release candidate
Dave Korn wrote: Roberto Bagnara wrote: We have uploaded the first PPL 0.10.1 release candidate to Please report any problem you may encounter to ppl-devel Hi Roberto and team, I am sorry to report some problems encountered. Hi Dave, thanks for the report. We will investigate it immediately. Target: i686-pc-cygwin, cygwin-1.7.0-42, gcc-4.3.2, ppl configured with --enable-shared --disable-static, no -fexceptions, no --enable-cxx. I am not following here. There are no "-fexceptions" and "--enable-cxx" in the PPL configuration procedure. In contrast, "--enable-cxx" is an option of GMP's configuration procedure. Moreover, if GMP was not compiled with the C++ interface enabled there is no way the PPL can work (even though compilation should fail in such case). Can you send us more details about which version of GMP you are using and how it was configured? We also need the files config.log and config.h generated by PPL's configure script. Thanks again, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] First PPL 0.10.1 release candidate
Dave Korn wrote: Roberto Bagnara wrote: Dave Korn wrote: Target: i686-pc-cygwin, cygwin-1.7.0-42, gcc-4.3.2, ppl configured with --enable-shared --disable-static, no -fexceptions, no --enable-cxx. I am not following here. There are no "-fexceptions" and "--enable-cxx" in the PPL configuration procedure. In contrast, "--enable-cxx" is an option of GMP's configuration procedure. Moreover, if GMP was not compiled with the C++ interface enabled there is no way the PPL can work (even though compilation should fail in such case). Apologies for being unclear. This is the commandline I used to configure with (from my bash history): 456 ./configure --prefix=/opt/gcc-tools -v --disable-static --enable-shared 2>&1 | tee conf.log I assume --disable-static is OK for Cygwin. This is the tail of conf.log configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP: *** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION. *** This is OK, if you do not plan to use the bounded memory capabilities *** offered by the PPL. Otherwise, if you are using GCC or the Intel C/C++ *** compiler, please make sure you use a version of GMP compiled with the *** `-fexceptions' compiler option. *** To build such a version, you can configure GMP as follows: *** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local I just meant to say that I had seen this warning and /not/ acted on it. That's OK. I mean, CLooG does not use that capabilities, so there is no problem here. We also need the files config.log and config.h generated by PPL's configure script. Do you still want these in light of the above information? Yes, please. Thanks, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Parma Polyhedra Library 0.10.1
We are pleased to announce the availability of PPL 0.10.1, a new release of the Parma Polyhedra Library. This release includes several important improvements to PPL 0.10, among which is better portability (including the support for cross-compilation), increased robustness, better packaging and several bug fixes. The precise list of user-visible changes is available at http://www.cs.unipr.it/ppl/Download/ftp/releases/0.10.1/NEWS . For more information, please come and visit the PPL web site at http://www.cs.unipr.it/ppl/ On behalf of all the past and present contributors listed at http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Parma Polyhedra Library 0.10.1
Richard Guenther wrote:
On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara wrote:
We are pleased to announce the availability of PPL 0.10.1, a new release
of the Parma Polyhedra Library.
It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux
but I get
PASS: nnc_writepolyhedron1
/bin/sh: line 4: 29952 Segmentation fault ${dir}$tst
FAIL: memory1
==
1 of 191 tests failed
Please report to ppl-de...@cs.unipr.it
==
on s390x-linux. Does the testsuite stop after the first error?
Hi Richard.
The testsuite does not proceed after the first directory that gives
an error. In your case, the `tests/Polyhedron' directory produced that
error and the `tests/Grid' directory is the only subdirectory of `tests'
that has not been tested because of that error.
If not,
what is memory1 testing?
It tests the PPL features that allow to recover after an out-of-memory
error, i.e., when std::bad_alloc is thrown. It does so by limiting
the amount of memory available to the process, attempting some
expensive computation, catching std:bad_alloc, and restart.
The key function is this one:
bool
guarded_compute_open_hypercube_generators(dimension_type dimension,
unsigned long max_memory_in_bytes) {
try {
limit_memory(max_memory_in_bytes);
compute_open_hypercube_generators(dimension);
return true;
}
catch (const std::bad_alloc&) {
nout << "out of virtual memory" << endl;
return false;
}
catch (...) {
exit(1);
}
// Should never get here.
exit(1);
}
From the fact that you observe this failure, I gather that the configure
script found a version of GMP compiled with -fexceptions. Unfortunately,
this is not always enough. For instance, on the Itanium the test fails
because of the libunwind bug reported in
http://lists.gnu.org/archive/html/libunwind-devel/2008-09/msg1.html
Hence the test is disabled if defined(__ia64). I don't know what the
problem could be on s390x-linux. Do you know if there is an s390x-linux
machine we can obtain access to for the purpose of debugging?
Cheers,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it
Re: Parma Polyhedra Library 0.10.1
Jack Howarth wrote: On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote: On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth wrote: [...] It seems rather bad form to me that soversions are being changed in minor dot releases of ppl. This has been one of my biggest fears about cloog/ppl...that the so version control be randomly bumped. Jack, can you please explain what you mean by "randomly bumped"? Thanks, Roberto P.S. Please direct all the PPL-related messages to ppl-de...@cs.unipr.it -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Parma Polyhedra Library 0.10.1
Peter O'Gorman wrote: Jack Howarth wrote: However if you look in ppl-0.10.1/src/Makefile.am, you will find... # PPL release -version-info # 0.1 - # 0.2 - # 0.3 0:0:0 # 0.4 1:0:1 # 0.5 2:0:0 # 0.6 3:0:0 # 0.7 4:0:0 # 0.8 5:0:0 # 0.9 6:0:0 # 0.107:0:0 # 0.10.1 8:0:1 So either Roberto meant to bump the soversion and forgot or changed his mind and didn't revert all of the soversion changes out before release. I assume that there was some added API that caused the CURRENT version number to increase. Since the soname did not change (AGE was also bumped), anything that was built against version 0.10 will continue to work with 0.10.1 without being rebuilt. Yes, this is what happened. [...] http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info This is the algorithm we followed. However, I realize now that we forgot to update the C interface using the same algorithm. So in interfaces/C/Makefile.am we have ... # 0.102:0:0 LIBPPL_C_LT_CURRENT = 2 LIBPPL_C_LT_REVISION = 0 LIBPPL_C_LT_AGE = 0 whereas we should have ... # 0.102:0:0 # 0.10.1 3:0:1 LIBPPL_C_LT_CURRENT = 3 LIBPPL_C_LT_REVISION = 0 LIBPPL_C_LT_AGE = 1 Last but not least, GMP 4.3.0 was released a few hours after PPL 0.10.1 with a change that is not backward compatible and that affects the PPL. Summing up, I think the only solution is to release PPL 0.10.2 during the weekend. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: [PPL-devel] Parma Polyhedra Library 0.10.1
Richard Guenther wrote: On Wed, Apr 15, 2009 at 5:28 PM, Roberto Bagnara wrote: Last but not least, GMP 4.3.0 was released a few hours after PPL 0.10.1 with a change that is not backward compatible and that affects the PPL. Summing up, I think the only solution is to release PPL 0.10.2 during the weekend. You mean the inability to verify the version requirement? hecking for the GMP library version 4.1.3 or above... no configure: error: Cannot find GMP version 4.1.3 or higher. GMP is the GNU Multi-Precision library: see http://www.swox.com/gmp/ for more information. When compiling the GMP library, do not forget to enable the C++ interface: add --enable-cxx to the configuration options. which is what I get after updating to GMP 4.3.0. Precisely. This is due to the fact that, starting from GMP version 4.3.0 the `gmp_version' variable always contains three parts (major, minor, patchlevel). In previous versions the patchlevel was omitted if it was 0. This change broke our GMP detection procedure. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Snapshots of PPL 0.10.2 available for testing
All the problems of PPL 0.10.1 we are aware of have been fixed in the snapshot of PPL 0.10.2 available at ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ In particular here is what has changed: - Correctly detect GMP 4.3.0. - Fixed the C interface library version information. - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x platform. - Makefiles fixed so as to avoid failure of `make -n check'. If no further issues are reported, that snapshot will be relabeled PPL 0.10.2 and released on Saturday, April 18, 2009. Thanks to all who provided feedback. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Parma Polyhedra Library 0.10.2
We announce the availability of PPL 0.10.2, a new release of the Parma Polyhedra Library fixing a few bugs affecting PPL 0.10.1. The precise list of user-visible changes is below. For more information, please come and visit the PPL web site at http://www.cs.unipr.it/ppl/ The core development team, Roberto Bagnara Patricia M. Hill Enea Zaffanella -- NEWS for version 0.10.2 (released on April 18, 2009) -- Bugfixes o Correctly detect GMP 4.3.0. o Fixed the C interface library version information. o Test program tests/Polyhedron/memory1 disabled on the zSeries s390x platform. o Makefiles fixed so as to avoid failure of `make -n check'. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Problems with in-tree host libraries (gmp, ppl, etc)
Kaveh R. GHAZI wrote:
On Sat, 2 May 2009, Anthony Green wrote:
The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?
It is supposed to. I haven't worked on or tested the ppl machinery so I
don't know what shape it is in.
Index: Makefile.def
===
--- Makefile.def(revision 146995)
+++ Makefile.def(working copy)
@@ -60,7 +60,7 @@
host_modules= { module= gawk; };
host_modules= { module= gettext; };
host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
- extra_configure_flags='--disable-shared';
+ extra_configure_flags='--disable-shared --enable-cxx';
no_install= true;
host="none-${host_vendor}-${host_os}";
target="none-${host_vendor}-${host_os}"; };
I would only pass in this flag if ppl is being used. Look at what I did
with extra_mpfr_configure_flags in the top level directory. You can use a
similar mechanism to have a flag passed in to the gmp build conditionally.
Even then, the ppl configury isn't detecting the gmp we just built. It
seems as though we should install gmp in a local temporary install tree
and point ppl at that. See below for a trace of the ppl configury as it
attempts to detect an in-tree gmp (after applying the patch above).
AG
I don't know if ppl was ever setup to detect/use an in-tree gmp. It would
need to be able to specify --with-gmp-build= or something equivalent to
get the header and library from a build tree rather than an install tree.
They're laid out slightly differently.
The PPL configure script offers the following options:
--with-libgmp-prefix[=DIR] search for libgmp in DIR/include and DIR/lib
--without-libgmp-prefix don't search for libgmp in includedir and libdir
--with-libgmpxx-prefix[=DIR] search for libgmpxx in DIR/include and DIR/lib
--without-libgmpxx-prefix don't search for libgmpxx in includedir and
libdir
If the C and the C++ interface of GMP have been installed in the same places,
specifying --with-libgmp-prefix[=DIR] is enough.
If you think that being able to use a non-installed GMP build tree is important,
we can add an option to that effect.
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it
Re: Trouble building Graphite
Ian Lance Taylor wrote: I'm having some trouble building the Graphite support. Using ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.10.2.tar.gz : * Unlike gcc, does not support a --with-gmp option. + Does support a --with-libgmpxx-prefix option. What is the trouble with this? I mean, is it a matter of syntax (you prefer the option to be called --with-gmp) or semantics (the --with-libgmpxx-prefix does not do the right thing)? * If GMP was not built with C++ support, fails at build time. Yes, the C++ interface of GMP is required. On the other hand, also the core of PPL is written in C++. In whhich sense requiring the C++ interface of GMP is a trouble? * If GMP was not built with exception support, complains at configure time, and recommends using CPPFLAGS=-fexceptions when building GMP. Well, "complain" is not the right word. The PPL configuration script simply warns about the fact that the bounded memory capabilities of the PPL are not available. Which is not a problem for GCC, since these capabilities are not used by CLooG. The message was designed not to alarm people unnecessarily. It says: "This is OK, if you do not plan to use the bounded memory capabilities offered by the PPL." Do you think a different wording could help? + CPPFLAGS is for preprocessor flags, and -fexceptions is not a preprocessor flag. However, I admit that setting CFLAGS does not work correctly, as GMP seems to have special requirements for it. In facto, our use of CPPFLAGS is motivated by the fact that using CFLAGS for that purpose was not working, once upon a time. See: http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000639.html http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000663.html Perhaps it works now: we will check again and, in case it works, we will amend the configuration script, documentation and web site. + I think they mean -funwind-tables anyhow. We do that because: -funwind-tables Similar to -fexceptions, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. Please let us know if we are mistaken on this point. Generally speaking, we are 100% willing to improve the PPL as much as possible: any suggestion is welcome in this respect. Please mail to ppl-de...@cs.unipr.it All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Graphite build fails if PPL configured with --disable-shared
Janis Johnson wrote: On Mon, 2009-05-11 at 13:07 -0700, Ian Lance Taylor wrote: Another Graphite build issue: it appears that I must not use --disable-shared when I configure PPL. If I do use --disable-shared, I get this: /home/iant/gnu/ppl-0.10.2-install/lib/libppl_c.a(ppl_c_implementation_common.o): In function `finalize': /home/iant/gnu/ppl-0.10.2/interfaces/C/../../src/ppl.hh:1842: undefined reference to `operator delete(void*)' followed by thousands of similar errors. This is unfortunate, as it means that I must manually set LD_LIBRARY_PATH to the directory where the PPL library is installed. This also makes it harder for anybody else to run the compiler that I build. This needs to be fixed. I get around this by setting LDFLAGS for the ppl configure: LDFLAGS="-static" \ ./configure \ --prefix=$PREFIX \ --build=powerpc-linux \ --with-gnu-ld \ --with-libgmp-prefix=$PREFIX \ --with-libgmpxx-prefix=$PREFIX \ --disable-shared I am not sure I understand: we trust that Libtool, which provides us with the --disable-shared option, will do the right thing. And it seems it does here: the static library is built and passes its checks. Perhaps you want something different from what --disable-shared promises, that is, not to build any shared libraries? I copy libstdc++.a into the directory with the other GCC host libraries (gmp/mpfr/ppl/cloog/mpc). Building these libraries is indeed quite painful. Any suggestion about how to improve the PPL is welcome. This, of course, applies also to the build machinery. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Parma Polyhedra Library 0.11
The core development team is very pleased to announce the availability
of PPL 0.11, a new release of the Parma Polyhedra Library.
This release has many new features, some of which developed in strict
coordination with the people behind GCC/Graphite. The main novelties
are:
- a class PIP_Problem that provides a Parametric Integer Programming
problem solver;
- "deterministic" timeout computation facilities;
- support for termination analysis via the automatic synthesis of
linear ranking functions;
- support for approximating computations involving (bounded)
machine integers.
This release includes several other enhancements, speed improvements
and some bug fixes. The precise list of user-visible changes is
available at
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11/NEWS .
For more information, please come and visit the PPL web site at
http://www.cs.unipr.it/ppl/
On behalf of all the past and present developers listed at
http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
Roberto BagnaraPatricia M. HillEnea Zaffanella
Applied Formal Methods Laboratory
Department of Mathematics
University of Parma, Italy
--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it
Re: Parma Polyhedra Library 0.11
On 08/04/10 20:58, Jack Howarth wrote: On Wed, Aug 04, 2010 at 05:43:33PM +0200, Roberto Bagnara wrote: The core development team is very pleased to announce the availability of PPL 0.11, a new release of the Parma Polyhedra Library. This release has many new features, some of which developed in strict coordination with the people behind GCC/Graphite. The main novelties are: - a class PIP_Problem that provides a Parametric Integer Programming problem solver; - "deterministic" timeout computation facilities; - support for termination analysis via the automatic synthesis of linear ranking functions; - support for approximating computations involving (bounded) machine integers. Roberto, I noticed that this release bumps the actual soversion numbers so that we have libppl.9.dylib, libpwl.5.dylib and libppl_c.4.dylib rather than libppl.7.dylib, libpwl.4.dylib and libppl_c.2.dylib from the 0.10.x releases. Hi Jack, yes, the soversion numbers have been updated as needed (this should not come as a surprise though). So I assume we now need legacy ppl packages for the older cloog library builds and will have to bump the soversion on any newer cloog that builds against ppl 0.11, right? I am not familiar enough with cloog to answer that. What I can do is to recommend the use of PPL 0.11 instead of PPL 0.10.* for the reasons explained in the NEWS file. Cheers, Roberto -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Parma Polyhedra Library 0.11
On 08/05/10 05:09, Dennis Clarke wrote: On a number of occasions I have tried to build ppl and Cloog and watched the process fail repeatedly. I have yet to see it complete with any degree of success. Perhaps this is due to some strange issue with gmp and mpfr header versions and a false error message about libgmp versions is generally seen early in the build process. If this fault in the ppl/cloog code has been fixed then I'll be quite glad to see it. Hi Dennis, I am not sure I understand the problems you are talking about (a release candidate has been announced back in april and no one reported this problem). However, PPL 0.11 has new, simpler options to indicate the GMP installation to use. These are: --with-gmp-prefix[=DIR] search for libgmp, libgmpxx in DIR/include and DIR/lib --with-gmp-build=DIRuse a non-installed build of GMP in DIR If you run into problem, please file a bug at https://www.cs.unipr.it/mantis/ Cheers, Roberto -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: some integer undefined behaviors in gcc
On 08/09/10 08:42, John Regehr wrote: On Sat, 7 Aug 2010, Florian Weimer wrote: I wonder if we should give up and make -fwrapv the default. My sense is that there are not that many of these integer bugs, and probably all of them are simple to fix. Best to just fix them and then run a tool like ours every now and then to see if anything new has popped up. Really interesting: where can we read more about the tool? -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Darwin long doubles and controlled rounding
Hi there, I have read the files darwin-ldouble* in GCC 4.1.0. What I would like do know is whether I can expect long doubles on Darwin to comply with ISO C99 7.6 (Floating-point environment). I am particularly interested in the possibility of setting the rounding mode with fesetround(). Is this supported? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Darwin long doubles and controlled rounding
Geoffrey Keating wrote: Roberto Bagnara <[EMAIL PROTECTED]> writes: Hi there, I have read the files darwin-ldouble* in GCC 4.1.0. What I would like do know is whether I can expect long doubles on Darwin to comply with ISO C99 7.6 (Floating-point environment). They can be made compliant with that section, but it requires cooperation from the project providing fenv.h. I am particularly interested in the possibility of setting the rounding mode with fesetround(). Is this supported? This implementation only supports one rounding mode, FE_TONEAREST, so it's not useful to call fesetround(). Thanks for the information. Are there any plans to extend it to support the rounding modes to minus and plus infinity? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: GCC 4.1.1 Released
Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC [...] Do you mean "a bug-fix release for problems in GCC 4.1.0"? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Parma Polyhedra Library 1.1
The core development team is very pleased to announce the availability of PPL 1.1, a new release of the Parma Polyhedra Library. This release includes support for "positive time elapse," a new operator on polyhedra, improvements to the Java interface, several portability improvements and a few bug fixes. The precise list of user-visible changes is available at http://bugseng.com/products/ppl/download/ftp/releases/1.1/NEWS . For more information, please come and visit the PPL web site at http://bugseng.com/products/ppl On behalf of all the past and present developers listed at http://bugseng.com/products/ppl/credits and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella Abramo Bagnara BUGSENG srl (http://bugseng.com) -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com
Parma Polyhedra Library 0.12
The core development team is very pleased to announce the availability of PPL 0.12, a new release of the Parma Polyhedra Library. This release includes portability improvements, a few bug fixes, and performance improvements for the MIP and PIP solvers. and PIP solvers. Configurability has also been improved, especially as far as the detection of GMP is concerned. ECLAIR (http://bugseng.com/products/eclair) has been introduced into the development workflow to bring the PPL into conformance with the applicable rules in MISRA, CERT, NASA/JPL, ESA/BSSC and other widely-used coding standards. The precise list of user-visible changes is available at http://bugseng.com/products/ppl/download/ftp/releases/0.12/NEWS . For more information, please come and visit the new PPL web site at http://bugseng.com/products/ppl On behalf of all the past and present developers listed at http://bugseng.com/products/ppl/credits and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella Abramo Bagnara BUGSENG srl (http://bugseng.com) -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com
Parma Polyhedra Library 0.12.1
The core development team is pleased to announce the availability of PPL 0.12.1, a new release of the Parma Polyhedra Library. This release includes portability improvements, a couple of new minor features, some interface changes and an important bug fix concerning the PIP solver. The precise list of user-visible changes is available at http://bugseng.com/products/ppl/download/ftp/releases/0.12.1/NEWS . For more information, please come and visit the new PPL web site at http://bugseng.com/products/ppl On behalf of all the past and present developers listed at http://bugseng.com/products/ppl/credits and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella Abramo Bagnara BUGSENG srl (http://bugseng.com) -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com
Parma Polyhedra Library 1.0
The core development team is very pleased to announce the availability of PPL 1.0, a new release of the Parma Polyhedra Library. This release includes support for the optimized representation of sparse vectors of coefficients, achieving significant performance improvements, e.g., when dealing with constraint systems describing weakly relational abstractions such as boxes and octagonal shapes. The precise list of user-visible changes is available at http://bugseng.com/products/ppl/download/ftp/releases/1.0/NEWS . For more information, please come and visit the PPL web site at http://bugseng.com/products/ppl sbpi1_bdiv_r.c On behalf of all the past and present developers listed at http://bugseng.com/products/ppl/credits and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella Abramo Bagnara BUGSENG srl (http://bugseng.com) -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com
Re: libtool for shared objects?
Basile STARYNKEVITCH wrote: But I'm not sure to understand the relation between libtool & $(LIBTOOL) (ie @libtool@) Any clues? Hi Basile, I will tell you what (I think) is the relation in projects using Autoconf, Automake and Libtool. @LIBTOOL@ is a placeholder that stands for the Libtool main script. In the Makefile.in files, you will find lines of the form LIBTOOL = @LIBTOOL@ At configure time, what has to take the place of the placeholder is computed. In the generated config.status file, you will find something like s,@LIBTOOL@,|#_!!_#|$(SHELL) $(top_builddir)/libtool,g and, consequently, in your Makefile files you will have LIBTOOL = $(SHELL) $(top_builddir)/libtool Thus the right way to invoke the libtool command is to use $(LIBTOOL) in the makefiles, as in install-data-local: ppl_sicstus.so $(LIBTOOL) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) \ $< $(DESTDIR)$(pkglibdir)/$< Some examples of use can be found in the Parma Polyhedra Library's Makefile.am files, but I am sure there are more authoritative sources out there (i.e., we may well misuse Libtool). I hope it helps, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
IEEE inexact-flag not working on the Alpha (despite -mieee-with-inexact)?
While testing the portability of the Parma Polyhedra Library, Abramo Bagnara
and myself identified the following apparent problem on the Alpha, whereby
the division 2/3 made on floats is flagged as exact. Here are the details:
$ cat sf.cc
#include
#include
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf("%d %.1000g\n", fetestexcept(FE_INEXACT) != 0, x);
}
$ g++ -v
Using built-in specs.
Target: alpha-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ g++ -mieee-with-inexact sf.cc
$ ./a.out
0 0.66686534881591796875
$ cat /proc/cpuinfo
cpu : Alpha
cpu model : EV56
cpu variation : 7
cpu revision: 0
cpu serial number :
system type : Rawhide
system variation: Tincup
system revision : 0
system serial number: AY74642662
cycle frequency [Hz]: 399642346 est.
timer frequency [Hz]: 1200.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS: 705.16
kernel unaligned acc: 0 (pc=0,va=0)
user unaligned acc : 31 (pc=2074c18,va=87)
platform string : AlphaServer 1200 5/400 4MB
cpus detected : 1
cpus active : 1
cpu active mask : 0001
L1 Icache : 8K, 1-way, 32b line
L1 Dcache : 8K, 1-way, 32b line
L2 cache: 96K, 3-way, 64b line
L3 cache: 4096K, 1-way, 64b line
$
We are not sure if this is a bug in GCC (we did search bugzilla though),
so we decided to post here before filing a bug report.
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: IEEE inexact-flag not working on the Alpha (despite -mieee-with-inexact)?
Andreas Schwab wrote:
Roberto Bagnara <[EMAIL PROTECTED]> writes:
$ cat sf.cc
#include
#include
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf("%d %.1000g\n", fetestexcept(FE_INEXACT) != 0, x);
You need to enable the FENV_ACCESS pragma (which is not yet implemented)
to get defined behaviour.
Hi Andreas,
thanks for your message. Do you mean that we need to enable the FENV_ACCESS
pragma to get defined behavior only on the Alpha or also elsewhere?
Moreover, do you mean that the FENV_ACCESS pragma is unimplemented for
the Alpha or unimplemented everywhere?
I am asking these questions because we observe this behavior only on the Alpha:
on all the other platforms we tested things seem to work fine. However, your
words could be interpreted as saying that, today, with GCC there is no way
to use feclearexcept() and fetestexcept() and get defined behavior.
Thanks again,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: IEEE inexact-flag not working on the Alpha (despite -mieee-with-inexact)?
Tim Prince wrote:
Roberto Bagnara wrote:
#include
#include
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf("%d %.1000g\n", fetestexcept(FE_INEXACT) != 0, x);
}
Is this a way of testing whether the division is performed at compile
time? Do you call it a bug if constant propagation occurs when you don't
take action to prevent it?
Hi Tim,
I am not sure I understand your message. However, before mailing I did
check that constant propagation is not an issue by checking the generated
assembly:
ldq $27,feclearexcept($29) !literal!2
jsr $26,($27),0 !lituse_jsr!2
ldah $29,0($26) !gpdisp!3
lda $29,0($29) !gpdisp!3
lds $f11,20($15)
lds $f10,16($15)
divs/sui $f11,$f10,$f12
trapb
cpys $f12,$f12,$f10
sts $f10,20($15)
ldah $16,32($31)
ldq $27,fetestexcept($29) !literal!4
jsr $26,($27),0 !lituse_jsr!4
Note that I am not compiling with optimizations and that the
divs/sui opcode is generated.
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: IEEE inexact-flag not working on the Alpha (despite -mieee-with-inexact)?
Andreas Schwab wrote: Roberto Bagnara <[EMAIL PROTECTED]> writes: thanks for your message. Do you mean that we need to enable the FENV_ACCESS pragma to get defined behavior only on the Alpha or also elsewhere? See the C standard, 7.6.1 The FENV_ACCESS pragma. The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes. ... If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined. I did read that, but I thought that, from a practical (i.e., not legal) standpoint, the issues were constant-propagation and other similar transformations, that is, something that seems unrelated to our testcase. Sorry if I insist, and thank you in advance for clarifying. Do you mean both the following? 1) Any program calling fetestexcept() without setting FENV_ACCESS "on" has undefined behavior, not only as far as the standard is concerned, but also in the GCC concrete world (meaning that GCC may really do no matter what if fetestexcept() is invoked with FENV_ACCESS "off"). 2) GCC does not implement a way to set FENV_ACCESS "on" so that fetestexcept() can be used reliably. I guess I misunderstood you either on point 1 or on point 2 or on both, because otherwise we would have that any program compiled with GCC and calling fetestexcept() has (in concrete terms) undefined behavior. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
More floating point problems on the Alpha
[Thanks to all those who responded to my previous problem-report
wrt to the IEEE inexact-flag on the Alpha. We have filed a bug
report for that one.]
Hi there,
we keep finding problems on the Alpha, and we are unsure about
what is going on. I anticipate that the present problem does
not seem to be a compiler issue (except that the -mieee-with-inexact
option promises full compliance with the IEEE floating point
standard). However, I hope some Alpha expert can advise about
how to investigate the issue further.
Here are the details:
$ cat bug.c
#include
float f = 1.4e-45;
double d = 1e-300;
int
main() {
if (1.4e-45f > 1e-300)
printf("compile-time test says 1.4e-45f > 1e-300\n");
if (f < d)
printf("run-time test says 1.4e-45f < 1e-300\n");
return 0;
}
$ gcc -mieee-with-inexact bug.c
$ ./a.out
compile-time test says 1.4e-45f > 1e-300
run-time test says 1.4e-45f < 1e-300
$ gcc -v
Using built-in specs.
Target: alpha-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ cat /proc/cpuinfo
cpu : Alpha
cpu model : EV56
cpu variation : 7
cpu revision: 0
cpu serial number :
system type : Rawhide
system variation: Tincup
system revision : 0
system serial number: AY74642662
cycle frequency [Hz]: 399642346 est.
timer frequency [Hz]: 1200.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS: 705.16
kernel unaligned acc: 0 (pc=0,va=0)
user unaligned acc : 35 (pc=2074c18,va=87)
platform string : AlphaServer 1200 5/400 4MB
cpus detected : 1
cpus active : 1
cpu active mask : 0001
L1 Icache : 8K, 1-way, 32b line
L1 Dcache : 8K, 1-way, 32b line
L2 cache: 96K, 3-way, 64b line
L3 cache: 4096K, 1-way, 64b line
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Warning: `z' is used uninitialized in this function
Just to make sure before I submit a bug report: when GCC says that
a certain variable _is_ (as opposed to _may be_) used uninitialized
in this function, it means that it has proved that the variable
is indeed used uninitialized, right?
I am asking because I have a testcase where g++ gives this warning for
`z' in the statement marked with (***) below. However, `z' is indeed
initialized by the mul() function template, which takes the first
argument by (non-const) reference:
template
inline Result
add_mul_int(Type& to, const Type x, const Type y, Rounding_Dir dir) {
Type z;
Result r = mul(z, x, y, dir);
switch (r) {
case V_NEG_OVERFLOW:
case V_LT:
if (to <= 0) {
to = z; (***)
return r;
}
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: Warning: `z' is used uninitialized in this function
Manuel López-Ibáñez wrote: On 11/10/2007, Roberto Bagnara <[EMAIL PROTECTED]> wrote: Just to make sure before I submit a bug report: when GCC says that a certain variable _is_ (as opposed to _may be_) used uninitialized in this function, it means that it has proved that the variable is indeed used uninitialized, right? Did you open a PR? I cannot find it. Not yet. I wanted to try to reduce my testcase, but I am currently snowed under other commitments. If you think it is acceptable, I could file a PR with the unreduced testcase and try to reduce it at a later stage. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Parma Polyhedra Library 0.11.1
We announce the availability of PPL 0.11.1, a new release of the Parma Polyhedra Library. This release includes several important bug fixes and performance improvements. The precise list of user-visible changes is available at http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.1/NEWS For more information, please come and visit the PPL web site at http://www.cs.unipr.it/ppl/ On behalf of all the past and present developers listed at http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS, Abramo Bagnara Roberto Bagnara Patricia M. Hill Enea Zaffanella -- Prof. Roberto Bagnara CEO & CTO Applied Formal Methods Laboratory BUGSENG srl Department of Mathematics Parco Area delle Scienze 53/A University of Parma, ItalyI-43124 Parma, Italy http://www.cs.unipr.it/~bagnara/ http://bugseng.com/ mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Parma Polyhedra Library 0.11.2
We announce the availability of PPL 0.11.2, a new release of the Parma Polyhedra Library. This release fixes a few minor bugs in PPL 0.11.1. The precise list of user-visible changes is available at http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.2/NEWS For more information, please come and visit the PPL web site at http://www.cs.unipr.it/ppl/ On behalf of all the past and present developers listed at http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS, Abramo Bagnara Roberto Bagnara Patricia M. Hill Enea Zaffanella -- Prof. Roberto Bagnara CEO & CTO Applied Formal Methods Laboratory BUGSENG srl Department of Mathematics Parco Area delle Scienze 53/A University of Parma, ItalyI-43124 Parma, Italy http://www.cs.unipr.it/~bagnara/ http://bugseng.com/ mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
