Bug#352790: gcc-4.0: gcc doesn't use locale for default input charset

[Samuel Thibault]

Package: gcc-4.0
Version: 4.0.2-8
Severity: normal
Tags: upstream

Hi,

Manual page says:

   -finput-charset=charset
   Set the input character set, used for translation from the charac-
   ter set of the input file to the source character set used by GCC.
   If the locale does not specify, or GCC cannot get this information
   from the locale, the default is UTF-8.  This can be overridden by
   either the locale or this command line option.  Currently the com-
   mand line option takes precedence if there's a conflict.  charset
   can be any encoding supported by the system's "iconv" library rou-
   tine.

€ locale charmap
ISO-8859-15

My ISO-8859-15-encoded test.c:

#include 
#include 
int main(void) {
setlocale(LC_ALL,"");
printf("|%lc|\n",L'ü');
return 0;
}

doesn't compile with a simple
$ gcc test.c -o test
test.c:5:19: error: converting to execution character set: Invalid argument

If I encode the file in utf-8, this works, whatever the current locale.

Apparently, the default is always utf-8. Gcc should use locale charset
as default input charset instead.

Regards,
Samuel

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages gcc-4.0 depends on:
ii  binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina
ii  cpp-4.0  4.0.2-8 The GNU C preprocessor
ii  gcc-4.0-base 4.0.2-8 The GNU Compiler Collection (base 
ii  libc62.3.6-1 GNU C Library: Shared libraries an
ii  libgcc1  1:4.0.2-8   GCC support library

Versions of packages gcc-4.0 recommends:
ii  libc6-dev 2.3.6-1GNU C Library: Development Librari
pn  libmudflap0-dev(no description available)

-- no debconf information

-- 
Samuel Thibault <[EMAIL PROTECTED]>
>Ever heard of .cshrc?
That's a city in Bosnia.  Right?
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)

Bug#173513: [Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||26282


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86

[aph at gcc dot gnu dot org]

--- Comment #4 from aph at gcc dot gnu dot org  2006-02-14 15:45 ---
A bit more explanation.

The problem is caused by the fact that 9007199254740994.0 + 0.847412109375
is carried out in extended precision, and the result is rounded to
9007199254740995.  In double precision, the result of this calculation is
rounded to 9007199254740994.

When the extended-precision value is rounded to double for storing, it is
rounded (again) to 9007199254740996.

So, double rounding leads gij to return a value of d that is 2.0, whereas it
should be 0.0.

