[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-04-20 06:21 --- Created an attachment (id=11300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11300action=view) tonto-1.0 input file stdin.h.uhf With this attachment as input I get a successful output with tonto-1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-04-20 06:25 --- Created an attachment (id=11301) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11301action=view) tonto-1.0 output for stdin.h.uhf Here is the output from the above patch. When I go to stdin.h2o.blyp I get a segfault. Valgrind is showing unitialized values being used. I am not using the spec version of tonto. I am using the 1.0 download from sourceforge. An added note, when attempting to compile tonto with the -g option I got an ice related to transfer. I will have to take another look later and report back here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #9 from igodard at pacbell dot net 2006-04-20 08:20 --- I believe it is a bug because my declaration should not be able to hijack the use inside the STL, which should only be seeing the declarations that were visible where the STL function was defined, which did not include any of my code. That is, my operator should not have been on the resolution list for the STL use. Your example has the STL declaration *after* the operator declaration, so the operator is visible. The test case I sent in had the STL first. Also, even if my operator was visible, why was it called when it wants a specReg left operand and didn't get one? The other overloads also all want particular classes as left operands, and the STL case should have been none of them, even if they were visible. You have created a case where the left operand is int but mine declarations all have particular classes as left operand. The operator,() is used here as a metaprogramming device so that a comma-separated list can be eaten and and its elements lightly processed and then saved in a compile-time structure for later processing. The particular situation requires that the form be syntactically a comma-separated list, and some other operator or functional notation would not do. As I recall, the swapping template was because I needed to work around a language restriction whereby operator,() cannot discriminate on the second operand (being by definition defined for left operand and anything). The swapping let me double-dispatch so I could dispatch (in the second invocation) on what had been the right operand but was now the left. But I no longer recall. Is there anything in the Standard that precludes having a templated operator,()? I'd guess that the same bug might be evidenced with operator and operator|| as well, because these three have nonstandard (er - uncommon) binding behavior. Hope this helps Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug tree-optimization/27218] [4.1/4.2 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-20 08:44 ---
(gdb) call debug_generic_expr(stmt)
*(struct VectorD.1984 *) D.2012 = dD.1989
that's not gimple. We trip over that in into-ssa.
(gdb) call debug_bb_n(2)
;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 1
;; pred: ENTRY (fallthru)
;; succ: EXIT
bb 2:
D.2013 = operator new (16);
D.2012 = (struct Point *) D.2013;
*(struct Vector *) D.2012 = d;
return;
We gimplified that to
void add_duck() ()
{
struct Point * D.2012;
void * D.2013;
D.2013 = operator new (16);
D.2012 = (struct Point *) D.2013;
try
{
*D.2012 = f () [return slot optimization];
}
catch
{
operator delete (D.2012);
}
}
but after inlining we get
void add_duck() ()
{
void * D.2013;
struct Point * D.2012;
bb 2:
D.2013 = operator new (16);
D.2012 = (struct Point *) D.2013;
*(struct Vector *) D.2012 = d;
return;
}
So inlining produces the non-gimple trees.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
GCC build triplet|i486-linux-gnu |
GCC host triplet|i486-linux-gnu |
GCC target triplet|i486-linux-gnu |
Summary|[4.1/4.2 regression] ICE in |[4.1/4.2 regression] ICE in
|get_indirect_ref_operands, |get_indirect_ref_operands,
|at tree-ssa-operands.c:1515 |at tree-ssa-operands.c:1515,
||inlining produces non-gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #10 from pcarlini at suse dot de 2006-04-20 09:10 --- Well, two comments: first, I cannot reproduce with current mainline. Second, frankly, if the implication of the issue is that in the entire implementation of algorithm we cannot use operator, only to allow the user to write unrestricted operator, templates in the face of the ADL trickeries, then, well, I don't think we are going to buy that. Before closing this I'm only curious to know why mainline is fine, maybe, simply, ADL was too zelant here? Any language lawyer kicking in? -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #11 from pcarlini at suse dot de 2006-04-20 09:25 --- (In reply to comment #10) Before closing this I'm only curious to know why mainline is fine, maybe, simply, ADL was too zelant here? Any language lawyer kicking in? The reason seems trivial, actually: in mainline vector is a little different (better ;) and avoids some pointless calls to copy/fill. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #12 from igodard at pacbell dot net 2006-04-20 09:28 --- I don't think that the problem is in the STL. The STL can be as tricky as it wants, including use of operator,(). It should not be possible for the actual operator,()s I declared to hijack the STL the way that happened, because 1) my declarations were out of scope for the STL code and 2) their signatures did not match the STL call site. This suggests a compiler bug to me, not an STL mis-design. A bug for this operator is not unlikely, because operator,() has unusual semantics that would force non-standard handling within the compiler, and the special code for it is probably not exercised as well as the main operator invocation path. It certinly looks to me like a template that uses operator,() that is defined before a second declaration of that operator but instantiated after the second declaration is seeing the second dec when parsing the body of the instantiation Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #13 from igodard at pacbell dot net 2006-04-20 09:31 --- p.s. Another requirement for the failure probably is that the second declaration has to be a templated operator,() of the form I used i.e. right argument a free template argument. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 --- (In reply to comment #12) I don't think that the problem is in the STL. The STL can be as tricky as it wants, including use of operator,(). It should not be possible for the actual operator,()s I declared to hijack the STL the way that happened, because 1) my declarations were out of scope for the STL code and 2) their signatures did not match the STL call site. This suggests a compiler bug to me, not an STL mis-design. Actually, I'm not at all sure, given: 1- our vector::iterator not being a built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size and _OutputIterator). Again, I'm not a language lawyer, but I think that, strictly speaking, the compiler may legally find and match your operator, I can certainly patch fill_n to avoid the operator, no big deal, my question is more general, whether, given our class-type vector::iterator, given the unrestrictedness of many algorithm templates, given current ADL rules, whether it makes sense for us to go that route trying piecewise to improve now the library, in the current C++03 framework. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27223] New: Compiled program crashes when it gets SIGNAL 19 many times.
My compiled program crashes when it receives many SIGNALs 19 from outside. It
also crashes when another signal is used, if the 'disposition f(int)' is set on
it.
Sun Solaris 8 on intel 2*CPU Pentium III Xeon.
GCC is from the sunfreeware.com bundle.
I tries it on the Sun Solaris 8 on 1*CPU UltraSparc IIi and on the Sun
Solaris 8 on many CPUs*CPU UltraSparc III. It does NOT crash on these
systems.
The program is:
#include signal.h
#include vector
void f(int)
{
}
int main(int argc, char* argv[])
{
typedef std::vectorint V;
::sigset(19, f);
while ( true ) {
V *v1 = new V();
for(int n=0; n1000; n++)
v1-push_back(n);
V *v2 = new V(*v1);
delete v1;
delete v2;
}
}
I compile it this way:
[EMAIL PROTECTED]:/home/barsuk/src/gcc-bugg++ -v -save-temps test.cpp
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nl
Thread model: posix
gcc version 3.4.2
/usr/local/libexec/gcc/i386-pc-solaris2.8/3.4.2/cc1plus -E -quiet -v test.cpp
-o test.ii
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/../../../../i386-pc-solaris2.8/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/../../../../include/c++/3.4.2
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/../../../../include/c++/3.4.2/i386-pc-solaris2.8
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/../../../../include/c++/3.4.2/backward
/usr/local/include
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i386-pc-solaris2.8/3.4.2/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -auxbase test -version -o test.s
GNU C++ version 3.4.2 (i386-pc-solaris2.8)
compiled by GNU C version 3.4.2.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65485
/usr/ccs/bin/as -V -Qy -s -o test.o test.s
as: Sun WorkShop 6 99/08/16
/usr/local/libexec/gcc/i386-pc-solaris2.8/3.4.2/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -Qy /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/crt1.o
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/crti.o /usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/crtbegin.o
-L/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2 -L/usr/ccs/bin -L/usr/ccs/lib
-L/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/../../.. test.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/crtend.o
/usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.299
That I run the program:
./a.out
In the next terminal window I run the script:
while true ; do pkill -19 a.out ; done
The program a.out crashes:
Segmentation Fault(coredump)
I run gdb:
[EMAIL PROTECTED]:/home/barsuk/src/gcc-buggdb a.out core
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-pc-solaris2.8...(no debugging symbols found)
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libstdc++.so.6...done.
Loaded symbols for /usr/local/lib/libstdc++.so.6
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
#0 0x08052696 in std::_Destroy__gnu_cxx::__normal_iteratorint*,
std::vectorint, std::allocatorint()
(gdb) bt
#0 0x08052696 in std::_Destroy__gnu_cxx::__normal_iteratorint*,
std::vectorint, std::allocatorint()
#1 0x08052336 in std::vectorint, std::allocatorint ::_M_insert_aux ()
#2 0x08051edf in std::vectorint, std::allocatorint ::push_back ()
#3 0x08051d51 in main ()
(gdb)
I suggest the problem is in STL, when the memory copy routine is interrupted by
the signal. May be somewhere in STL the value on errno, when it equals EINTR,
is not handled correctly.
--
Summary: Compiled program crashes when it gets SIGNAL 19 many
times.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
[Bug c++/27223] Compiled program crashes when it gets SIGNAL 19 many times.
--- Comment #1 from ademin at gmail dot com 2006-04-20 09:38 --- Created an attachment (id=11302) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11302action=view) .ii file of test case program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27223
[Bug libgcj/25414] should update rmic
--- Comment #5 from aph at gcc dot gnu dot org 2006-04-20 09:39 --- Subject: Bug 25414 Author: aph Date: Thu Apr 20 09:39:22 2006 New Revision: 113113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113113 Log: 2006-04-05 Archit Shah [EMAIL PROTECTED] PR java/25414 * gnu/java/rmi/rmic/CompilerProcess.java (computeTypicalArguments): Add classpath argument. * gnu/java/rmi/rmic/Compile_gcj.java (computeArguments): Adjust caller. * gnu/java/rmi/rmic/Compile_jikes.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compile_kjc.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compiler.java (getClasspath, setClasspath): New. * gnu/java/rmi/rmic/RMIC.java: Set classpath for compiler, call mkdirs for destination directory, correct handling of superclasses and interfaces of the remote class, correct handling of exceptions declared by remote methods. Modified: branches/gcj/gcj-abi-stabilization-branch/libjava/ChangeLog branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/Compile_gcj.java branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/Compile_jikes.java branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/Compile_kjc.java branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/Compiler.java branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/CompilerProcess.java branches/gcj/gcj-abi-stabilization-branch/libjava/gnu/java/rmi/rmic/RMIC.java branches/gcj/gcj-abi-stabilization-branch/libjava/java/lang/Class.h branches/gcj/gcj-abi-stabilization-branch/libjava/java/lang/Object.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug c++/27223] Compiled program crashes when it gets SIGNAL 19 many times.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 09:54 --- This is more likely a problem with your kernel/libc than with libstdc++ or gcc. Also on linux i386 signal 19 is SIGSTOP, for which sigset returns SIG_HOLD. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27223
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #15 from pcarlini at suse dot de 2006-04-20 09:56 ---
We can easily get a reference to the user defined operator, from the mainline
compiler with:
templatetypename T
int operator,(int i, T t) { return i; }
#include vector
int main()
{
std::vectorint v;
std::fill_n(v.begin(), 0, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #16 from igodard at pacbell dot net 2006-04-20 09:57 --- Well, I don't see how the templating of the STL code can influence whether or not my declarations are in scope or not. BTAIM, my declarations are certainly inappropriate for what the STL is looking for at the call site. Assuming that user declarations are in scope, the only thing I can think of that the STL might do to avoid unwittingly falling into user code in cases like this is to apply boost-style concept checks, which would have immediately eliminated my operators from consideration in this case. However, adding concept checks to a large hunk of wooly code is not trivial. We use them, and our experience is that they are well worth the effort because they expose subtle bugs in our semantics, but they are not free to implement, especially if the code was not originally written with concept-checking in mind. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #17 from igodard at pacbell dot net 2006-04-20 09:58 --- Yes, you pick up my operator in Wolfgang's test case. But in the original submission the vector code is *before* my operators, which are consequently out of scope for the STL code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27223] Compiled program crashes when it gets SIGNAL 19 many times.
--- Comment #3 from ademin at gmail dot com 2006-04-20 10:12 --- (In reply to comment #2) This is more likely a problem with your kernel/libc than with libstdc++ or gcc. Also on linux i386 signal 19 is SIGSTOP, for which sigset returns SIG_HOLD. Now I tried it with signal 17. The result is same -- crash. Do you suggest than I have to upgrade libc or update the solaris kernel? -- ademin at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27223
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #18 from pcarlini at suse dot de 2006-04-20 10:20 ---
This is a self-contained example:
namespace mine1
{
struct mini_iter
{
mini_iter(int* p)
: _M_current(p) { }
int
operator*() const
{ return *_M_current; }
mini_iter
operator++()
{
++_M_current;
return *this;
}
private:
int* _M_current;
};
}
namespace mine2
{
templatetypename _OutputIterator, typename _Size, typename _Tp
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp __value)
{
for (; __n 0; --__n, ++__first)
*__first = __value;
return __first;
}
void f(int* p) { fill_n(mine1::mini_iter(p), 1, 1); }
}
templatetypename T
int operator,(int i, T t) { __builtin_trap(); return i; }
int main()
{
int arr[1];
mine2::f(arr);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #13 from jakub at gcc dot gnu dot org 2006-04-20 10:27 --- This has been introduced in http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01594.html Will try to revert the name-lookup.c part and see what exactly breaks and if we couldn't tell about this to cgraph rather than doing ugly hacks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/27102] [4.0/4.1 regression] ICE with invalid class name in function template
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-20 10:45
---
Mark, your patch doesn't cover the following case which still crashes
on mainline:
===
templatetypename T void T::X::foo() {}
===
The ICE is not in is_ancestor anymore, though:
PR27102B.cc:6: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:422
Please submit a full bug report, [etc.]
Would you mind having a look?
Or should I file a different PR for this case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27223] Compiled program crashes when it gets SIGNAL 19 many times.
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-20 10:49 --- I would suggest using SIGUSR1 for testing, malloc and free are not affected by signal interruption. So if they are, this is internal to the Solaris libc or the kernel. At a first guess I would suggest updating the Solaris libc, then maybe the kernel. On another note, gcc 3.4.2 is no longer supported, the oldest supported version is 4.0.3 (though this is really no gcc problem). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|g++ -v -save-temps test.cpp | GCC host triplet|Sun Solaris 8 on intel 2*CPU| |Pentium III Xeon| GCC target triplet|GCC 3.4.2 |i686-*-solaris http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27223
[Bug c/27224] New: Read twice and write on a variable in same expression
The compiler doesn't warn when you read a variable twice in an expression where you also write it. Look at http://www.research.att.com/~bs/bs_faq2.html#evaluation-order to see the description of the problem. (GCC) 3.4.4 (mingw special) c++ -Wall -pedantic -ansi -- Summary: Read twice and write on a variable in same expression Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: moura at kdewebdev dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement
--- Comment #5 from wouter dot vermaelen at pi dot be 2006-04-20 10:58
---
I think something similar happens for the following code.
int f(int a) {
switch (a 7) {
case 0: return 2;
case 1: return 3;
case 2: return 5;
case 3: return 7;
case 4: return 11;
case 5: return 13;
case 6: return 17;
case 7: return 19;
}
}
Part of the generated code looks like this:
movl8(%ebp), %eax
andl$7, %eax
cmpl$7, %eax
jbe .L15
popl%ebp
ret
.p2align 4,,15
.L15:
jmp *.L11(,%eax,4)
The test for values bigger than 7 is clearly not needed here.
I don't know much about compiler technologie, but maybe this specific case is
easier to solve with some peephole optimization?
I have seen real code (Z80 emulator or HQ2x scaler algorithm) that does a
switch on a unsigned char and handles all 256 cases. Code like that would
benefit from this optimization.
Thanks.
--
wouter dot vermaelen at pi dot be changed:
What|Removed |Added
CC||wouter dot vermaelen at pi
||dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14495
[Bug ada/27225] New: Wide_String slice assignment in nested procedure does not work properly
The following program should not raise Program_Error, but does. procedure p is procedure (txt: WIDE_STRING) is pragma Assert(txt'length 0, string is empty); result: WIDE_STRING(txt'first .. txt'first + 3); begin result(txt'first .. txt'first + 3) := ; if result(txt'first .. txt'first + 3) /= then raise program_error; end if; end ; begin (_); end p; URL: svn://gcc.gnu.org/svn/gcc/tags/gcc_4_1_0_release Revision: 113107 Linux sonnenregen 2.6.12-10-686-smp #1 SMP Sat Mar 11 16:41:12 UTC 2006 i686 GNU/Linux -- Summary: Wide_String slice assignment in nested procedure does not work properly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27225
[Bug ada/27225] Wide_String slice assignment in nested procedure does not work properly
--- Comment #1 from bauhaus at futureapps dot de 2006-04-20 11:28 --- I forgot: $ gnatmake p $ ./p raised PROGRAM_ERROR : p.adb:11 explicit raise (The Assert is a relic of an earlier program and not an issue.) -- bauhaus at futureapps dot de changed: What|Removed |Added GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27225
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #19 from pcarlini at suse dot de 2006-04-20 11:32 --- By the way, I think I mentioned incorrectly ADL, which, in this specific case, doesn't seem involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #12 from patchapp at dberlin dot org 2006-04-20 11:45 --- Subject: Bug number PR27084 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00750.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #20 from pcarlini at suse dot de 2006-04-20 11:56 --- Everything considered, I don't think there is something to fix here, either in the compiler (and all the other compilers I tried bahaves the same of current g++ on Comment #18, irrespective of the position of the overloaded operator, of course) or in the library: agreed, std::fill_n could be made more robust restricting the second template argument, but this is really matter for C++0x. Otherwise, the problem would immediately go away if vector::iterator were a plain pointer, but that is not an option for our implementation. Agreed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #21 from pcarlini at suse dot de 2006-04-20 11:59 --- (In reply to comment #20) std::fill_n could be made more robust restricting the second template argument, Scratch this bit, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #14 from jakub at gcc dot gnu dot org 2006-04-20 12:04 ---
The reversal of the DECL_UID (x) = DECL_UID (t); assignment in name-lookup.c
causes
FAIL: g++.dg/opt/inline2.C (test for excess errors)
as well as
// { dg-do link }
// { dg-options -O1 }
static int g;
void f()
{
extern int g;
g++;
}
int main () {
f ();
}
regression.
For some of the duplicate decls in different binding levels I'm pretty sure we
could just duplicate_decls instead of keeping two decls around, but as the
comment explains e.g. for
static int g (int x, int y = 8);
void f ()
{
int g (int x, int y = 12);
g (6);
}
int g (int x, int y)
{
return x + y;
}
int main ()
{
f ();
g (6);
}
we need two decls, at least throughout the frontend. On the other side, the
two
decls are really supposed to share all cgraph {,varpool} node properties,
except
the decl itself (and uid), so I wonder if we couldn't have indirect nodes in
cgraph_hash and cgraph_varpool_hash or something similar for this purpose.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c/27224] Read twice and write on a variable in same expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-20 12:04 ---
It's called -Wsequence-point, but it's not perfect. See also PR18050.
int *v;
int i;
void f(int, int);
void foo(void)
{
v[i] = i++;
f(v[i], i++);
}
/space/rguenther/install/gcc-3.4.4/bin/gcc -Wsequence-point -c t.c
t.c: In function `foo':
t.c:6: warning: operation on `i' may be undefined
t.c:7: warning: operation on `i' may be undefined
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Keywords||diagnostic
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug c/27224] Read twice and write on a variable in same expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 12:05 --- Oh, you used C++ but filed against C. Reopen bug... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug c++/27224] Read twice and write on a variable in same expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-20 12:06 --- ... to close as fixed in 4.0.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |c++ Known to fail||3.4.4 Known to work||4.0.0 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 13:52 --- I have a patch to teach GVN tree-combining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-20 13:54 ---
Which, for the testcase in comment #4 gives us
;; Function f (f)
Created value VH.0 for a_1
Created value VH.1 for *VH.0 vuses: (SMT.4_8)
Created value VH.2 for (unsigned int *) VH.0
Created value VH.3 for (int *) VH.2
Created value VH.4 for VH.1 + VH.1
Created value VH.5 for retval_7
exp_gen[0] := { }
tmp_gen[0] := { a_1 (VH.0) }
avail_out[0] := { a_1 (VH.0) }
exp_gen[2] := { a_1 (VH.0) , *VH.0 (VH.1) , (unsigned int *) VH.0 (VH.2) , (int
*) VH.2 (VH.3) , VH.1 + VH.1 (VH.4) }
tmp_gen[2] := { t_2 (VH.1) , b_3 (VH.2) , c_4 (VH.3) , D.1527_5 (VH.1) ,
D.1526_6 (VH.4) , retval_7 (VH.5) }
avail_out[2] := { a_1 (VH.0) , t_2 (VH.1) , b_3 (VH.2) , c_4 (VH.3) , D.1526_6
(VH.4) , retval_7 (VH.5) }
exp_gen[1] := { }
tmp_gen[1] := { }
avail_out[1] := { }
Replaced *c_4 with t_2 in D.1527_5 = *c_4;
f (a)
{
int * c;
unsigned int * b;
int t;
int D.1527;
int D.1526;
bb 2:
t_2 = *a_1;
b_3 = (unsigned int *) a_1;
c_4 = (int *) b_3;
D.1527_5 = t_2;
D.1526_6 = D.1527_5 + t_2;
return D.1526_6;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #22 from bangerth at dealii dot org 2006-04-20 14:10 ---
(In reply to comment #17)
Yes, you pick up my operator in Wolfgang's test case. But in the original
submission the vector code is *before* my operators, which are consequently
out
of scope for the STL code
That is factually incorrect, as you can easily check in your code: the
declarations involving operator, and hide::inv are in global namespace.
Both Paolo and I have come up with small test codes, but they don't seem
to to be to your liking. If you insist on there being something wrong,
I can only urge you to show us a small piece of code that we can look over,
and explain to us why you think that the compiler is wrong. Just waving
hands, talking about ADL, claiming that something is wrong, and pointing to a
60,000 line chunk of code isn't going to get us somewhere. Where's the meat?
On a different note, as a teacher, I can't help to wonder who in his right
mind thought it would be a good idea to come up with code like this:
---
hide::inv operator,(hide::inv l, hide::inv r) { return hide::inv(); }
templatetypename T
hide::inv operator,(hide::inv l, T t) { return t, hide::inv(); }
templatetypename T
hide::inv operator,(T t, hide::inv r) { return hide::notAssembler(); }
---
I mean, it's a miracle your code actually does what you expect. From a
code design viewpoint, everyone seems to agree that overloading operator,
is already a Really Bad Idea (TM), but to do so in global namespace, using
templated arguments, and then not even returning the second argument must
be something that everyone recognizes as an accident in the making, no?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27224] Read twice and write on a variable in same expression
--- Comment #4 from moura at kdewebdev dot org 2006-04-20 14:49 --- One has still to use the -Wsequence-point, in C++? It would be good if there was no need to explicitly use such a switch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
--- Comment #3 from laszlo dot szakony at philips dot com 2006-04-20 14:52 --- Created an attachment (id=11303) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11303action=view) Simple test without automake files to test visibility changes of static members To create the binaries and run the test: tar -xzf simpletest.tar.gz cd simpletest ./build.sh Actually the shared libs libdlib1.so and libdlib2.so should not export any symbols, but as you can see, both of them have the global symbol SLibC1::m_str. But only in case of hash_map. With std::map works. -- laszlo dot szakony at philips dot com changed: What|Removed |Added Attachment #3|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
[Bug tree-optimization/14844] [tree-ssa] narrow types if wide result is not needed for unsigned types or when wrapping is true
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-20 14:57 --- We now generate return (int) ((unsigned int) (long long int) b + (unsigned int) (long long int) a); which is harder to optimize. But with -fwrapv and GVN tree-combiner we get aa_2 = (long long int) a_1; bb_4 = (long long int) b_3; D.1527_5 = a_1; D.1528_6 = b_3; D.1526_7 = D.1527_5 + D.1528_6; return D.1526_7; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14844
[Bug libgcj/21941] NPE in Socket.connect()
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 15:42 --- Subject: Bug 21941 Author: tromey Date: Thu Apr 20 15:42:12 2006 New Revision: 113117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113117 Log: PR libgcj/21941: * gnu/java/net/natPlainDatagramSocketImplPosix.cc (send): Throw UnknownHostException if needed. * gnu/java/net/natPlainSocketImplPosix.cc (connect): Throw UnknownHostException if needed. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc branches/gcc-4_1-branch/libjava/gnu/java/net/natPlainSocketImplPosix.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21941
[Bug c++/19963] ICE on invalid member declaration
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-20 15:46 --- Mine. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19963
[Bug libgcj/21941] NPE in Socket.connect()
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 15:46 --- Subject: Bug 21941 Author: tromey Date: Thu Apr 20 15:46:40 2006 New Revision: 113118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113118 Log: PR libgcj/21941: * gnu/java/net/natPlainDatagramSocketImplPosix.cc (send): Throw UnknownHostException if needed. * gnu/java/net/natPlainSocketImplPosix.cc (connect): Throw UnknownHostException if needed. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc trunk/libjava/gnu/java/net/natPlainSocketImplPosix.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21941
[Bug libgcj/21941] NPE in Socket.connect()
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-20 15:47 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21941
[Bug c++/19963] ICE on invalid member declaration
--- Comment #3 from patchapp at dberlin dot org 2006-04-20 15:50 --- Subject: Bug number PR c++/19963 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00761.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19963
[Bug c/27226] New: Compiler looses track of alignment for emit_block_move
The compiler used to use move_by_pieces for sh-elf at -O2 for the trivial
strcpy calls in dhrystone, but now it uses memcpy. I've found that this
is because it no longer knows that the two MEM arguments are aligned.
Here is a pruned-down testcase:
char *strcpy (char *, const char *);
extern void g ();
f ()
{
struct {
int i;
char str[31];
} s;
strcpy (s.str, text text text text text text text text);
g (s.str);
}
--
Summary: Compiler looses track of alignment for emit_block_move
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 15:54 --- You can see it by compiling this short example program with 'g++ --syntax-only': #include gcj/cni.h #include jni.h -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-20 15:54:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219
[Bug c/27226] Compiler looses track of alignment for emit_block_move
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-20 15:58 --- This worked in 3.5.0 20040512 (experimental), but failed in 3.5.0 20040630 (experimental) -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 Known to work||3.4.0 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug c++/26789] [4.1 regression] ICE on incomplete struct with -fmudflap
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-20 16:01 --- Subject: Bug 26789 Author: reichelt Date: Thu Apr 20 16:01:05 2006 New Revision: 113119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113119 Log: PR mudflap/26789 * tree-mudflap.c (mudflap_finish_file): Skip function when there were errors. * testsuite/libmudflap.c++/error1-frag.cxx: New test. Added: branches/gcc-4_1-branch/libmudflap/testsuite/libmudflap.c++/error1-frag.cxx Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-mudflap.c branches/gcc-4_1-branch/libmudflap/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26789
[Bug fortran/22547] Fortran 2003: ISO_FORTRAN_ENV intrinsic module missing
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-20 16:02 ---
(In reply to comment #1)
This should be fairly straight forward to implement. The
question is where do we put the module and 8.o file. Is
${prefix}/lib/modules a good enough place? There is also
the possibility of ${prefix}/libexec/modules.
I'm not sure whether putting it into an external module is the right way to do
as this is an intrinsic module; in any case this .mod file has to be regarded
as intrinsic (see below).
From Fortran 95/2003 explained:
Also like intrinsic procedures, it is possible for a program to use an
intrinsic module and a user-defined module of the same name, though they cannot
both be referenced from the same scoping unit. [...] for example
use, intrinsic :: iso_fortran_env
(and: use, non_intrinsic :: iso_fortran_env)
(For completeness: The other intrinsic modules of Fortran 2003 are: ieee_* and
iso_c_binding.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22547
[Bug c/27226] Compiler looses track of alignment for emit_block_move
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 16:05 --- You might want to dive into builtins.c:get_pointer_alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug libgcj/27201] can't include cni.h and jni.h in the same file
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 16:06 --- You can see it by compiling this short example program with 'g++ --syntax-only': #include gcj/cni.h #include jni.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27201
[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 16:06 --- Ignore that, I appended to the wrong report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #9 from law at gcc dot gnu dot org 2006-04-20 16:13 --- Subject: Bug 26854 Author: law Date: Thu Apr 20 16:13:12 2006 New Revision: 113120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113120 Log: PR tree-optimization/26854 * tree-ssa-dse.c (dse_optimize_stmt): Avoid num_imm_uses when checking for zero or one use. * tree-ssa-dom.c (propagate_rhs_into_lhs): Similarly. * tree-cfgcleanup.c (merge_phi_nodes): Similarly. * tree-ssa-reassoc.c (negate_value): Similarly. (reassociate_bb): Similarly. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfgcleanup.c trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-dse.c trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #10 from law at redhat dot com 2006-04-20 16:17 --- PRE/FRE for mainline need some TLC on their compile-time performance as indicated by this PR as well. They're #3 #4 respectively behind the operator scanning code and store-ccp and way out of line when compared with the rest of the tree optimization passes. -- law at redhat dot com changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-04-20 16:19 --- (In reply to comment #14) The reversal of the DECL_UID (x) = DECL_UID (t); assignment in name-lookup.c causes Yes because they are the same decl, if the C++ only uses one decl instead of creating a seperate one, it would just work. Zack's patch did not cause but did expose one issue. Again see PR 20357 for why this was not caused by any of the patches mentioned and why this is a latent bug from before any of the patches mentioned and the correct method is to create one decl with one decl UID and forget about a seperate decl with the copy. Fortran has the same issue and I was trying to fix some of those issue but that work got stalled by me joining Sony and also not having time to work on any of GCC in the last days of college. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-04-20 16:21 --- (In reply to comment #10) PRE/FRE for mainline need some TLC on their compile-time performance as indicated by this PR as well. They're #3 #4 respectively behind the operator scanning code and store-ccp and way out of line when compared with the rest of the tree optimization passes. I'll look into this in the next few weeks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-04-20 16:24 --- Actually I don't see why the comma operator can be overridden in C++ (yes this I am raising a question about why the standards says it can). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/26789] [4.1 regression] ICE on incomplete struct with -fmudflap
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-20 16:24 --- Now also fixed on the 4.1 branch. The more drastic fix used there (skipping the whole function on errors instead of just single erroneous objects) is now also on mainline, too. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26789
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #24 from law at redhat dot com 2006-04-20 16:24 --- Richard -- is there any chance you could pick up the ball on this PR? I really need to focus on some non-GCC stuff for a while, but don't want this issue to get lost in the process. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #25 from rguenther at suse dot de 2006-04-20 16:33 --- Subject: Re: VRP/DOM does not like TRUTH_AND_EXPR On Thu, 20 Apr 2006, law at redhat dot com wrote: Richard -- is there any chance you could pick up the ball on this PR? I really need to focus on some non-GCC stuff for a while, but don't want this issue to get lost in the process. Yes, it's on my list of things to look at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug ada/27225] Wide_String slice assignment in nested procedure does not work properly
--- Comment #2 from bauhaus at futureapps dot de 2006-04-20 16:57 --- Apperently, this is fixed in the 4.2 trunk, 113114. Same error with 4.02. (Not in 3.4.5 of GNAT GPL edition) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27225
[Bug classpath/27163] FTP directory listing doesn't work
--- Comment #3 from r_ovidius at eml dot cc 2006-04-20 17:20 --- Try with String url = ftp://gcc.gnu.org;; (notice the missing / at the end). This results in gnu.java.net.protocol.ftp.FTPException: Invalid number of arguments. at gnu.java.net.protocol.ftp.FTPConnection.changeWorkingDirectory (libgcj.so.7) at gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream (libgcj.so.7) at java.net.URL.openStream (libgcj.so.7) with gcj (GCC) 4.2.0 20060419 (experimental). Further, the while (file.ready()) never seems to return false in Sun's java, while it does with gcj, so I'd wager on the obscure bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27163
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-20 18:05 --- (In reply to comment #2) You might want to dive into builtins.c:get_pointer_alignment. Hmm, indeed, I see that in 3.5.0 20040512, expand_builtin_memcpy has found a dest_align of 32 and proceeded to go the store_by_pieces route. The tree passed to get_poiter_alignment for the destination was: nop_expr 0xb57cd794 type pointer_type 0xb58411b0 type integer_type 0xb58562f4 char QI size integer_cst 0xb5854104 constant 8 unit size integer_cst 0xb5854118 constant 1 align 8 symtab 0 alias set -1 precision 8 min integer_cst 0xb58541a 4 -128 max integer_cst 0xb58541b8 127 pointer_to_this pointer_type 0xb58411b0 unsigned SI size integer_cst 0xb58547a8 constant 32 unit size integer_cst 0xb58547d0 constant 4 align 32 symtab 0 alias set -1 arg 0 plus_expr 0xb583e150 type pointer_type 0xb57ce438 type array_type 0xb57ce0d8 unsigned SI size integer_cst 0xb58547a8 32 unit size integer_cst 0xb58547d0 4 align 32 symtab 0 alias set -1 arg 0 nop_expr 0xb57cd780 type pointer_type 0xb57ce438 arg 0 addr_expr 0xb57cd730 type pointer_type 0xb57ce4a4 arg 0 var_decl 0xb57ce288 s arg 1 integer_cst 0xb57cd76c constant 4 In mainline, the calculated dest_align is 8. The tree passed to get_pointer_alignment is: addr_expr 0xb58b13e0 type pointer_type 0xb58c6170 type integer_type 0xb58bd170 char sizes-gimplified public string-flag QI size integer_cst 0xb58ac1c8 constant invariant 8 unit size integer_cst 0xb58ac1e0 constant invariant 1 align 8 symtab 0 alias set -1 precision 8 min integer_cst 0xb58ac228 -128 max integer_cst 0xb58ac288 127 pointer_to_this pointer_type 0xb58c6170 unsigned SI size integer_cst 0xb58ac3c0 constant invariant 32 unit size integer_cst 0xb58ac150 constant invariant 4 align 32 symtab 0 alias set -1 invariant arg 0 array_ref 0xb593a820 type integer_type 0xb58bd170 char arg 0 component_ref 0xb58bb078 type array_type 0xb5938730 arg 0 var_decl 0xb58ba108 s arg 1 field_decl 0xb593878c str arg 1 integer_cst 0xb58ac168 constant invariant 0 arg 2 integer_cst 0xb58ac168 0 arg 3 integer_cst 0xb58ac1e0 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-04-20 18:10 --- Created an attachment (id=11304) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #24 from bangerth at dealii dot org 2006-04-20 18:16 --- (In reply to comment #23) Actually I don't see why the comma operator can be overridden in C++ (yes this I am raising a question about why the standards says it can). It was mid-March when Stroustrup developed operator overloading. The draft was finished March 31th, and the next day he didn't know what to do and thought of adding something to the language appropriate for the day. Just like this, a few years later: http://public.research.att.com/~bs/whitespace98.pdf W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #25 from igodard at pacbell dot net 2006-04-20 18:40 --- Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why operator,() was overloadable in the Rationale. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-20 18:58 --- (In reply to comment #4) Created an attachment (id=11304) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304action=view) [edit] proposed patch Needs some more work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #26 from igodard at pacbell dot net 2006-04-20 19:15 --- Sorry, fat fingered a submit before message was done, please ignore immediately previous message. Corrected full one follows later Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27227] New: [4.0/4.1/4.2 Regression] rejects valid code with some extern C
Testcase:
namespace x {
extern C const int y;
};
using x::y;
extern C int const y=0;
---
The testcase is orginally from Alex Rosenberg on the IRC channel, modified to
make it valid code so that the linkage specifications match.
This used to work before 4.0.0
--
Summary: [4.0/4.1/4.2 Regression] rejects valid code with some
extern C
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-04-20 20:38 --- Created an attachment (id=11305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305action=view) proposed patch for 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 20:47 --- I suggest you test on an architecture that traps on unaligned accesses, so as ia64 with the correct prctrl setup. In particular you seem to miss that ARRAY_REF can have a custom index range that doesn't start with zero. Otherwise the patch looks reasonable, though you may wait on the backport of the bits from mainline for the 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug libgcj/27228] New: java.security.InvalidAlgorithmParameterException
Originally from jsch (jcraft.com)
com/jcraft/jsch/jce/DH.java
getE()
This function works in Sun's java, but on libgcj it fails. Here is a
standalone sample that works in Sun's java:
(I believe this used to work with gnu.crypto)
gcj (GCC) 4.2.0 20060419 (experimental)
gcj --main=Sec -o Sec Sec.java
./Sec
java.security.InvalidAlgorithmParameterException: params
at gnu.javax.crypto.jce.sig.DHKeyPairGeneratorSpi.initialize (libgcj.so.7)
at java.security.KeyPairGenerator.initialize (libgcj.so.7)
at Sec.main (Sec)
=
public class Sec {
private static KeyPairGenerator myKpairGen;
private static KeyAgreement myKeyAgree;
private static BigInteger p;
private static BigInteger g;
private static BigInteger e; // my public key
private static byte[] e_array;
public static void main(String[] args) {
try {
myKpairGen = KeyPairGenerator.getInstance(DH);
myKeyAgree = KeyAgreement.getInstance(DH);
p = new
BigInteger(179769313486231590770839156793787453197860296048756011706236841971802161585193689478337958649255415021805654
859805036464405481992391000507928770033558166392295531362390765087357599148225748625750074253020774477125895509579377784244424266173347276
29299387668709205606050270810842907692932019128194467627007);
g = new BigInteger(2);
DHParameterSpec dhSkipParamSpec = new DHParameterSpec(p, g);
myKpairGen.initialize(dhSkipParamSpec);
KeyPair myKpair = myKpairGen.generateKeyPair();
myKeyAgree.init(myKpair.getPrivate());
// BigInteger
x=((javax.crypto.interfaces.DHPrivateKey)(myKpair.getPrivate())).getX();
byte[] myPubKeyEnc = myKpair.getPublic().getEncoded();
System.err.println(myPubKeyEnc);
e = ((javax.crypto.interfaces.DHPublicKey) (myKpair.getPublic())).getY();
e_array = e.toByteArray();
} catch (Exception e) {
e.printStackTrace();
}
}
}
--
Summary: java.security.InvalidAlgorithmParameterException
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r_ovidius at eml dot cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-20 20:53 ---
I have tested this test case again with lcm.c patched with the patch below to
check for insertions on edges where an expression is already available. The
abort does not trigger.
The version of GCC that I patched and tested was extracted from SVN with the
following commands: svn co -r {2004-08-10 15:10} (etc.)
Index: lcm.c
===
--- lcm.c (revision 85749)
+++ lcm.c (working copy)
@@ -426,10 +426,6 @@ pre_edge_lcm (FILE *file ATTRIBUTE_UNUSE
dump_sbitmap_vector (file, earliest, , earliest, num_edges);
#endif
- sbitmap_vector_free (antout);
- sbitmap_vector_free (antin);
- sbitmap_vector_free (avout);
-
later = sbitmap_vector_alloc (num_edges, n_exprs);
/* Allocate an extra element for the exit block in the laterin vector. */
@@ -462,6 +458,32 @@ pre_edge_lcm (FILE *file ATTRIBUTE_UNUSE
}
#endif
+#if 1
+ {
+sbitmap *avout_check;
+sbitmap *insert_ = *insert;
+int x;
+
+avout_check = sbitmap_vector_alloc (num_edges, n_exprs);
+sbitmap_vector_zero (avout_check, num_edges);
+
+for (x = 0; x num_edges; x++)
+ {
+ basic_block bb = INDEX_EDGE_PRED_BB (edge_list, x);
+ if (bb-index 0)
+ continue;
+ sbitmap_copy (avout_check[x], avout[bb-index]);
+ sbitmap_a_and_b (avout_check[x], avout_check[x], insert_[x]);
+ if (sbitmap_first_set_bit (avout_check[x]) = 0)
+ abort ();
+ }
+ }
+#endif
+
+ sbitmap_vector_free (antout);
+ sbitmap_vector_free (antin);
+ sbitmap_vector_free (avout);
+
return edge_list;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-04-20 21:09 --- (In reply to comment #7) I suggest you test on an architecture that traps on unaligned accesses, so as ia64 with the correct prctrl setup. I don't have access to an ia64 host, but sh-elf is a STRICT_ALIGNMENT target, too. In particular you seem to miss that ARRAY_REF can have a custom index range that doesn't start with zero. get_inner_reference should take care of that. Otherwise the patch looks reasonable, though you may wait on the backport of the bits from mainline for the 4.1 branch. When I backported the mainline patch to our 4.1 based sources I've found that it did ICE on dhrystone. The 4.1 patch is completely re-written. I'll have to forward-port that when I find some time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-20 21:13 --- Created an attachment (id=11306) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11306action=view) CFG at the start of gcse -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-20 21:14 --- Created an attachment (id=11307) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11307action=view) LCM dataflow solution for the first gcse pass -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #10 from steven at gcc dot gnu dot org 2006-04-20 21:15 --- Created an attachment (id=11308) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11308action=view) LCM dataflow solution for the second gcse pass -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-20 21:16 --- One of these days someone should manually compute the LCM sets from attachments 1, 2, and 3 ... -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-11 00:37:04 |2006-04-20 21:16:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-20 21:23 --- Ah, I see. I only looked at the mainline patch. I was refering to the patch for PR26565 which is still pending for 4.1 and will bring the 4.1 version in-line with the mainline version. I guess sh is also affected for PR26565. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-20 21:23:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug fortran/27229] New: char_transpose_1.f90 fails with ICE in gfc_conv_array_transpose
Test gfortran.dg/char_transpose_1.f90 fails on mainline for powerpc-unknown-linux-gnu with optimization: /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/testsuite/gfortran.dg/char_transpose_1.f90:9: internal compiler error: in gfc_conv_array_transpose, at fortran/trans-array.c:726^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See URL:http://gcc.gnu.org/bugs.html for instructions.^M A regression hunt identified this patch: r112955 | kazu | 2006-04-14 14:31:32 + (Fri, 14 Apr 2006) | 8 lines * local-alloc.c (rest_of_handle_local_alloc): Use VEC instead of VARRAY. * reload1.c (reg_equiv_memory_loc_varray): Rename to reg_equiv_memory_loc_vec. Change the type to VEC(rtx,gc) *. (init_reload, reload): Use VEC instead of VARRAY. * reload.h: Update the prototype for reg_equiv_memory_loc_varray. http://gcc.gnu.org/viewcvs?view=revrev=112955 That seemed unlikely so I tried reverting that patch from today's mainline, and it did indeed allow the test to pass. The same ICE is reported in PR26119, filed 2006-02-06. -- Summary: char_transpose_1.f90 fails with ICE in gfc_conv_array_transpose Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27229
[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc
--- Comment #3 from mckinlay at redhat dot com 2006-04-20 21:45 --- It does look like these should be made robust in the case of an EINTR which was caused by a signal other than the interrupt signal. As for ignoring ENOTCONN and ECONNRESET, I have a vague recollection that there is a good reason for doing this (compatibility with Sun?) - but this probably does warrant more testing/investigation, and a better comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219
[Bug target/27230] New: many obj-c++.dg tests ICE in rs6000_output_function_epilogue
On powerpc64-unknown-linux-gnu with -m64, 85 tests in obj-c++.dg fail with: elm3b11% /opt/gcc-nightly/trunk-20060420/bin/g++ -c -m64 basic.mm basic.mm: In function void __objc_gnu_init(): basic.mm:21: internal compiler error: in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:15346 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This has apparently never worked on the FSF tree for this target. -- Summary: many obj-c++.dg tests ICE in rs6000_output_function_epilogue Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27230
[Bug target/24955] ICE: rs6000_output_function_epilogue, at config/rs6000/rs6000.c:15204
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-20 21:48 --- *** Bug 27230 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24955
[Bug target/27230] many obj-c++.dg tests ICE in rs6000_output_function_epilogue
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-20 21:48 --- *** This bug has been marked as a duplicate of 24955 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27230
[Bug target/27230] many obj-c++.dg tests ICE in rs6000_output_function_epilogue
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-20 21:50 --- Let me reopen this for a second but really this is a dup of bug 24955 but maybe there is a language type defined for objc++ and it is not yet implemented in GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27230
[Bug libgcj/27228] java.security.InvalidAlgorithmParameterException
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 22:16 --- I see this with 4.2. 4.1 seems to work. With jamvm and classpath cvs I see something else: opsy. ~/workspace/classpath/install/bin/jamvm Sec java.security.NoSuchAlgorithmException: DH at java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:115) at Sec.main(Sec.java:17) ... which is curious since DH is definitely defined as a key pair generator in GnuCrypto.java. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-20 22:16:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug libgcj/27228] java.security.InvalidAlgorithmParameterException
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 22:16 --- Created an attachment (id=11310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11310action=view) updated test case This is a version of the test case that compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug libgcj/27231] New: java.lang.StringIndexOutOfBoundsException in HTTPURLConnection.connect
Works in Sun's java. Doesn't work with gcj, with or without the trailing /
on the url.
gcj (GCC) 4.2.0 20060419 (experimental)
gcj -o Htest --main=Htest Htest.java
./Htest
Exception in thread main java.lang.StringIndexOutOfBoundsException
at java.lang.String.substring (libgcj.so.7)
at gnu.java.net.protocol.http.HTTPURLConnection.connect (libgcj.so.7)
at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream (libgcj.so.7)
at java.net.URL.openStream (libgcj.so.7)
at Htest.main (Htest)
---
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.math.BigInteger;
import java.net.MalformedURLException;
import java.net.URL;
public class Htest {
public static void main(String[] a) {
String urlString = http://microsoft.com/;; // w or w/o trailing /
URL url = null;
try {
url = new URL(urlString);
} catch (MalformedURLException e) {
e.printStackTrace();
}
try {
BufferedReader b = new BufferedReader(new
InputStreamReader(url.openStream()));
StringBuffer sb = new StringBuffer();
String string;
while ((string = b.readLine()) != null)
sb.append(string);
b.close();
System.err.println(sb.toString());
} catch (IOException e) {
e.printStackTrace();
}
}
}
--
Summary: java.lang.StringIndexOutOfBoundsException in
HTTPURLConnection.connect
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r_ovidius at eml dot cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27231
[Bug libgcj/27228] java.security.InvalidAlgorithmParameterException
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-20 23:08 --- Ok... I fixed a problem with my jamvm setup and now I am seeing this with classpath cvs as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #27 from pcarlini at suse dot de 2006-04-20 23:10 --- (In reply to comment #23) Actually I don't see why the comma operator can be overridden in C++ (yes this I am raising a question about why the standards says it can). Well, if we are talking about rationale and programming style, then authors like Lippman/Lajoie/Moo in general advice against overloading operator, (14.1.1). But really, now the point seems to me rather clear: it is essentially impossible to protect the library vs all the possible operator overloadings in global namespace (consider also things like operator|| and operator) together with unrestricted templates (thus enabled not only for user defined types): if the user does that then has to accept the behavior he gets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
--- Comment #7 from danglin at gcc dot gnu dot org 2006-04-20 23:12 --- Ditto on hppa-unknown-linux-gnu. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug crypto/27228] java.security.InvalidAlgorithmParameterException
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-20 23:14 --- Moving to Classpath. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Component|libgcj |crypto Product|gcc |classpath Version|4.2.0 |0.90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Comment #9 from patchapp at dberlin dot org 2006-04-20 23:20 --- Subject: Bug number PR20257 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00785.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #3 from janis at gcc dot gnu dot org 2006-04-20 23:31 --- This test and obj-c++.dg/try-catch-9.mm get the same ICE on powerpc-linux on trunk as of 2006-04-20, and have failed since I started including obj-c++ on 2005-11-02. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #4 from danglin at gcc dot gnu dot org 2006-04-20 23:37 ---
4649 else if (any_condjump_p (head))
4650gcc_assert (EDGE_COUNT (bb-succs) 1
4651 !BARRIER_P (NEXT_INSN (head)));
(gdb) p debug_rtx (head)
(jump_insn 20 18 30 2 (parallel [
(set (pc)
(if_then_else (eq (reg:SI 28 %r28)
(const_int 0 [0x0]))
(label_ref 30)
(pc)))
(set (reg/v:SI 3 %r3 [orig:94 call_result ] [94])
(reg:SI 28 %r28))
]) 231 {*pa.md:9084} (nil)
(expr_list:REG_DEAD (reg:SI 28 %r28)
(expr_list:REG_BR_PROB (const_int 1 [0x2710])
(nil
(gdb) p debug_rtx_list (head, 5)
(jump_insn 20 18 30 2 (parallel [
(set (pc)
(if_then_else (eq (reg:SI 28 %r28)
(const_int 0 [0x0]))
(label_ref 30)
(pc)))
(set (reg/v:SI 3 %r3 [orig:94 call_result ] [94])
(reg:SI 28 %r28))
]) 231 {*pa.md:9084} (nil)
(expr_list:REG_DEAD (reg:SI 28 %r28)
(expr_list:REG_BR_PROB (const_int 1 [0x2710])
(nil
(code_label 30 20 31 3 2 (error_free_node) [1 uses])
(note 31 30 33 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 33 31 34 3 (set (reg:SI 26 %r26 [ node ])
(reg/v/f:SI 3 %r3 [orig:95 node ] [95])) 37 {*pa.md:2482} (nil)
(nil))
(call_insn 34 33 40 3 (parallel [
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI (@T) [flags 0x41]
function_decl 0x40090b80 T) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) 210 {call_val_symref} (nil)
(expr_list:REG_DEAD (reg:SI 26 %r26 [ node ])
(expr_list:REG_UNUSED (reg:SI 2 %r2)
(expr_list:REG_UNUSED (reg:SI 1 %r1)
(expr_list:REG_UNUSED (reg:SI 28 %r28)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26 [ node ]))
(nil)))
(gdb) p *bb-succs
$16 = {base = {num = 1, alloc = 4, vec = {0x4009cb28}}}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug target/27179] libgomp bootstrap failure: unhandled reloc type 67
--- Comment #3 from gerald at pfeifer dot com 2006-04-20 23:46 --- (In reply to comment #2) Does Sparc-FreeBSD have working TLS support? According to FreeBSD developers I asked, it does not, yet (probably due to missing binutils support). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27179
[Bug target/27179] libgomp bootstrap failure: unhandled reloc type 67
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-20 23:47 --- (In reply to comment #3) (In reply to comment #2) Does Sparc-FreeBSD have working TLS support? According to FreeBSD developers I asked, it does not, yet (probably due to missing binutils support). That means this is a dup of bug 25865. Yes that was filed about netbsd but it also effects other targets. *** This bug has been marked as a duplicate of 25865 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27179
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-20 23:47 --- *** Bug 27179 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #7 from bryce at gcc dot gnu dot org 2006-04-20 23:48 --- Subject: Bug 27170 Author: bryce Date: Thu Apr 20 23:47:56 2006 New Revision: 113123 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113123 Log: PR libgcj/27170 * gnu/gcj/runtime/natSharedLibLoader.cc: Include gc.h to override dlopen(). From Anthony Green. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/gcj/runtime/natSharedLibLoader.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-20 23:48 --- This also effects sparc64-portbld-freebsd6.1 as described in PR 27179. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|*-*-netbsd |*-*-netbsd, sparc64-portbld- ||freebsd6.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
