Package: gcc-4.4-doc
Version: 4.4.4.nf1-1
Severity: normal
The GCC 4.4 manual says:
-- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1,
EXP2)
You can use the built-in function `__builtin_choose_expr' to
evaluate code depending on the value of a constant
On 2010-05-31 01:24:50 +0200, Vincent Lefevre wrote:
On 2010-05-30 23:24:26 +0200, Matthias Klose wrote:
On 15.04.2010 11:46, Vincent Lefevre wrote:
On a Debian/stable machine (amd64), I got the following error:
tst-tomate-1268827996-3840.c:1000: fatal error: error writing to
/tmp
On 2010-05-06 12:51:46 +0100, Richard Kettlewell wrote:
Package: gcc-doc
deodand:~# apt-get install gcc-doc
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible
On 2010-05-30 23:24:26 +0200, Matthias Klose wrote:
On 15.04.2010 11:46, Vincent Lefevre wrote:
On a Debian/stable machine (amd64), I got the following error:
tst-tomate-1268827996-3840.c:1000: fatal error: error writing to
/tmp/317065.1.cas/ccmB9478.s: Success
compilation terminated
Package: gcc-4.3
Version: 4.3.2-1.1
Severity: normal
On a Debian/stable machine (amd64), I got the following error:
tst-tomate-1268827996-3840.c:1000: fatal error: error writing to
/tmp/317065.1.cas/ccmB9478.s: Success
compilation terminated.
How can a success be a fatal error???
BTW, I've
On 2009-11-01 15:22:43 +0100, Matthias Klose wrote:
it is *not* a dependency package; there are currently no tools like
policytool and javaws in this package.
OK, there are no tools. So, what's the point of this package?
This confuses the users.
--
Vincent Lefèvre vinc...@vinc17.net - Web:
reopen 547165
severity 547165 normal
thanks
On 2009-09-17 15:02:55 +0200, Matthias Klose wrote:
closing, wrong. see the hppa packages.
This answer is buggy: the hppa package also contains nothing:
http://packages.debian.org/sid/hppa/gcj-jre/filelist lists:
/usr/share/doc/gcj-jre
(which is
Package: gcj-jre
Version: 4:4.3.3-9
Severity: grave
Justification: renders package unusable
The description says:
Description: Java runtime environment using GIJ/classpath
GIJ is a Java bytecode interpreter, not limited to interpreting bytecode.
It includes a class loader which can dynamically
Package: java-gcj-compat-headless
Version: 1.0.80-5.1
Severity: wishlist
java-gcj-compat-headless depends on gij:
Depends: java-common (= 0.25), gij (= 4:4.3), fastjar, libgcj-bc (= 4.3),
libgcj9-jar (= 4.3), libmx4j-java (= 3.0.1), libgcj-common (= 1:4.4.0-2)
which is a transitional package:
On 2009-09-17 15:04:53 +0200, Matthias Klose wrote:
tags 547170 + wontfix
thanks
no, won't fix anything. java-gcj-compat is obsolete as well.
Then why doesn't aptitude list them as obsolete?
--
Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/
100% accessible validated
Package: gcc-4.3
Version: 4.3.3-15
Severity: normal
Note: this is a bug concerning the c99 utility, but since c99 uses
gcc, I report the bug against gcc. Also note that both gcc-4.4 and
gcc-snapshot have the same problem. I've also reported the bug on
GCC's bugzilla:
Package: gcc
Version: 4:4.3.3-8
Severity: normal
POSIX.1-2008 says[*]:
-I directory
Change the algorithm for searching for headers whose names are not
absolute pathnames to look in the directory named by the directory
pathname before looking in the usual places. Thus, headers
I've submitted a RFE on GCC here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
--
Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
retitle 524472 [PR tree-optimization/36765] gcc-4.3: gcc 4.3.2 strict-aliasing
bug / miscompiles GMP 4.3.0
thanks
I've added the upstream bug reference to the title, in case
someone else wonders...
--
Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/
100% accessible validated
On 2008-04-17 14:02:17 +0400, Alexei Sheplyakov wrote:
I don't think it's a bug. Rather, it's a wrong expectation from the
user side. You are comparing results of FP calculation done on 3
different platforms: ix87, sse2, and MPFR, and expect them to be the
same. I think your expectation is
Package: gcc-4.3
Version: 4.3.2-1.1
Severity: important
Tags: lenny
When I build GMP 4.3.0 with gcc 4.3.2, I get the following errors in
make check:
rootrem.c:338: GNU MP assertion failed: bn = qn
/bin/sh: line 4: 2231 Aborted (core dumped) ${dir}$tst
FAIL: reuse
rootrem.c:338:
retitle 524472 gcc-4.3: gcc 4.3.2 strict-aliasing bug / miscompiles GMP 4.3.0
thanks
I've tracked down the bug and managed to write a simple testcase:
/* With GCC 4.3.2 and -O2 option: output value is 1 instead of 0.
* If -fno-strict-aliasing is added, this bug disappears.
*/
#include stdio.h
Package: gcc-4.3-doc
Version: 4.3.0.nf1-1
Severity: normal
When I type info gcc, I get the manual of gcc 3.3:
File: gcc-3.3.info, Node: Top, Next: G++ and GCC, Up: (DIR)
whereas I expect to get the manual of gcc 4.3 (which is the version
of /usr/bin/gcc, in fact 4.3.1 whereas the manual is
Package: gcj-4.3
Version: 4.3.0-1
Severity: minor
/usr/share/man/man1/gc-analyze.1.gz is a dangling symlink:
vin% ls -l /usr/share/man/man1/gc-analyze.1.gz
lrwxrwxrwx 1 root root 19 2008-03-17 02:46:40
/usr/share/man/man1/gc-analyze.1.gz - gc-analyze-4.3.1.gz
vin% ls -lL
Package: cpp-4.1
Version: 4.1.1-21
Severity: normal
I get the following segmentation fault:
courge:...re/mpfr-2.3.1-rc1 gcc -DWANT_ASSERT=2 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1
-DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1
On 2007-12-28 14:26:04 +0100, Martin Michlmayr wrote:
* Vincent Lefevre [EMAIL PROTECTED] [2007-12-28 13:51]:
courge:...re/mpfr-2.3.1-rc1 gcc -DWANT_ASSERT=2 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1
-DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1
merge 458072 405065
thanks
On 2007-12-28 19:01:15 +0100, Martin Michlmayr wrote:
I can reproduce the problem with 4.1.1-21 from stable but not with
4.1.2-18 from testing/unstable. So I think this has been fixed
upstream (it might be PR30286 but I'm not sure).
I simplified the code and could
Package: g77-3.4
Version: 3.4.6-6
Severity: normal
vin:~ ls -l /usr/share/man/man1/i486-linux-gnu-g77-3.4.1
lrwxrwxrwx 1 root root 9 2007-07-30 16:13:45
/usr/share/man/man1/i486-linux-gnu-g77-3.4.1 - g77-3.4.1
but /usr/share/man/man1/g77-3.4.1 doesn't exist.
-- System Information:
Debian
On 2007-07-07 10:50:22 +0200, Matthias Klose wrote:
see http://gcc.gnu.org/ml/gcc/2007-06/msg00080.html
it's only supported for powerpc*-linux and x86*-linux
doesn't really work for x86*-linux unitl ... fixed a bunch of
back-end/middle-end bugs in 4.3
FYI, I wanted it just for
Package: gcc-4.2
Version: 4.2-20070528-1
Severity: wishlist
GCC 4.2 has partial support for decimal floating-point types (DFP):
http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html
But it seems that this is not enabled by default. I think that gcc
should be built with --enable-decimal-float
Package: gcc-4.1
Version: 4.1.1-21
Severity: important
I get the following crash when compiling MPFR 2.2.1, and contrary to
what is said, the crash is 100% reproducible.
$ /usr/bin/make
[...]
gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1
On 2006-12-30 22:12:07 +0100, Vincent Lefevre wrote:
I can reproduce the crash on this simple example:
int main (void)
{
int i;
for (i = 31 ; i = 0 ; i--)
{
volatile int x = 0;
}
return 0;
}
$ gcc -O2 -ftrapv -c gcc-bug.c
gcc-bug.c: In function 'main':
gcc
Package: java-gcj-compat
Version: 1.0.65-7
Severity: normal
The following files are dangling symlinks:
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/man/man1/gcj-dbtool.1.gz
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/man/man1/java.1.gz
I cannot reproduce this bug under Debian/unstable.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
--
To UNSUBSCRIBE, email to [EMAIL
Package: cpp-4.0
Version: 4.0.2-5
Severity: normal
As shown below, the __linux macro is no longer defined when using
the C99 mode on a PowerPC machine. An x86 machine does not have
this behavior. This is normal for the linux macro to be no longer
defined (as it is not reserved), but I do not see
Package: gcc-3.4
Version: 3.4.2-2
Severity: important
gcc -ftrapv aborts 0 * (-1), e.g.
#include stdio.h
int main (void)
{
volatile int i = 0, j = -1;
printf (%d, i * j);
return 0;
}
After a search on the GCC bugzilla, it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15526
which has
Package: gij-3.3
Version: 1:3.3.4-1
Severity: normal
Concerning the following Java source:
--
// $Id: test.java 3734 2004-06-21 15:36:52Z lefevre $
public class test {
public static void main(String[] args) throws Exception {
On 2004-03-24 08:03:40 +0100, Matthias Klose wrote:
Vincent Lefevre writes:
The second paragraph is incorrect. The IEEE754 standard has nothing
to do with that since it allows extended precision for intermediate
computations. This option just makes gcc more ISO C compliant, since
the ISO
Package: gcc-3.3
Version: 1:3.3.3-1
Severity: normal
The gcc man page says:
-ffloat-store
Do not store floating point variables in registers. This pre-
vents undesirable excess precision on machines such as the 68000
where the floating registers (of the 68881)
reassign libc6-dev
thanks
On 2003-10-01 09:28:12 +0200, Vincent Lefevre wrote:
Perhaps, but the definition of NAN in /usr/include/bits/nan.h
uses a gcc extension:
# define NAN \
(__extension__\
((union { unsigned __l
Package: gcc-3.3
Version: 1:3.3.2-0pre3
Severity: normal
When compiling the following program with gcc -std=c99
#include math.h
int main (void)
{
static double x = NAN;
return x == 0;
}
I get:
testconstnan.c: In function `main':
testconstnan.c:27: error: initializer element is not constant
101 - 136 of 136 matches
Mail list logo
