[Bug other/19287] a protoize bug (directory string is duplicated.)
--- Comment #3 from jbuck at gcc dot gnu dot org 2007-01-12 07:59 --- Confirmed, I can get the failure in 4.1.1. It seems protoize only works right on files in the current directory. That said, it doesn't appear that anyone's done any work on protoize in years. It no longer installs by default, in 4.1.1 you need to do "make proto" in the gcc directory to build it. Confusingly, if you say "make protoize" the SYSCALLS file isn't built, and you get the message about the missing SYSCALLS.c.X. Reconfirming, but setting to lowest priority. -- jbuck at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 Priority|P2 |P5 Last reconfirmed|-00-00 00:00:00 |2007-01-12 07:59:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19287
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-12 08:12 --- Created an attachment (id=12894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12894&action=view) The patch promised above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug c++/23643] Incorrect conversion from derived to empty base class
--- Comment #3 from jbuck at gcc dot gnu dot org 2007-01-12 08:18 --- Andrew is right, this isn't a bug, and is in fact required by the ABI. See http://www.codesourcery.com/cxx-abi/abi.html#class-types, section II, subsection 3. "First, attempt to place D at offset 0." No rule prevents doing this, so that is where it lands. -- jbuck at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23643
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #14 from paolo at gcc dot gnu dot org 2007-01-12 11:09 --- Subject: Bug 30416 Author: paolo Date: Fri Jan 12 11:09:26 2007 New Revision: 120720 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120720 Log: 2007-01-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30416 * include/std/valarray (valarray<>::shift, valarray<>::cshift): Do not segfault when |n| > size. * testsuite/26_numerics/valarray/30416.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/valarray/30416.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/valarray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #15 from gdr at integrable-solutions dot net 2007-01-12 13:06 --- Subject: Re: SIGSEGV in valarray::cshift(n) on empty array "paolo at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Subject: Bug 30416 | | Author: paolo | Date: Fri Jan 12 11:09:26 2007 | New Revision: 120720 | | URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120720 | Log: | 2007-01-12 Paolo Carlini <[EMAIL PROTECTED]> Paolo -- Your patch had issues I just commented on. I expected you'd have waited for me to review it. :-( I was travelling back to CS all day yesterday. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #6 from jasonmbechtel at gmail dot com 2007-01-12 13:34 --- Not easily. I'm already using the current version on Edgy Eft. I'm not willing to upgrade to the active development version (Feisty Fawn) on my production system. So, I think the way to get a newer 4.1.2 would be to compile and install it in parallel with the current one... or to use another system for this testing. Is there a simple way to install another version of gcc in parallel with my current one under Debian/Ubuntu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #16 from paolo at gcc dot gnu dot org 2007-01-12 13:35 --- Subject: Bug 30416 Author: paolo Date: Fri Jan 12 13:34:47 2007 New Revision: 120722 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120722 Log: 2007-01-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30416 (continued) * include/std/valarray (valarray<>::shift, valarray<>::cshift): Allways return the same variable, thus facilitating NRVO. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/valarray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #17 from paolo at gcc dot gnu dot org 2007-01-12 14:56 --- Subject: Bug 30416 Author: paolo Date: Fri Jan 12 14:56:29 2007 New Revision: 120725 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120725 Log: 2007-01-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30416 (continued) * include/std/std_valarray.h (valarray<>::shift, valarray<>::cshift): Allways return the same variable, thus facilitating NRVO. 2007-01-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30416 * include/std/std_valarray.h (valarray<>::shift, valarray<>::cshift): Do not segfault when |n| > size. * testsuite/26_numerics/valarray/30416.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/26_numerics/valarray/30416.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/std/std_valarray.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #18 from pcarlini at suse dot de 2007-01-12 14:57 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #25 from ghazi at gcc dot gnu dot org 2007-01-12 15:36 --- Subject: Bug 30399 Author: ghazi Date: Fri Jan 12 15:36:16 2007 New Revision: 120727 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120727 Log: PR fortran/30399 * actual_array_constructor_2.f90 actual_array_substr_2.f90: Revert accidental checkin of these testcases. Removed: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/actual_array_substr_2.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug fortran/30399] testsuite failures in actual_array_constructor_2.f90 and actual_array_substr_2.f90
--- Comment #26 from ghazi at gcc dot gnu dot org 2007-01-12 15:54 --- Testcases deleted, problem solved. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.0.4 | Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
[Bug middle-end/30447] New: Evaluate complex math functions at compile-time
We should evaluate complex math functions (csin, catan, etc) at compile-time if they have constant arguments. There is a package called MPC (available at http://www.lix.polytechnique.fr/Labo/Andreas.Enge/Mpc.html or http://www.loria.fr/~zimmerma/software/mpc.html) that works with MPFR and may be suitable. At the moment in version 0.4.5, it doesn't have all of the complex transcendental functions implemented. In fact it has only sqrt and exp so far. But it may be extended or serve as a base for further improvements, and one day usable by GCC. -- Summary: Evaluate complex math functions at compile-time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: ghazi at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug middle-end/30447] Evaluate complex math functions at compile-time
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-12 16:38:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug java/30448] New: libjava configure script mix up with .c / .java using gcj /gcc
When running "make bootstrap" make gets to the target configure-target-libjava
and seems to be creating conftest.java files with "c" code in them. These are
compiled with gcj. This causes some of the tests in configure to pass when "c"
code is compiled with gcc) and some of the tests in configure to fail when "c"
code is compiled with gcj).
Here is part of configure's output:
First getting
checking command to parse /cygdrive/c/gcc-4_2-branch-build/./gcc/nm output...
ok
Later getting:
checking command to parse /cygdrive/c/gcc-4_2-branch-build/./gcc/nm output...
failed
I am not an expert on java, I am just trying to compile _all_ of gcc-4_2. I do
not know that these tests failing will hurt the java compile (in fact it seems
to compile "reasonably well" according to the result of running "make check").
I do not see the purpose of sending "c" code (with a .java extension) to the
gcj compiler to test if it works and is able to use "nm". Perhaps the
conftest.java files should be re-named with the .c extension, or perhaps the
conftest files should have java in them - maybe these tests should be skipped -
I don't know enough about java to have an opinion, just filing a bug report.
The problem _seems_ to be that configure is using ltconfig to call
gcc-4_2-branch-build/gcc/gcj to compile files with the extension .java but
containing "c" code. Gcj is failing when it tries to process the "#ifdef"
statements. The result is that configure thinks it's tests are failing (whereas
if it had called gcc instead of gcj they would pass).
Line 6589 of /gcc-4_2-branch/libjava/configure contains this:
AR="$AR" LTCC="$CC" CC="$GCJ" CFLAGS="$GCJFLAGS" CPPFLAGS="$CPPFLAGS" \
Shortly after it tries to run this command:
${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig -o libtool $libtool_flags \
--build="$build" --add-tag=GCJ $ac_aux_dir/ltcf-gcj.sh $host \
...
I may not understand what is trying to be done here but it seems that configure
is trying to get libtool to check if it can use the gcj tool chain (java) in
place of the gcc tool chain ("c") to compile "c" programs with the extension of
.java . The partial output of running "make configure-target-libjava" (part of
having typed "make bootstrap) is as follows:
loading cache ./config.cache within ltconfig
checking host system type... i686-pc-cygwin
checking build system type... i686-pc-cygwin
checking for objdir... .libs
checking for /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc option to produce
PIC... -DDLL_EXPORT -DPIC
checking if /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc PIC flag -DDLL_EXPORT
-DPIC works... yes
checking if /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc static flag -static
works... yes
finding the maximum length of command line arguments... (cached) 8192
checking if /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc supports -c -o
file.o... (cached) yes
checking if /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc supports -fno-rtti
-fno-exceptions ... yes
checking whether the linker (/cygdrive/c/gcc-4_2-branch-build/./gcc/collect-ld)
supports shared libraries... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking command to parse /cygdrive/c/gcc-4_2-branch-build/./gcc/nm output...
ok
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
appending configuration tag "CXX" to libtool
checking for gcj... /cygdrive/c/gcc-4_2-branch-build/gcc/gcj
-B/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/
-B/cygdrive/c/gcc-4_2-branch-build/gcc/
checking dependency style of /cygdrive/c/gcc-4_2-branch-build/gcc/gcj
-B/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/
-B/cygdrive/c/gcc-4_2-branch-build/gcc/... gcc3
loading cache ./config.cache within ltconfig
checking host system type... i686-pc-cygwin
checking build system type... i686-pc-cygwin
checking for objdir... .libs
checking for /cygdrive/c/gcc-4_2-branch-build/gcc/gcj option to produce PIC...
-DDLL_EXPORT
checking if /cygdrive/c/gcc-4_2-branch-build/gcc/gcj PIC flag -DDLL_EXPORT
works... (cached) yes
checking if /cygdrive/c/gcc-4_2-branch-build/gcc/gcj static flag -static
works... (cached) yes
finding the maximum length of command line arguments... (cached) 8192
checking if /cygdrive/c/gcc-4_2-branch-build/gcc/gcj supports -c -o file.o...
(cached) yes
checking if /cygdrive/c/gcc-4_2-branch-build/gcc/gcj supports -fno-rtti
-fno-exceptions ... no
checking whether the linker (/cygdrive/c/gcc-4_2-branch-build/./gcc/collect-ld)
supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking command to parse /cygdrive/c/gcc-4_2-branch-build/./gcc/nm output...
failed
checking if libtool supports shared libraries... yes
checking if pac
[Bug libstdc++/30449] New: Missing overloads (specializations) in stl_algobase.h
Apparently, we are missing useful overloads (specializations, depending on the implementation details): for example, for std::lexicographical_compare on pointers to non-const char types; std::equal seems not optimized to exploit memcmp when possible. Probably, normal_iterators to containers of chars and co, could be also dealt with (similarly to std::copy). -- Summary: Missing overloads (specializations) in stl_algobase.h Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30449
[Bug fortran/30450] New: calling subroutine with constant parameter
I checked google and gcc bugzila and couldn't find if this is standard or not but the following program should work (fortran used to pass all arguments as reference!!??): call sub(1) end subroutine sub(i) integer i i=i+1 return end Of course this program is very dumb but the functionality it requires has many uses in real life programs. Right now the program segfaults! -- Summary: calling subroutine with constant parameter Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug fortran/30450] calling subroutine with constant parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-12 17:58 --- The only use is to change the value of "1" :). Gfortran is correct as this behavior is undefined as you are trying to change the value of the constant 1. in Fortran all agruments are passed as reference. This has been what Fortran has done for years. Oh and this is not an issue that was introduced by the change over to gfortran from g77. g77 also segfaulted on your undefined code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug middle-end/30443] [4.3 Regression] 4.3 internal compiler error: verify_cgraph_node failed
--- Comment #4 from hubicka at gcc dot gnu dot org 2007-01-12 18:08 --- Subject: Bug 30443 Author: hubicka Date: Fri Jan 12 18:07:57 2007 New Revision: 120730 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120730 Log: PR tree-optimization/30443 * tree-inline.c (tree_function_versioning): Do not optimize when cloning for inlining. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30443
[Bug fortran/30450] calling subroutine with constant parameter
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-12 18:10 ---
The Fortran standard has never mandated pass-by-reference in
either subroutine or function call. A Fortran compiler can
use either pass-by-reference or pass-by-value. In fact, the
Standard does not require a Fortran processor to diagnose
that the programmer may be doing some stupid.
To understand why this is a stupid thing to do, here's the output
from -fdump-tree-original:
laptop:kargl[228] more b.f.003t.original
MAIN__ ()
{
_gfortran_set_std (70, 127, 0);
{
static int4 C.989 = 1;
sub (&C.989);
}
sub (i)
{
*i = *i + 1;
goto __return_sub;
__return_sub:;
The "static int C.989 = 1" is then transformed into this assembly:
.file "b.f"
.section.rodata
.align 4
.LC0:
.long 1
.text
.globl MAIN__
.type MAIN__, @function
MAIN__:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
subl$4, %esp
pushl $0
pushl $127
pushl $70
call_gfortran_set_std
addl$16, %esp
subl$12, %esp
pushl $.LC0
callsub_
Notice you're trying to modify read-only data.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug fortran/30450] calling subroutine with constant parameter
--- Comment #3 from milan at cmm dot ki dot si 2007-01-12 18:23 --- Subject: Re: calling subroutine with constant parameter > "pinskia" == pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> writes: pinskia> --- Comment #1 from pinskia at gcc dot gnu dot org pinskia> 2007-01-12 17:58 --- The only use is to change the pinskia> value of "1" :). pinskia> Gfortran is correct as this behavior is undefined as you pinskia> are trying to change the value of the constant 1. in pinskia> Fortran all agruments are passed as reference. This has pinskia> been what Fortran has done for years. Yes but in my case the compiler should create a temporary variable and use that in a real call to subroutine. Passing 1 to the the subroutine is just telling the compiler I am not interested in the final value of this parameter in the calling routine. But in some other places in the code this valus is important. I think this is what the compilers did in the old VAX times and I guess some other compilers do it also now. Since gfortran/gcc is so good (within 10% of ifort, sometimes faster sometimes slower) I lost interest in any other compiler, so I don't have anything handy to compile this program with say ifort. pinskia> Oh and this is not an issue that was introduced by the pinskia> change over to gfortran from g77. g77 also segfaulted on pinskia> your undefined code. I couldn't remember this for sure, but I know this problem for long time already. Only I just fixed a bug in a very old program and couldn't beleive it is still there. I think gfortran is more picky when something goes wrong in the program and reports an error, while others just go on with some stupid values :-( I am still not convinced this is not standard complying. Milan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-12 19:02 --- We can implement the complex variants in term of the real ones in mpfr, no? I don't like the idea of another build-dependency ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-01-12 19:10 --- You should file the bug in the Ubuntu bugtracking system, the Ubuntu maintainers might have a way to check their newer compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-12 19:12 --- (In reply to comment #1) > We can implement the complex variants in term of the real ones in mpfr, no? I > don't like the idea of another build-dependency ;) > Yes, you can. gfortran does this already for several Fortran intrinsic functions. See fortran/simplify.c. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug preprocessor/28227] valid #ifdef rejected
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-12 19:47 --- Subject: Bug 28227 Author: tromey Date: Fri Jan 12 19:46:49 2007 New Revision: 120731 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120731 Log: libcpp PR preprocessor/28227: * directives.c (lex_macro_node): Added 'is_def_or_undef' argument. (do_define): Update. (do_undef): Update. (do_ifdef): Update. (do_ifndef): Update. gcc/testsuite PR preprocessor/28227: * gcc.dg/cpp/pr28227.c: New file. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr28227.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28227
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #4 from dalej at apple dot com 2007-01-12 20:13 --- With pic, the load of the global's address is pulled outside the loop, so the "base" is a register rather than the global. This causes ivopts to represent index*step all in the index field rather than as two separate fields, so the dump looks like MEM[base: &arr_base, index: (int *) iter * 4B] = D.1877; instead of MEM[symbol: arr_base, index: (int *) iter, step: 4B] = D.1877; so the test fails, but the generated code is correct and optimal. I suggest adding -fno-pic to the test, does that look OK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug target/30451] New: incorrect attributes in *movti_ppc64 of rs6000.md
I found the following problem in rs6000.md:
(define_insn "*movti_ppc64"
[(set (match_operand:TI 0 "nonimmediate_operand" "=r,o<>,r")
(match_operand:TI 1 "input_operand" "r,r,m"))]
"TARGET_POWERPC64 && (gpc_reg_operand (operands[0], TImode)
|| gpc_reg_operand (operands[1], TImode))"
"#"
[(set_attr "type" "*,load,store")])
It appears that the order of the load and store attributes in the set_attr
expression is incorrect. If operand 0 is memory (o<>) and operand 1 is a
register (r), the instruction should be a store, not a load. Similarly, if
operand 0 is a register ("r") and operand 1 memory ("m"), the instruction
should be load, not a store.
I think either the constraint order or the attribute order need to be reversed
to make constraints and attributes match.
--
Summary: incorrect attributes in *movti_ppc64 of rs6000.md
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dkwan at transmeta dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: ppu-unknown-lv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #1 from pault at gcc dot gnu dot org 2007-01-12 20:59 ---
Steve,
I am a bit surprised by what you say:
On an ia64/FC5, the pair of programs work fine. The code around the call to
f_to_f is:
.
real4 a;
.
a = 4.2e+1;
b = 0.0;
c = a;
c.1 = &c;
f_to_f (&b, a, &c, &c.1);
D.1355 = a * 2.0e+0;
b.2 = b;
if (D.1355 != b.2)
{
_gfortran_abort ();
}
so that a appears to be passed as a float, aka real4
and for the function itself:
f_to_f__ (retval, a1, a2, a3)
{
float D.1993;
float * D.1994;
float D.1995;
float D.1996;
float D.1997;
D.1993 = *a2;
if (D.1993 != a1)
{
abort ();
}
else
{
}
D.1994 = *a3;
D.1995 = *D.1994;
if (D.1995 != a1)
{
abort ();
}
else
{
}
a1 = 0.0;
D.1996 = *a2;
D.1997 = D.1996 * 2.0e+0;
*retval = D.1997;
return;
}
and, similarly, f_to_f treats it as a float.
Unflummox me!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug target/30451] incorrect attributes in *movti_ppc64 of rs6000.md
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-12 21:28 --- LV2 target support does not exist in the FSF GCC (yet). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|ppu-unknown-lv2 |powerpc64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #3 from janis at gcc dot gnu dot org 2007-01-12 21:41 --- RMS declined to relicense the decNumber source files. We've got the same problem with config/dfp-bit.[ch], which were new files added by GCC developers from IBM, and a couple of other minor files in libdecnumber/. Decimal float support has not yet been in a released version of GCC. In 4.2 and mainline it is not enabled, and support is not included in libgcc, unless configured with --enable-decimal-float. Perhaps that option should be changed to --enable-decimal-float-including-GPL-runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #2 from sje at cup dot hp dot com 2007-01-12 21:52 ---
I am not sure if I can unflummox you or not. It still fails for me on IA64
HP-UX and on IA64 Debian 3.1 Linux. It also shows up in the testresults mail
from H.J and Andreas on their IA64 Linux testing. Here are two short programs
to reproduce the error. The interesting thing is that a1 is correctly printed
out if I remove the initial integer argument. With the integer argument I get
the value zero printed. Looking at the assembly code again, it still looks
like the float argument is being passed in an integer register by the Fortran
main program and read from a floating point register by the C code. With out
the integer argument the float argument is written to and read from a floating
point register, which is what I would expect.
C code:
void f_to_f__(int i, float a1)
{
printf("a1 = %f\n", (double) a1);
return;
}
program c_by_val_1
external f_to_f
real a
integeri
a = 42.0
call f_to_f (i, %VAL (a))
stop
end
Fortran code:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #3 from sje at cup dot hp dot com 2007-01-12 21:54 ---
My example code got a little messed up in the last comment, here it is again:
C code:
void f_to_f__(int i, float a1)
{
printf("a1 = %f\n", (double) a1);
return;
}
Fortran code:
program c_by_val_1
external f_to_f
real a
integeri
a = 42.0
call f_to_f (i, %VAL (a))
stop
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug libfortran/30014] INQUIRE (iolength = xx) limited to kind=4
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-12 21:57 --- This is an enhancement, so only for trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30014
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #4 from sje at cup dot hp dot com 2007-01-12 22:37 --- Here is a little more information: In the broken case (my small test case with the initial integer argument), when I call ia64_function_arg (via the FUNCTION_ARG macro) the named argument has a value of zero. This results in the floating point argument being put in an integer register. In the working case (no initial integer argument), named is one and the floating point argument gets put in a floating point register. I am not sure what triggers the different value for the named parameter though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug fortran/30452] New: Strange syntax error with high-value character
This shouldn't be rejected. g77 accepts this. $ cat char.f program main if (char (254) /= "รพ") call abort end program main $ gfortran char.f char.f:2.24: if (char (254) /= "\xFE") call abort 1 Error: Unterminated character constant beginning at (1) $ g77 char.f $ -- Summary: Strange syntax error with high-value character Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug c++/27492] [4.0/4.1/4.2/4.3 regression] ICE on invalid covariant return type
--- Comment #3 from simartin at gcc dot gnu dot org 2007-01-12 22:57 --- I am testing a patch for this one. -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |simartin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-21 21:32:56 |2007-01-12 22:57:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27492
[Bug fortran/30435] Slash at end of input not recognized according to standard
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-01-12 23:10 --- Subject: Bug 30435 Author: jvdelisle Date: Fri Jan 12 23:10:27 2007 New Revision: 120737 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120737 Log: 2007-01-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/30435 * io/list_read.c (finish_separator): Don't call next_record. (list_formatted_read_scalar): Clean up some comments and whitespace. (nml_read_obj): Whitespace fix. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug fortran/30435] Slash at end of input not recognized according to standard
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-01-12 23:36 --- Subject: Bug 30435 Author: jvdelisle Date: Fri Jan 12 23:36:25 2007 New Revision: 120738 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120738 Log: 2007-01-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/30435 * gfortran.dg/list_read_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/list_read_6.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30435
[Bug ada/30453] New: Segmentation fault: Error detected at ali.adb:2240:1
/home/dave/gnu/gcc-4.3/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -gna tpg -gnata -I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/ali.adb -o ada/al i.o +===GNAT BUG DETECTED==+ | 4.3.0 20070112 (experimental) (hppa-unknown-linux-gnu) Segmentation fault| | Error detected at ali.adb:2240:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. ../../gcc/gcc/ada/ali.adb ../../gcc/gcc/ada/ali.ads ../../gcc/gcc/ada/casing.ads ../../gcc/gcc/ada/types.ads ../../gcc/gcc/ada/gnatvsn.ads ../../gcc/gcc/ada/rident.ads ../../gcc/gcc/ada/table.ads ../../gcc/gcc/ada/butil.ads ../../gcc/gcc/ada/debug.ads ../../gcc/gcc/ada/fname.ads ../../gcc/gcc/ada/namet.ads ../../gcc/gcc/ada/alloc.ads ../../gcc/gcc/ada/hostparm.ads ../../gcc/gcc/ada/opt.ads ../../gcc/gcc/ada/osint.ads ../../gcc/gcc/ada/output.ads ../../gcc/gcc/ada/table.adb ../../gcc/gcc/ada/tree_io.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:393 This was with revision 120700. Same error occurs under hpux. Last successful build was with 120606. -- Summary: Segmentation fault: Error detected at ali.adb:2240:1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30453
[Bug ada/30453] Segmentation fault: Error detected at ali.adb:2240:1
--- Comment #1 from danglin at gcc dot gnu dot org 2007-01-12 23:56 --- Starting program: /home/dave/gnu/gcc-4.3/objdir/prev-gcc/gnat1 -I- -I. -Iada -I../../gcc/gcc/ada -quiet -dumpbase ali.adb -O2 -g -gnatpg -gnata ../../gcc/gcc/ada/ali.adb -o xxx.s Program received signal SIGSEGV, Segmentation fault. 0x00b0b368 in lookup_page_table_entry (p=0x75) at ../../gcc/gcc/ggc-page.c:605 605 return base[L1][L2]; (gdb) bt #0 0x00b0b368 in lookup_page_table_entry (p=0x75) at ../../gcc/gcc/ggc-page.c:605 #1 0x00b0b174 in ggc_set_mark (p=0x75) at ../../gcc/gcc/ggc-page.c:1284 #2 0x0091cc50 in gt_ggc_mx_tree_ann_d (x_p=0x75) at gtype-desc.c:622 #3 0x000854c0 in gt_ggc_mx_lang_tree_node (x_p=0x40ca9690) at ./gtype-ada.h:41 #4 0x00087418 in gt_ggc_mx_lang_tree_node (x_p=0x40a20ae0) at ./gtype-ada.h:346 #5 0x00088000 in gt_ggc_mx_lang_decl (x_p=0x40a0ffd8) at ./gtype-ada.h:484 #6 0x000862a8 in gt_ggc_mx_lang_tree_node (x_p=0x40a07b58) at ./gtype-ada.h:175 #7 0x000876c4 in gt_ggc_mx_lang_tree_node (x_p=0x409cfe38) at ./gtype-ada.h:377 #8 0x00087a30 in gt_ggc_mx_lang_tree_node (x_p=0x40ca2480) at ./gtype-ada.h:413 #9 0x00087418 in gt_ggc_mx_lang_tree_node (x_p=0x40a11820) at ./gtype-ada.h:346 #10 0x00087418 in gt_ggc_mx_lang_tree_node (x_p=0x40a0a750) at ./gtype-ada.h:346 #11 0x00088000 in gt_ggc_mx_lang_decl (x_p=0x40a0f250) at ./gtype-ada.h:484 #12 0x000862a8 in gt_ggc_mx_lang_tree_node (x_p=0x40a077e8) at ./gtype-ada.h:175 #13 0x0091ae9c in gt_ggc_mx_int_tree_map (x_p=0x40c75590) at gtype-desc.c:98 #14 0x009204a8 in gt_ggc_m_P12int_tree_map4htab (x_p=0x40c59e40) ---Type to continue, or q to quit--- at gtype-desc.c:1628 #15 0x0091be74 in gt_ggc_mx_gimple_df (x_p=0x40c6f0f8) at gtype-desc.c:414 #16 0x0091c774 in gt_ggc_mx_function (x_p=0x40a33000) at gtype-desc.c:562 #17 0x00086eb8 in gt_ggc_mx_lang_tree_node (x_p=0x4018fc40) at ./gtype-ada.h:282 #18 0x000861e8 in gt_ggc_mx_lang_tree_node (x_p=0x40a37058) at ./gtype-ada.h:169 #19 0x000870a4 in gt_ggc_mx_lang_tree_node (x_p=0x409d2600) at ./gtype-ada.h:307 #20 0x00086a70 in gt_ggc_mx_lang_tree_node (x_p=0x409d60d0) at ./gtype-ada.h:246 #21 0x000876c4 in gt_ggc_mx_lang_tree_node (x_p=0x409cf230) at ./gtype-ada.h:377 #22 0x00087a30 in gt_ggc_mx_lang_tree_node (x_p=0x40a92c90) at ./gtype-ada.h:413 #23 0x0091c64c in gt_ggc_mx_tree_statement_list_node (x_p=0x40a992b0) at gtype-desc.c:546 #24 0x000879ac in gt_ggc_mx_lang_tree_node (x_p=0x40a09378) at ./gtype-ada.h:407 #25 0x0091d0e4 in gt_ggc_mx_basic_block_def (x_p=0x40b6e360) at gtype-desc.c:714 #26 0x0091cd54 in gt_ggc_mx_tree_ann_d (x_p=0x40b6dd20) at gtype-desc.c:638 #27 0x000879f0 in gt_ggc_mx_lang_tree_node (x_p=0x40abd048) ---Type to continue, or q to quit--- at ./gtype-ada.h:411 #28 0x0091b1dc in gt_ggc_mx_cgraph_edge (x_p=0x40ba1578) at gtype-desc.c:158 #29 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba1540) at gtype-desc.c:156 #30 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba1508) at gtype-desc.c:156 #31 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba14d0) at gtype-desc.c:156 #32 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba1498) at gtype-desc.c:156 #33 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba13b8) at gtype-desc.c:156 #34 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b9dd20) at gtype-desc.c:156 #35 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b9dbd0) at gtype-desc.c:156 #36 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b9db98) at gtype-desc.c:156 #37 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b92d90) at gtype-desc.c:156 #38 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5230) at gtype-desc.c:156 #39 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5188) at gtype-desc.c:156 #40 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b94c40) at gtype-desc.c:156 #41 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40b94818) at gtype-desc.c:156 #42 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba59d8) at gtype-desc.c:156 #43 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba59a0) at gtype-desc.c:156 #44 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5968) at gtype-desc.c:156 #45 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba58c0) at gtype-desc.c:156 #46 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5888) at gtype-desc.c:156 #47 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5850) at gtype-desc.c:156 #48 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba57a8) at gtype-desc.c:156 #49 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba5620) at gtype-desc.c:156 ---Type to continue, or q to quit--- #50 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40ba53b8) at gtype-desc.c:156 #51 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40c51150) at gtype-desc.c:156 #52 0x0091b19c in gt_ggc_mx_cgraph_edge (x_p=0x40c51118) at gtype-desc.c:156 #53 0x0091b314 in gt_ggc_mx_cgraph_node (x_p=0x40b8e500) at gtype-desc.c:182 #54 0x00920d30 in gt_ggc_m_P11cgraph_node4htab (x_p=0x400066c0) at gtype-desc.c:1782 #55 0x00918aa0 in ggc_mark_roots () at ../../gc
[Bug middle-end/30453] [4.3 Regression] Segmentation fault: Error detected at ali.adb:2240:1
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-13 00:00 --- This is most likely the same issue as: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01075.html Why it only happens with Ada on ia64/hppa is a different question. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|ada |middle-end Keywords||build, ice-on-valid-code Summary|Segmentation fault: Error |[4.3 Regression] |detected at ali.adb:2240:1 |Segmentation fault: Error ||detected at ali.adb:2240:1 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30453
[Bug libgcj/30454] New: classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
/test/gnu/gcc/objdir/gcc/gcj -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjav a/ -B/test/gnu/gcc/objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc/libjava /classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -f source-filename=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/classpath/lib /classes -MT gnu/javax/crypto/jce.lo -MD -MP -MF gnu/javax/crypto/jce.deps @gnu/ javax/crypto/jce.list -fPIC -o gnu/javax/crypto/.libs/jce.o ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java: In cla ss 'gnu.javax.crypto.jce.GnuCrypto$1': ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java: In met hod 'gnu.javax.crypto.jce.GnuCrypto$1.run()': ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:433: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacTigerSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:433: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacTigerSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:435: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacHavalSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:435: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacHavalSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:437: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacWhirlpoolSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:437: er ror: cannot find file for class gnu.javax.crypto.jce.mac.HMacWhirlpoolSpi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:438: er ror: cannot find file for class gnu.javax.crypto.jce.mac.TMMH16Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:438: er ror: cannot find file for class gnu.javax.crypto.jce.mac.TMMH16Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:439: er ror: cannot find file for class gnu.javax.crypto.jce.mac.UHash32Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:439: er ror: cannot find file for class gnu.javax.crypto.jce.mac.UHash32Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:440: er ror: cannot find file for class gnu.javax.crypto.jce.mac.UMac32Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:440: er ror: cannot find file for class gnu.javax.crypto.jce.mac.UMac32Spi ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:443: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacAnubisImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:443: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacAnubisImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:445: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacBlowfishImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:445: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacBlowfishImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:447: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacCast5Impl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:447: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacCast5Impl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:449: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacDESImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:449: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacDESImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:451: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacKhazadImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:451: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacKhazadImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:453: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacRijndaelImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:453: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacRijndaelImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:455: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacSerpentImpl ../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/GnuCrypto.java:455: er ror: cannot find file for class gnu.javax.crypto.jce.mac.OMacSerpentImpl ../../../../../gcc/libjava/classpat
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-13 01:01 ---
(In reply to comment #4)
> so the test fails, but the generated code is correct and optimal. I suggest
> adding -fno-pic to the test, does that look OK?
I no longer have access to the x86 boxes I was using for testing last year. So
I can't test any fix. But anyway, if I recall correctly adding -fno-pic won't
help because stuff in RUNTESTFLAGS is added *after* the dg-options flags. So
pic will still be turned on if the user selects it. Instead do something like
what's in gcc.dg/sibcall-6.c, namely:
/* { dg-skip-if "" { { i?86-*-* x86_64-*-* } && ilp32 } { "-fpic" "-fPIC" } {
"" } } */
I don't think the check for ilp32 is wanted in this case though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #8 from gin at mo dot msk dot ru 2007-01-13 01:15 --- Subject: Re: -B$(build_tooldir)/bin/ Wrote on Fri, 29 Dec 2006 17:35:39 +0300: > will try it for 3.0.3 Did so. `--with-ld=/bin/ld --without-gnu-ld' it did link programs properly even if `$(build_tooldir)/bin/ld' was present and broken and even if passed `-B$(build_tooldir)/bin/'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #6 from dalej at apple dot com 2007-01-13 01:32 --- Stuff in --tool_opts from RUNTESTFLAGS goes before the dg-options on the command line, I just tried it. Is there some other way to do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-13 01:58 --- I am implementing something for this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
[Bug c++/20019] incorrect overflow warning
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-13 02:23 --- There is no warning with GCC 4.3 and you can get a warning for the int->char conversion by using -Wconversion. So I am going to close this. Please, feel free to reopen if you think there is some unresolved issue. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-01-13 05:01 --- (In reply to comment #6) > Stuff in --tool_opts from RUNTESTFLAGS goes before the dg-options on the > command line, I just tried it. Is there some other way to do it? Yes, the GCC docs suggest using --target_board: http://gcc.gnu.org/install/test.html I could be wrong, but I'm pretty sure that one appends the flags you supply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-13 05:17 --- (In reply to comment #2) > (In reply to comment #1) > > We can implement the complex variants in term of the real ones in mpfr, no? > > I > > don't like the idea of another build-dependency ;) > > > Yes, you can. gfortran does this already for several Fortran > intrinsic functions. See fortran/simplify.c. Yes, but think of the waste of creating all these complex functions only to hide them inside GCC. In a perfect world, these would exist inside MPFR or MPC and I'd have more confidence they'd have less bugs. Sigh, in the real world I guess it'll have to be a one-off for GCC and hope I don't hose all the corner cases. I'm not a wiz at this exact precision calculation hooha. Hopefully someone will stop me before I shoot myself. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2007-01-13 06:09 --- Subject: Re: Evaluate complex math functions at compile-time On Sat, Jan 13, 2007 at 05:17:11AM -, ghazi at gcc dot gnu dot org wrote: > > --- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-13 05:17 --- > > Yes, but think of the waste of creating all these complex functions > only to hide them inside GCC. In a perfect world, these would exist > inside MPFR or MPC and I'd have more confidence they'd have less bugs. Well, mpfr doesn't have a complex type, and you've already broached the possible negative effect of requiring another 3rd party library to build GCC. From watching the mailing lists, you already caught enough crap for using mpfr. I still don't understand why so many people got bent out of shape. > Sigh, in the real world I guess it'll have to be a one-off for GCC > and hope I don't hose all the corner cases. I'm not a wiz at this > exact precision calculation hooha. Hopefully someone will stop me > before I shoot myself. :-) You don't have to be a whiz. IEEE 754 requires exact results for only sqrt() for floating point types. For all other libm functions one strives for results that are correct to less than or equal to 0.5 ULP. The most important item is a good understand of complex analysis and in particular branch cuts (see the glibc csqrt bug). Another thing to note, mpfr returns the correct result to whatever precision you requested. Internally, mpfr may, and often does, compute that result with much higher precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug target/30455] New: i386 generates unnecessary TEST instructions for arithmetic ops on memory
Consider the following function:
int add_zf(int *x, int y, int a, int b)
{
if ((*x += y) == 0)
return a;
else
return b;
}
Ideally, it should produce (modulo cmov verses branches / scheduling issues):
addl%esi, (%rdi)
movl%edx, %eax
cmovne %ecx, %eax
ret
Instead, it produces:
addl(%rdi), %esi# reversed
movl%edx, %eax
testl %esi, %esi # unnecessary
movl%esi, (%rdi)# unnecessary
cmovne %ecx, %eax
ret
This is true of all flags and all arithmetic instructions (afaict).
--
Summary: i386 generates unnecessary TEST instructions for
arithmetic ops on memory
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmiell at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30455
[Bug fortran/30452] Strange syntax error with high-value character
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-13 07:00 --- At the lowest level, next_char in scanner.c is returning -2. That is not right for sure. I am wondering if there is an error reading the file. I will dig further. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-13 07:00:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug fortran/30452] Strange syntax error with high-value character
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-13 07:20 --- Turns out that the character 254 which is Hex FE is also the 2's complement representation of -2 which is what is used to signal an error if there is a missing delimiter. It should not be converting this to an int -2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
