--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-17 08:00 ---
Then _Jv_GetStringChars should be dropped from libgcj_bc.so too.
And for the other function, I think adding a "C" alias in libgcj.so.* and
a C++ in libgcj_bc.so wouldn't hurt.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #12 from pault at gcc dot gnu dot org 2009-01-17 08:39 ---
The fix has caused the regression reported in
http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html so I am reverting on trunk
and 4.3.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Rem
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-17 09:04
---
Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly
mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1 bind
(indeed the testcases provided by Doug are rather cle
Found in PR 38871. The following is invalid as C_F_FUNPTR takes
function/procedure pointers as arguments.
TODO: Check also that C_F_POINTER doesn't take a type(c_ptr) as argument.
use iso_c_binding
type(c_ptr) :: fun
integer, pointer :: bar
call c_f_funpointer(fun,bar)
end
--
Summar
--- Comment #7 from burnus at gcc dot gnu dot org 2009-01-17 09:18 ---
(In reply to comment #6)
> I'd say re-adding that symbol until you change libgfortran ABI wouldn't hurt
> anything, but if you can prove no program could ever use it except for
> referencing directly that symbol, I gu
--- Comment #13 from pault at gcc dot gnu dot org 2009-01-17 09:29 ---
Subject: Bug 38657
Author: pault
Date: Sat Jan 17 09:28:50 2009
New Revision: 143458
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143458
Log:
2009-01-17 Paul Thomas
PR fortran/38657
* mo
--- Comment #8 from burnus at gcc dot gnu dot org 2009-01-17 09:37 ---
> However, I just saw that due to missing argument checking the following works
> in gfortran 4.3:
>
> call c_f_funpointer(fun,bar) ! <<< Invalid; should be C_F_POINTER
That's actually nonsense. The procedure name is
--- Comment #14 from pault at gcc dot gnu dot org 2009-01-17 09:44 ---
Subject: Bug 38657
Author: pault
Date: Sat Jan 17 09:43:57 2009
New Revision: 143459
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143459
Log:
2009-01-17 Paul Thomas
PR fortran/38657
* mo
--- Comment #9 from burnus at gcc dot gnu dot org 2009-01-17 09:58 ---
Patch http://gcc.gnu.org/ml/fortran/2009-01/msg00209.html
or one can close it as WONTFIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-17 10:46 ---
The example was wrong as the name is c_f_PROCpointer (no -fun- only in
type(c_funptr) and c_FUNloc). Working example:
use iso_c_binding
type(c_ptr) :: fun
procedure(), pointer :: bar
call c_f_procpointer(fun,bar) !
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-17 10:57
---
Well, I don't know how fortran strings are supposed to work, but for the
80 chars in a C string you need 81 bytes, 1 byte for the terminating null
character. Also you single-file testcase prints nothing at -O0 for
--- Comment #22 from pault at gcc dot gnu dot org 2009-01-17 11:32 ---
Subject: Bug 34955
Author: pault
Date: Sat Jan 17 11:32:02 2009
New Revision: 143462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143462
Log:
2009-01-17 Paul Thomas
PR fortran/34955
* tr
--- Comment #23 from pault at gcc dot gnu dot org 2009-01-17 11:34 ---
Fixed on trunk.
Thanks for the report and sorry that it took so long to fix.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mikael at gcc dot gnu dot org 2009-01-17 11:54 ---
I vote for WONTFIX.
But I can live with a patch revert. ;)
While a program could reference the symbol, it seems highly unlikely.
And anyway, 4.3 is still there in case it is needed.
--
http://gcc.gnu.org/bug
--- Comment #15 from pault at gcc dot gnu dot org 2009-01-17 11:58 ---
Subject: Bug 38657
Author: pault
Date: Sat Jan 17 11:58:48 2009
New Revision: 143463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143463
Log:
2009-01-17 Paul Thomas
PR fortran/38657
* mo
--- Comment #19 from dominiq at lps dot ens dot fr 2009-01-17 12:29 ---
Further reduced test case:
PROGRAM testcase
IMPLICIT NONE
INTEGER NENERT
PARAMETER (NENERT=62)
LOGICAL QENER(NENERT)
CHARACTER*4 ANER(NENERT)
CHARACTER*80 LINE
INTEGE
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-17 12:54
---
With Dominique's reduced test case I see three valgrind errors. Actual output
is fine. I am looking further.
==4359== Conditional jump or move depends on uninitialised value(s)
==4359==at 0x43793D: strlen (
RTL alias analysis (nonoverlapping_component_refs_p) with a quadratic loop
finds that c->a1.i and b->a1.j cannot alias based on a offset test on the
common sub-reference base a1. The tree based alias oracle only does two
linear searches for the base type *c in b->a1.j and for *b in c->a1.i.
This
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-17 12:58
---
Note that we have to be very careful here because
struct X {
int i;
};
struct A {
int i;
};
struct B {
struct A a;
int j;
};
int foo (struct X *p, struct B *q)
{
p->i = 0;
q->a.i = 1;
return p->i;
}
--- Comment #12 from dominiq at lps dot ens dot fr 2009-01-17 13:20 ---
(In reply to comment #11)
> This PR can be closed, provided there are no remaining issues on darwin9 (see
> comment #4 and #5). I cannot check this myself (since I don't have access to a
> darwin system), but maybe D
--- Comment #13 from burnus at gcc dot gnu dot org 2009-01-17 13:25 ---
Close as FIXED based on Dominique's remark.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-17 13:57 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
-enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --without-system-libunwind
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
It does matter whic
--- Comment #7 from rob1weld at aol dot com 2009-01-17 14:41 ---
Created an attachment (id=17127)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17127&action=view)
Screenshot of build shows libgcj_tools building (after reboot)
Before reboot:
# gmake
...
gmake[3]: Entering director
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-17 14:59 ---
shouldn't this be fixed for 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
--- Comment #21 from sebpop at gmail dot com 2009-01-17 15:11 ---
Subject: Re: r143152 breaks output routines in
xplor-nih
On Sat, Jan 17, 2009 at 6:29 AM, dominiq at lps dot ens dot fr
wrote:
> Somehow I got the impression that graphite is now enabled at -O2
We did enabled
--- Comment #10 from thomas dot jourdan at gmail dot com 2009-01-17 15:23
---
Hi
My mistake was to export a function in the bash to fool a shell script. But
then I configured GCC without removing it.
I did :
function install() { ginstall "$@"; }
export -f install
Then I configured G
Attached is locale-inst.ii for gcc-4_3-branch revision 143448.
The assembler says, during build:
locale-inst.s: Assembler messages:
locale-inst.s:192360: Error: bignum invalid
The line, with context, is (with -dA -mpdebug for improved clarity, but causing
the line number to change to 203626):
20
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-17 15:44 ---
Created an attachment (id=17128)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17128&action=view)
as mentioned
Use cc1plus -fpreprocessed locale-inst.ii -march=v32 -quiet -dumpbase
locale-inst.cc -dA -mpdebug -auxb
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-17 15:45 ---
> shouldn't this be fixed for 4.3.3?
Too late - the release is too soon (freeze; release-candidate build is
running). Regarding 4.4.0: Do you plan to submit a patch soonish?
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-17 15:46 ---
Configured with /tmp/hptest/v32l/gcc/configure
--prefix=/n/common_data/comptools/cris-1.64-64 --target=crisv32-axis-linux-gnu
--with-gnu-ld --with-gnu-as --enable-checking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-17
16:02 ---
Subject: Re: FAIL: abi_check hppa
> I think we also need float stubs. I saw some problems with
> floorf in the testsuite in my last build.
There are four testsuite fails due to floorf being missing. He
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-17 16:03 ---
Subject: Bug 38895
Author: rguenth
Date: Sat Jan 17 16:02:36 2009
New Revision: 143469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143469
Log:
2009-01-17 Richard Guenther
PR middle-end/13146
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-17 16:03
---
Subject: Bug 13146
Author: rguenth
Date: Sat Jan 17 16:02:36 2009
New Revision: 143469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143469
Log:
2009-01-17 Richard Guenther
PR middle-end/13146
--- Comment #3 from hp at gcc dot gnu dot org 2009-01-17 16:06 ---
Um, ok, it's __gnu_cxx::__numeric_traits_integer::__min
so the number as such is most likely valid. :)
Not sure if that number is supposed to be valid as a .sleb128 operand though.
I'd better assign this to myself and che
--- Comment #4 from hp at gcc dot gnu dot org 2009-01-17 16:12 ---
Trunk binutils accepts it but produces junk:
Contents of section .text:
80808080 80808080 807f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
--- Comment #5 from hp at gcc dot gnu dot org 2009-01-17 16:15 ---
(In reply to comment #4)
> 80808080 80808080 807f
Silly me, that's the right sleb128 encoding, IIUC. Doh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
--- Comment #6 from hp at gcc dot gnu dot org 2009-01-17 16:38 ---
(In reply to comment #3)
> I'd better assign this to myself and check.
FWIW, the assembler that complained was an old 2.12.something. There's a gcc
sleb128 configure check, but it doesn't check for large numbers.
--
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-01-17 16:40
---
Comment 20 was compiled with -static -g. Each error is at functions outside
libgfortran. Valgrind reports zero errors if the test case is compiled without
-static. I suspect comment 20 is misleading.
--
h
--- Comment #1 from ubizjak at gmail dot com 2009-01-17 17:04 ---
The problem is in a thinko in alias.c, base_alias_check (). For our problematic
addresses, we enter base_alias_check with:
x = (reg:DI 18 $18 [ i ])
and
y = (and:DI (reg/f:DI 16 $16 [orig:69 __result ] [69])
(con
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-17 17:19 ---
So... fixing the sleb128 configure test (to check that this number is parsed
and handled correctly) is fairly simple, but should perhaps only be done for
targets that actually will use 64-bit numbers. If someone wants to
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-17 18:05 ---
That code is ancient, and wrong from day 1 if your analysis is correct :-)
http://gcc.gnu.org/viewcvs/trunk/gcc/alias.c?r1=21967&r2=23060
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
Compilation fails of the small code sample found at:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch31s03.html
I am using the suggested compiler options.
This is the code (cut and pasted from your documentation):
#include
#include
int main()
{
std::vector v(100);
// ...
// E
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-17 18:12 ---
I have similar results as comment #0 on i686-apple-darwin9 (Core2) trunk
revision 143468:
Date & Time : 17 Jan 2009 17:41:32
Test N
--- Comment #3 from ubizjak at gmail dot com 2009-01-17 18:40 ---
(In reply to comment #2)
> That code is ancient, and wrong from day 1 if your analysis is correct :-)
Hm, no. The code is correct, but applies only to symbols involving ANDs.
We need somehing like this code also for the
ith-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
Thanks,
Rob
--
Summary: gcc 4.4.0 20090117 - Testsuite - tree-ssa.exp -
unmat
--- Comment #1 from schwab at suse dot de 2009-01-17 19:37 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00468.html
--
schwab at suse dot de changed:
What|Removed |Added
[ Forwarded from http://bugs.debian.org/512050 ]
brian m. carlson reports the following problem with gcc 4.3 and trunk:
Attached is a C file that is compiled with -O3. mul and mul2 perform the
same operation; mul uses a loop, and mul2 uses SSE intrinsics. mul2
results in three instructions, whe
--- Comment #1 from tbm at cyrius dot com 2009-01-17 19:40 ---
Testcase:
#include
#include
#ifndef MUL
#define MUL mul
#endif
void mul(float in1[4], float in2[4], float out[4])
{
int i;
for (i = 0; i < 4; i++)
out[i] = in1[i] * in2[i];
}
void mul2(f
--- Comment #2 from davek at gcc dot gnu dot org 2009-01-17 21:06 ---
Subject: Bug 38862
Author: davek
Date: Sat Jan 17 21:06:17 2009
New Revision: 143472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143472
Log:
PR bootstrap/38862
* Makefile.in (BACKENDLIBS):
--- Comment #1 from a dot pignotti at sssup dot it 2009-01-17 22:11 ---
Created an attachment (id=17129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17129&action=view)
Proposed test case
compile using gcc -mno-sse to trigger the bug
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-17 22:20 ---
Created an attachment (id=17130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17130&action=view)
Difference of the dump
The problem is the call
_gfortran_internal_unpack (&parm.2, D.1572);
since the array
--- Comment #10 from danglin at gcc dot gnu dot org 2009-01-17 22:34
---
This is the last output of the register usage information prior to the dbr
pass. I am somewhat puzzled as to why register 124 doesn't appear as
allocated to %r28 in the "lr in" and "lr use" lines for blocks 4 an
--- Comment #23 from burnus at gcc dot gnu dot org 2009-01-17 22:51 ---
Program of comment 19 works here (x86-64) with all options I tried, incl. -m32,
-fgraphite-identity etc. - valgrind shows no problems.
For the program in attachment 17125 / commment 13: I get the same valgrind
outpu
gcc -S -O1 -foptimize-sibling-calls bug.c
bug.c: In function 'f':
bug.c:9: error: unable to find a register to spill in class 'CREG'
bug.c:9: error: this is the insn:
(call_insn/j 11 9 12 2 bug.c:8 (call (mem:QI (reg/f:SI 3 bx [59]) [0 S1 A8])
(const_int 0 [0x0])) 468 {*sibcall_1} (expr_li
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:19 ---
bug.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int) = h;
g(i);
g(i);
}
--
d dot g dot gorbachev at gmail dot com changed
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:20 ---
ok.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int);
g = h;
g(i);
g(i);
}
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-01-17
23:23 ---
I've had no luck triggering this problem on targets other than
i686-apple-darwin9. On that target -m64, suppresses the problem. As to the
issue with ANER(J) being undefined on line 162, this can be fixed w
--- Comment #25 from dominiq at lps dot ens dot fr 2009-01-17 23:28 ---
In the reduced case in comment #19 ANER is initialized and the output is still
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #26 from dominiq at lps dot ens dot fr 2009-01-17 23:48 ---
Further reduced test case:
PROGRAM testcase
IMPLICIT NONE
INTEGER NENERT
PARAMETER (NENERT=62)
CHARACTER*4 ANER(NENERT)
CHARACTER*80 LINE
INTEGER PUNIT
PUNIT = 6
I've tested this under gcc 4.2.1 (DJGPP) and gcc 3.4.4 (cygwin) (see below for
gcc -v outputs). The test program is simple: generate two random complex
numbers, multiply them using the FPU, and do it again using 3dnow inline
assembly. I can get it to work with different code, but this version
illus
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:17 ---
This is now fixed.
Will file a separate PR later for -lstdc++ problems.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
-
[...@gnu-17 gcc]$ /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src-4.3/configure --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld
Thread model: posix
gcc version 4.3.3 20090117 (prerelease) [gcc-4_3
--- Comment #1 from schwab at suse dot de 2009-01-18 00:25 ---
The asm statement modifies an input-only operand. If an operand is modified it
must be listed as output operand, possibly marked as early-clobber if it is
written before all input operands are consumed.
--
schwab at suse
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
[refs: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00060
http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00216 ]
Bootstrap on cygwin is currently failing during stage 3 with:
/home/andy/live-gcc/my_gcc/./gcc/xgcc
-B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/b
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:31 ---
Created an attachment (id=17131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17131&action=view)
Remove troublesome clause from libiberty configure
Now testing vs. both src/ and gcc/
--
http:
The shared libgcc DLL currently built for cygwin is named "libgcc_s_1.dll", and
it comes with an import library named "libgcc_s.a". These both violate the
Cygwin platform naming conventions. All DLLs are prefixed with 'cyg' rather
than 'lib' on the Cygwin target, and the corresponding import libr
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:41 ---
Oh, I forgot to mention a further non-standardness about the DLL's name: on the
Cygwin platform, the shared library version number should be separated from the
name by a hyphen, not an underscore. So for
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-01-18 01:33
---
Closing, the code is invalid Fortran
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-18 01:41 ---
bash-3.2$ cat /tmp/x.c
extern void abort ();
int foo (const char *, const char *);
int main (void)
{
char buffer[1024]="";
__builtin_strcpy (buffer, "1234567890abcdefghijklmno");
if (foo (buffer, "1234567890a
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-18 01:43 ---
bash-3.2$ cat /tmp/x.c
extern void abort ();
int foo (const char *, const char *);
int main (void)
{
char buffer[1024]="";
__builtin_strcpy (buffer, "1234567890abcdefghijklmno");
if (foo (buffer, "1234567890a
--- Comment #7 from bangerth at dealii dot org 2009-01-18 03:58 ---
(In reply to comment #6)
> Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly
> mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1
> bind
> (indeed the testcases provide
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-18
05:57 ---
Created an attachment (id=17132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view)
Move _ctors* and _chkstk* to import lib
Danny, this is the approach that I think I'd like to take f
74 matches
Mail list logo