Note however, that the true accurate value for d, calculated at infinite
precision, is 1-(2^-16).  So, the absolute error for gcj is 1+(2^-16) and the
absolute error with correct rounding is 1-(2^-16).  (I'm not surprised this
hasn't been reported as a problem with any real applications!)

It might be worth setting the floating-point precision of gcj to double, but
that would only fix the double-precision case, and I presume we'd still have
the same double rounding problem for floats.  

And in any case, I do not know if libcalls would be affected by being entered
with the FPU in round-to-double mode.  We might end up breaking things.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86

[vincent at vinc17 dot org]

--- Comment #5 from vincent at vinc17 dot org  2006-02-14 17:03 ---
(In reply to comment #4)
> Note however, that the true accurate value for d, calculated at infinite
> precision, is 1-(2^-16).  So, the absolute error for gcj is 1+(2^-16) and the
> absolute error with correct rounding is 1-(2^-16).  (I'm not surprised this
> hasn't been reported as a problem with any real applications!)

Note that some algorithms may be sensitive to this difference. I give an
example in  (The
Euclidean division implemented with a floating-point division and a floor); the
effect of extended precision is dealt with in Section 5.

A second problem is the reproducilibity of the results on various
architectures. Under probabilistic hypotheses, there should be something like 1
case over 2048 that is incorrectly rounded (in the real world, this is much
less).

> It might be worth setting the floating-point precision of gcj to double, but
> that would only fix the double-precision case, and I presume we'd still have
> the same double rounding problem for floats.  

Yes, however doubles are nowadays used much more often than floats, IMHO. I
think that fixing the problem for the doubles would be sufficient (as it is
probably too difficult to do better), though not perfect.

> And in any case, I do not know if libcalls would be affected by being entered
> with the FPU in round-to-double mode.  We might end up breaking things.

The only glibc function for which problems have been noticed is pow in corner
cases. See . And it is
also inaccurate when the processor is configured in extended precision; so in
any case, users shouldn't rely on it. I'd be interested in other cases, if any.

More information here: 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#352859: cpp: -iquote behaves wrong but -I- still works correct

[Mathias Krause]

Subject: cpp: -iquote behaves wrong but -I- still works correct
Package: cpp
Version: 4:4.0.2-2
Severity: normal

The preprocessor from gcc 4.0.x behaves wrong when using the "-iquote"
option as recommended by a warning when using "-I-".

The problem is that it doesn't honors the include directories specified
with "-iquote" within header files when a file with the same name as the
one to include resists in the same directory as the file currently being
processed.

To make this more clear imagine the following directory layout:

[EMAIL PROTECTED]:~/gcc-test$ find . -type f
./arch/foo.h
./arch/bar.h
./inc/foo.h
./inc/bar.h
./test.c
[EMAIL PROTECTED]:~/gcc-test$


The files have the following contents:

[EMAIL PROTECTED]:~/gcc-test$ cat arch/foo.h
#ifndef foo_h_arch
#define foo_h_arch
#include   // should include inc/bar.h
#endif
[EMAIL PROTECTED]:~/gcc-test$ cat arch/bar.h
#ifndef bar_h_arch
#define bar_h_arch
#endif
[EMAIL PROTECTED]:~/gcc-test$ cat inc/foo.h
#ifndef foo_h
#define foo_h
#include "bar.h"  // should include arch/bar.h
#endif
[EMAIL PROTECTED]:~/gcc-test$ cat inc/bar.h
#ifndef bar_h
#define bar_h
#endif
[EMAIL PROTECTED]:~/gcc-test$ cat test.c
#include   // does it all wrong
#include "foo.h"  // other way works ok
[EMAIL PROTECTED]:~/gcc-test$


Now the output when invoking cpp one time with the old deprecated option
-I- and after that with the recommended -iquote. I used an additional -H
to see which files get processed when:

[EMAIL PROTECTED]:~/gcc-test$ cpp -H -Iarch -I- -Iinc test.c > /dev/null
cc1: note: obsolete option -I- used, please use -iquote instead
. inc/foo.h
.. arch/bar.h
. arch/foo.h
.. inc/bar.h
[EMAIL PROTECTED]:~/gcc-test$ cpp -H -iquote arch -Iinc test.c > /dev/null
. inc/foo.h
.. inc/bar.h
. arch/foo.h
.. inc/bar.h
[EMAIL PROTECTED]:~/gcc-test$


The two commands should be equivalent but aren't. As you can see the
second run does it wrong by including inc/bar.h from within inc/foo.h
and not arch/bar.h as supposed to be. The old syntax does it right by
including arch/bar.h from inc/foo.h since the include directive is made
with quotes not brackets.
The other way (including <..>-headers) from within quoted ".."-headers
works correct for both versions.

I've created a tarball with the above mentioned files for a quick self
test. It's available at [1].

I also took a look at the bug mailing list at gcc.gnu.org but haven't
found this bug there. Maybe I'm the only one using this feature to
separate the order of header file inclusion.


I hope this information helps to get this bug fixed soon.


Yours sincerely,
Mathias Krause

[1] http://www.informatik.tu-cottbus.de/~mkrause/gcc4-iquote-bug.tar.gz

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-mk
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages cpp depends on:
ii  cpp-4.0   4.0.2-9The GNU C preprocessor

cpp recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#352859: cpp: -iquote behaves wrong but -I- still works correct

[Jeremy Nimmer]

On Tue, 2006-02-14 at 19:45 +0100, Mathias Krause wrote:
> The preprocessor from gcc 4.0.x behaves wrong when using the "-iquote"
> option as recommended by a warning when using "-I-".

The documentation states:

 In addition, `-I-' inhibits the use of the directory of the current
 file directory as the first search directory for `#include "FILE"'.

I believe that this is the behavior you are relying on.  The -iquote
option does not do this, nor can I find an alternative switch that does
so.

A quick google search of "site:gcc.gnu.org iquote" finds a good chunk of
relevant information.  Please check it out.

Anyway, gcc is behaving as documented, AFAICT.  You may wish to
re-purpose this bug as a wishlist "Please undeprecate -I-" or somesuch.

Thanks,
- Jeremy




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#188943: [Bug c++/10891] code using dynamic_cast causes segfaults when -fno-rtti is used

[dbaron at dbaron dot org]

--- Comment #6 from dbaron at dbaron dot org  2006-02-14 22:29 ---
Was it really necessary to break dynamic_cast() with -fno-rtti ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10891

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#349617: Fixed

[Gustaf Räntilä]

Seems fixed in either newer gcj or Eclipse, so this bug is no more.
Thanks someone.

/Gustaf



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]