--- Comment #3 from paulthomas2 at wanadoo dot fr 2006-01-10 05:16 ---
Subject: Re: Components of a derived type array not passed
as an array
pinskia at gcc dot gnu dot org wrote:
>--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 23:24
>---
>the parse tree is c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-10 04:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-10 04:44 ---
*** Bug 22044 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 04:44 ---
*** This bug has been marked as a duplicate of 25690 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-10 04:44 ---
*** Bug 24603 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-10 04:44 ---
*** This bug has been marked as a duplicate of 25690 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-10 04:39 ---
Yes, we are not rejecting this early enough so we get the ICE in the trans*
functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 04:35 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 04:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-01-10 04:01 ---
fixed in mainline and 4.1.x
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-10 04:01 ---
Related to PR 20541.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepen
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-01-10 04:01 ---
Subject: Bug 25472
Author: bkoz
Date: Tue Jan 10 04:01:00 2006
New Revision: 109531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109531
Log:
2006-01-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstdc
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-10 02:46 ---
0x0004ae5c in gfc_match_common () at
/Users/pinskia/src/gcc/alias/gcc/gcc/fortran/match.c:2284
2284 while (tail->common_next)
(gdb)
2285tail = tail->common_next;
tail and tail->common_
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-10 01:03 ---
This is a regression as it worked on "4.2.0 20051219" though it did not work
with "4.2.0 20051231".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
extern int foo (float _Complex);
int
main ()
{
float _Complex z;
__real__ z = 0.0;
__imag__ z = -1.0;
return foo (z);
}
gcc -S -O2 complex.c
.LEVEL 1.1
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.word -1082130432
.text
.
--- Comment #5 from tobi at gcc dot gnu dot org 2006-01-10 00:12 ---
All dependencies have been fixed. Closing. If anybody ever gets access to new
SPEC sources, they're free to open a new one.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from tobi at gcc dot gnu dot org 2006-01-10 00:10 ---
(In reply to comment #9)
> We don't get an error message but instead we call _gfortran_internal_malloc
> with a zero value and invoked undefined behavior in malloc.
No. This is specifically guarded against:
69 /
--- Comment #8 from tromey at gcc dot gnu dot org 2006-01-10 00:07 ---
Applied 4.0 fix to 4.1; 4.2 still unfixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-10 00:04 ---
Reduced testcase:
MODULE testcase
TYPE orbit_elem
CHARACTER :: coo
END TYPE orbit_elem
END MODULE
MODULE tp_trace
USE testcase
TYPE(orbit_elem) :: tp_store
CONTAINS
SUBROUTINE str_clan()
USE testca
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-01-10 00:03
---
(In reply to comment #5)
> The limit was rose but we should be able to do better.
Indeed. But the problem is not trivial. For a case like above, where the
array is a variable, we can translate it to
(program|fu
--- Comment #3 from andrea dot bedini at gmail dot com 2006-01-10 00:02
---
In gfc_conv_component_ref line 280 I read
if (c->ts.type == BT_CHARACTER)
{
tmp = c->ts.cl->backend_decl;
/* Components must always be constant length. */
gcc_assert (tmp && INTEGER_CST
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-09 23:55 ---
We don't get an error message but instead we call _gfortran_internal_malloc
with a zero value and invoked undefined behavior in malloc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15335
--- Comment #2 from andrea dot bedini at gmail dot com 2006-01-09 23:54
---
Created an attachment (id=10604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10604&action=view)
backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25730
--- Comment #1 from andrea dot bedini at gmail dot com 2006-01-09 23:53
---
Created an attachment (id=10603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10603&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25730
$ /home/andrea/software/gcc-build/gcc/f951 -Wall -o testcase.o testcase.f90
str_clan
testcase.f90:19: internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:282
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for inst
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-09 23:49 ---
This is fixed for real in 4.1.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 23:47 ---
Lahey's f95 compiler says:
1652-S: "SOURCE.F90", line 7, column 9: 'foo' shall be declare as a function
in a host or module scoping unit.
Though Lahey's F90 compiler says nothing.
--
http://gcc.gnu.org/bugzi
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 23:41 ---
Fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23573
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-09 23:37 ---
Fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 23:37 ---
Fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 23:31 ---
Also this causes us to lose information lowering in the middle-end that what
the size of the arrays were.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-09 23:25 ---
Then let's close it. Thanks!
I'm closing it as WONTFIX because the problem may still exist in GCC 3.0 and
3.1 at least, and we're not going to fix that.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 23:24 ---
the parse tree is correct:
CALL foo ((MAIN__:list(FULL) % word))
So this is just a trans issue as far as I can tell.
Also it is even worse with, were we print way wrong stuff:
program test_lex
type :: dtype
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 23:15 ---
The problem here is that we did not reduce transfer to a constant.
Hmm, the problem is fully transfer which is why this fully related to PR 17298.
Looks like we don't currently handle transfer that well.
--
pin
--- Comment #8 from sje at cup dot hp dot com 2006-01-09 22:57 ---
I submitted the bug and you won't hurt my feelings if you close it out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4648
--- Comment #27 from tkoenig at gcc dot gnu dot org 2006-01-09 22:53
---
Created an attachment (id=10602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10602&action=view)
proposed patch for environment variable
This implements setting the default for byte-swapping via an
environm
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-09 22:50 ---
Disassembly of section .text for x86 (compiled on AMD64 with -m32 -mtune=i686):
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 4d 10
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-09 22:44 ---
For reference, gcc 3.3-hammer-branch has the following .text sizes:
flags: .text size:
-Os 83
-m32 -Os44
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1821
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-09 22:43 ---
And the numbers for "gcc (GCC) 4.1.0 20060109" are
flags: .text size:
-Os 86 bytes
-Os -fno-ivopts 86 bytes
-m32 -Os58 bytes
-m32 -Os -
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-09 22:35 ---
This is weird as I cannot reproduce it on powerpc-darwin but can on
x86_64-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 22:33 ---
Here is a testcase which fails currently because of this bug:
program stuff
integer :: i_do
integer :: i(11) = (/ (i_do, i_do=1,11) /)
write (*,*) i
end program stuff
-
The limit was
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-09 22:31 ---
we no longer ICE on this code but we still accept it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #35 from steven at gcc dot gnu dot org 2006-01-09 22:26 ---
...and so we go blame Diego for the 4.1/4.2 problem, because gcse.c CPROP is no
longer a problem here for GCC 4.0/4.1/4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-09 22:23 ---
AMD64 timings for today's GCC 4.1 (20060109) branch:
flags used score
for compilation (avg. of 3, higher is better
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-09 22:08 ---
(In reply to comment #5)
> I get a lot of output with:
> $ gcc -E -dD test.c
>
> Perhaps that is what you're looking for. This looks more like a documentation
> bug to me than a real preprocessor bug.
It is not, -
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-09 22:02 ---
IA-64 is a secondary platform, and Fortran is not a release critical language.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-09 22:00 ---
I get a lot of output with:
$ gcc -E -dD test.c
Perhaps that is what you're looking for. This looks more like a documentation
bug to me than a real preprocessor bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-09 21:57 ---
Your command line:
touch test.h; gcc -dM test.h
creates a precompiled header.
Also, my documentation for -dM says:
@item -dM
@itemx -fdump-rtl-mach
@opindex dM
@opindex fdump-rtl-mach
Dump after performing the
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-09 21:25 ---
Created an attachment (id=10601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10601&action=view)
proposed fix
This is my throw-over-the-wall completely untested proposed fix
for PR24257. We end up ICEing whe
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-09 20:44 ---
Fixed in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #9 from laurent at guerby dot net 2006-01-09 20:14 ---
<<
So it seems like C-family specific attributes are set for all alpha
builtins, which seems incorrect to me.
Two possible solutions come to mind:
* Make const and nothrow generic to avoid this.
* Only set them for C f
--- Comment #7 from tromey at gcc dot gnu dot org 2006-01-09 20:07 ---
Subject: Bug 21637
Author: tromey
Date: Mon Jan 9 20:07:22 2006
New Revision: 109505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109505
Log:
PR libgcj/21637:
* gnu/java/net/protocol/jar/Co
--- Comment #1 from hjl at lucon dot org 2006-01-09 19:59 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00495.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
verify-lines in gcc/testsuite/lib/gcov.exp has
proc verify-lines { testcase file } {
#send_user "verify-lines\n"
set failed 0
set fd [open $file r]
while { [gets $fd line] >= 0 } {
if [regexp "^ *(\[^:]*): *(\[0-9\]+):.*count\\((\[0-9\]+)\\)" \
"$line" all i
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-09 19:46 ---
Fixed for 4.1.0, thanks for your report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-09 19:46 ---
Subject: Bug 21977
Author: pinskia
Date: Mon Jan 9 19:46:23 2006
New Revision: 109504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109504
Log:
2006-01-09 Andrew Pinski <[EMAIL PROTECTED]>
PR fo
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-09 19:36 ---
Subject: Bug 21977
Author: pinskia
Date: Mon Jan 9 19:36:35 2006
New Revision: 109503
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109503
Log:
2006-01-09 Andrew Pinski <[EMAIL PROTECTED]>
PR fo
--- Comment #7 from tobi at gcc dot gnu dot org 2006-01-09 18:57 ---
Discussion on how to fix this has taken place in PR18540.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from tobi at gcc dot gnu dot org 2006-01-09 18:56 ---
(In reply to comment #16)
> The idea of comment #14 and #15 looks better than mine, yes.
I'll continue what I've started, then.
> Which bug is the slowness bug btw? We should really be discussing solutions
> for tha
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-09 18:35 ---
The idea of comment #14 and #15 looks better than mine, yes.
Which bug is the slowness bug btw? We should really be discussing solutions
for that bug in the audit trail of that bug instead of this one ;-)
--
h
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-09 18:34 ---
No longer working on this, I am too busy working on the gfortran front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-09 18:34 ---
No longer working on this, I am too busy working on the gfortran front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-09 18:33
---
No longer working on this, I am too busy working on the gfortran front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 18:33 ---
No longer working on this, I am too busy working on the gfortran front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-09 18:33 ---
Here is that patch:
[zhivago:gcc/gcc/fortran] pinskia% svn diff trans-stmt.c
Index: trans-stmt.c
===
--- trans-stmt.c(revision 109491)
+++ tran
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 18:30 ---
I have a fix for the ICE, it is an easy one, it just copies what was done in
gfc_trans_pointer_assign to gfc_trans_pointer_assign_need_temp. Though I don't
think we need a temporary variable here, I have not looked
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-01-09 18:26 ---
As far as I know the kernel guys rely on the fact that gcc can
handle DImode operations without calling libgcc. As Richard pointed out
this only fails in this case because the conditional jump is emitted
differentl
--- Comment #24 from cagney at redhat dot com 2006-01-09 18:21 ---
(In reply to comment #20)
> but it doesn't seem like a good idea in general. This LD_PRELOAD hack seems
> to
> make every child of /usr/bin/java load libgcj.so.7 and so potentially breaks
> all manner of things.
>
--- Comment #6 from dir at lanl dot gov 2006-01-09 18:18 ---
Hurray - Let there be an end to I/O problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-09 18:05 ---
This is not a regression after all, the checking only happens for
ENABLE_CHECKING and not just enabled all ways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-09 17:57 ---
Some more information:
(gdb) p debug_generic_expr(lhs.common.type)
charD.14[1:32] *
$3 = void
(gdb) p debug_generic_expr(rhs.common.type)
charD.14 *
So we have lhs of a pointer to an array of and not a pointer to a
--- Comment #23 from jakub at gcc dot gnu dot org 2006-01-09 17:42 ---
Forgot to mention, the fix would be to use dlvsym (RTLD_NEXT, "pthread_create",
"GLIBC_2.1") (on i?86 and several other platforms) and different versions
on other arches (GLIBC_2.2.5 on x86_64, etc.).
--
http://g
--- Comment #22 from jakub at gcc dot gnu dot org 2006-01-09 17:41 ---
Just FYI, dlsym (RTLD_NEXT, "pthread_create") is wrong when using glibc.
pthread_create is symbol versioned and there are on most arches 2 different
pthread_create implementations. By using dlsym (RTLD_NEXT, "pthread
--- Comment #21 from greenrd at gcc dot gnu dot org 2006-01-09 17:32
---
For those wondering what aph is talking about, the hack he is referring to (or
at least the initial proposal for it) is at
https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg2.html
--
h
--- Comment #20 from aph at gcc dot gnu dot org 2006-01-09 17:25 ---
This breaks java on s390.
# LD_PRELOAD=/usr/lib/jvm/java-gcj/jre/lib/s390/pr13212.so /bin/echo
/bin/echo: symbol lookup error: /usr/lib/libgcj.so.7: undefined symbol:
__data_start
This is because pr13212.so requires
--- Comment #15 from tobi at gcc dot gnu dot org 2006-01-09 16:50 ---
Forgot to say: the validity check would then look like:
for (b = code->block: b != NULL; b = b->enclosing_block)
if (b == label->block)
/* valid GOTO */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
--- Comment #14 from tobi at gcc dot gnu dot org 2006-01-09 16:46 ---
Coming to think of it, I think that while your speedup would work, it would
probably be easier and even faster if we kept track of the enclosing blocks
while building the blocks and labels, so that the data structure w
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-09 16:34 ---
*** Bug 25726 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-09 16:34 ---
Yes it is.
*** This bug has been marked as a duplicate of 20239 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-09 16:33 ---
Isn't this PR20239?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25726
--- Comment #5 from lawless at spamcop dot net 2006-01-09 16:29 ---
Never mind. Your are correct. Got bit by the temporary object.
I'd turn that language feature off if I could.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25719
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-09 16:24 ---
Here is the testcase from the tar ball for us lazy people:
#include
#include
using namespace std;
int printit(const char * const str) {
return *str;
}
int main()
{
ostringstream ostr;
ostr << "test test
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-01-09 16:21
---
Fixed on 4.1 and mainline.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-09 16:19
---
Subject: Bug 25093
Author: eedelman
Date: Mon Jan 9 16:19:22 2006
New Revision: 109500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109500
Log:
fortran/
2005-01-09 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #3 from lawless at spamcop dot net 2006-01-09 16:15 ---
The string object in the test case does not die until the
'main' function is exited. The destructor is not called
before the 'return' statement, which is after the 'printit'
function call.
--
lawless at spamcop dot
--- Comment #24 from yanov at il dot ibm dot com 2006-01-09 16:15 ---
You might be right; Compiling the code below without Mustafa's patch to
cfgrtl.c we get the following ICE on Power5: powerpc-linux if SMS is enabled:
gcc -O -c -fmodulo-sched smaller_comb.c
smaller_comb.c: In funct
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-09 15:59 ---
What is the error message?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25726
--- Comment #19 from philb at filmlight dot ltd dot uk 2006-01-09 15:58
---
Verified fixed (against original source problem) in 4.0.3 20060105
--
philb at filmlight dot ltd dot uk changed:
What|Removed |Added
--
When I try to compile an empty tmp.i file, I have no problem doing it
under GNU/Debian Linux gcc-3.4 (GCC) 3.4.5 (Debian 3.4.5-1),
The same command whoever fails under Cygwin
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
and
MinGW gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, usin
--- Comment #5 from pluto at agmk dot net 2006-01-09 15:48 ---
(In reply to comment #4)
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21237
oops, I accidentally posted this link:(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724
--- Comment #4 from pluto at agmk dot net 2006-01-09 15:46 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21237
--
pluto at agmk dot net changed:
What|Removed |Added
Libtool is always invoked with -rpath /prefix/lib/sparcv9 option. When using
Sun ld (/usr/ccs/bin/ld), the option should be -R/prefix/lib/sparcv9. This
results in libraries and some executables not being able to find libraries they
depend on during runtime. It is possible that sparc-sun-* target
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-09 14:41 ---
Using
void foo(void);
int dcache_readdir(long long ll)
{
if (ll == 0)
foo();
}
the correct bit-twiddling is generated...
So it looks like a generic switch expand issue.
--
http://gcc.gnu.org/bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 14:38 ---
Confirmed, this is just a missed optimization and not a regression at best. If
the kernel is using long long on a 32bit target, it needs all support functions
including __cmpdi2.
--
pinskia at gcc dot gnu dot or
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-09 14:33 ---
This is no way critical at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The kernel for s390 (and ppc) currently drags in __cmpdi2 from libgcc with
the following reduced testcase even though s390 is supposed to have an 8
byte comparison opcode and archs such as i686 generate bit-twiddling for
this unsupported case (admittandly not from ifcvt, but from some define-expand
--- Comment #2 from Donald dot Sharp at prismtech dot com 2006-01-09 13:39
---
Created an attachment (id=10600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10600&action=view)
This is the second test file
This file also produces an internal compiler error on Solaris 9
--
ht
--- Comment #1 from Donald dot Sharp at prismtech dot com 2006-01-09 13:37
---
Created an attachment (id=10599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10599&action=view)
Compiling this file with gcc-3.4.5 on Solaris 9 produces an internal compiler
error.
--
http://gcc.
1 - 100 of 117 matches
Mail list logo
