[Bug libstdc++/35353] C++ wide character locale doesn't work

2010-04-07 Thread luca dot barbieri at gmail dot com


--- Comment #15 from luca dot barbieri at gmail dot com  2010-04-08 02:33 
---
Why can't wcout simply convert to the selected encoding, and append the results
to the cout buffer, as if the converted string had been directly output to
cout?

I'm not sure about the implementation details, but I fail to see how anything
could prevent adopting this rather obvious solution.

Of course, if cout is in the middle of the byte sequence of a character, this
will not result in sensible output, but that is user error and I fail to see
how such use could be made meaningful.

BTW, doesn't cout share the stdout buffer via the GNU libio FILE/iostream
sharing mechanism, making sync_with_stdio do nothing anyway?


-- 


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



[Bug c++/40895] New: ICE in tsubst, at cp/pt.c:9687 with variadic templates

2009-07-28 Thread luca dot barbieri at gmail dot com
With G++ 4.3.3 and 4.4.0 from Ubuntu Jaunty, I get:
ice.cpp: In instantiation of ‘s<0>’:
ice.cpp:19:   instantiated from here
ice.cpp:14: internal compiler error: in tsubst, at cp/pt.c:9687

from this test program:
int foo(int x, ...);

template
int bar()
{
return 0;
}

template
struct s
{
template
static inline void
f(typeof(foo(bar<_T>()...)) a)
{
}
};

s<0> g;


-- 
   Summary: ICE in tsubst, at cp/pt.c:9687 with variadic templates
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luca dot barbieri at gmail dot com


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



[Bug middle-end/24932] GCC segfault's on strcmp in tree.c:annotate_with_file_line

2005-12-24 Thread barbieri at gmail dot com


--- Comment #5 from barbieri at gmail dot com  2005-12-24 22:47 ---
any news on this front?

I'll present a tutorial in LinuxConf.au and need to know if front-end should
provide the information or middle-end should handle it.

In both cases I'll provide the patch to gcc, but I need to know where the bug
is.


-- 


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



[Bug middle-end/24932] GCC segfault's on strcmp in tree.c:annotate_with_file_line

2005-12-07 Thread barbieri at gmail dot com


--- Comment #4 from barbieri at gmail dot com  2005-12-07 10:49 ---
So, this is a bug.

I just need a confirmation if it's a bug in the middle-end layer, so there is
already a patch, or if this is a bug in the front-end, then I will add the
check to the gimplify code.

Since there is no documentation on the expected behaviour, we need to be safe.

Also, it would be good to have this before our presentation at LinuxConf.AU,
then we can be sure what's expected and how to teach others.


-- 


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



[Bug middle-end/24932] GCC segfault's on strcmp in tree.c:annotate_with_file_line

2005-11-18 Thread barbieri at gmail dot com


--- Comment #3 from barbieri at gmail dot com  2005-11-18 18:36 ---
Created an attachment (id=10276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10276&action=view)
gcc-lower_function_body.patch

Alternative patch that also fix seg fault, but earlier.

It's uglier than the previous, and is more restricted, since it just protect
the behaviour from gimple-low.c:lower_function_body(), while the previous patch
does the check for every use of annotate_with_file_line, used by
SET_EXPR_LOCATION.

I cannot know if this is a bug in the middle-end, since there is no
documentation on when I need to set this value. If so, probably we can use
gcc_assert() to confirm this?


-- 


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



[Bug middle-end/24932] GCC segfault's on strcmp in tree.c:annotate_with_file_line

2005-11-18 Thread barbieri at gmail dot com


--- Comment #1 from barbieri at gmail dot com  2005-11-18 18:09 ---
Created an attachment (id=10274)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10274&action=view)
gcc-annotate_with_file_line.patch

Fix segfault


-- 


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



[Bug middle-end/24932] New: GCC segfault's on strcmp in tree.c:annotate_with_file_line

2005-11-18 Thread barbieri at gmail dot com
I'm writing a tutorial on a HelloWorld compiler front-end for GCC
(http://svn.gna.org/viewcvs/gsc/branches/hello-world/doc/hello.xml) and noticed
that a function with statements but no DECL_SOURCE_FILE set, seg-faults on 
cgraph_finalize_function(), because it calls
gimple-low.c:lower_function_body(), which in turn does:

SET_EXPR_LOCATION (x, cfun->function_end_locus);

however, if cfun->function_end_locus is empty ({NULL, 0}), it will call
tree.c:annotate_with_file_line() with file=NULL, and it will fail on this "if":

  if (last_annotated_node
  && last_annotated_node->line == line
  && (last_annotated_node->file == file
  || !strcmp (last_annotated_node->file, file)))

because strcmp (last_annotated_node->file, file), with file=NULL will
seg-fault.

The attached patch checks if file is NULL before using strcmp.

The program that fails build is:
http://svn.gna.org/viewcvs/gsc/branches/hello-world/compiler/hello1.c?rev=551


-- 
   Summary: GCC segfault's on strcmp in
tree.c:annotate_with_file_line
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: barbieri at gmail dot com


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



[Bug libgcj/21140] New: Charset.encode and Charset.decode broken

2005-04-20 Thread luca dot barbieri at gmail dot com
Charset.encode and Charset.decode only work for a single call.

The reason is that the encoder/decoder is cached and after the first call it
will be in the flushed state.

The second call will thus throw an InvalidStateException.

Removing the cache or resetting the cached object should solve this.

-- 
   Summary: Charset.encode and Charset.decode broken
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luca dot barbieri at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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


[Bug libgcj/21136] tryLock waits for the lock, and lock doesn't

2005-04-20 Thread luca dot barbieri at gmail dot com

--- Additional Comments From luca dot barbieri at gmail dot com  2005-04-21 
00:25 ---
Created an attachment (id=8693)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8693&action=view)
Patch


-- 


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


[Bug libgcj/21136] New: tryLock waits for the lock, and lock doesn't

2005-04-20 Thread luca dot barbieri at gmail dot com
In gnu.java.nio.channels.FileChannelImpl tryLock and lock call the native lock
functions with incorrect wait parameters: tryLock passes true and lock false.

Of course, tryLock should pass false and lock should pass true.

Patch attached.

-- 
   Summary: tryLock waits for the lock, and lock doesn't
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luca dot barbieri at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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


[Bug java/21036] New: gcj ICE compiling Azureus 2.2.0.2 to native code

2005-04-14 Thread luca dot barbieri at gmail dot com
Description of problem:

gcj ICEs compiling Azureus 2.2.0.2 to native code.

Version-Release number of selected component (if applicable):
gcc-java-4.0.0-0.42 from RedHat Fedora Core Development

How reproducible:
Always

Steps to Reproduce:
1. Download and unpack Azureus 2.2.0.2 from
http://azureus.sourceforge.net/download.php
2. Run gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic
--classpath=swt.jar:swt-pi.jar:swt-mozilla.jar Azureus2.2.0.2.jar -o
Azureus2.2.0.2.jar.so
  
Actual results:
org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java: In class
'org.gudy.azureus2.core3.tracker.client.classic.TrackerStatus':
org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java: In method
'org.gudy.azureus2.core3.tracker.client.classic.TrackerStatus.scrapeUDP(java.net.URL,java.io.ByteArrayOutputStream,byte[])':
org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java:813: internal
compiler error: in update_aliases, at java/decl.c:166
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.

Expected results:
Success.

Additional info:
Happens with several other sets of command line options (including no options
except --classpath and -o).

-- 
   Summary: gcj ICE compiling Azureus 2.2.0.2 to native code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: luca dot barbieri at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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