At revision 146606 the following code
module vector_calculus
intrinsic :: dot_product, sqrt
contains
function len(r)
real, dimension(:), intent(in) :: r
real :: len
len = sqrt(dot_product(r,r))
end function len
end module vector_calculus
end
gives
pr36192_mod_red.f90:12.26:
--- Comment #2 from ubizjak at gmail dot com 2009-04-23 06:49 ---
Please report this bug to Debian first:
For Debian GNU/Linux specific bug reporting instructions,
see .
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from lasse-gccbug-2009 at mail dot plastictree dot net
2009-04-23 06:42 ---
(In reply to comment #4)
> Can you give the output of gcc -v?
>
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/package/host/localhost/sepbuilt/gcc41-4.1.2-01-03/src/unpack/gcc
--- Comment #21 from jakub at gcc dot gnu dot org 2009-04-23 06:28 ---
Created an attachment (id=17682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17682&action=view)
glibc-no-long-double-math.patch
I agree that even for __NO_LONG_DOUBLE_MATH we should provide *l prototypes
(cer
--- Comment #4 from pavel dot petrovic at gmail dot com 2009-04-23 06:06
---
Thanks! it works. I was confused by this document:
ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf which seems to
claim the opposite.
--
pavel dot petrovic at gmail dot com changed:
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-23 06:03 ---
GCC 4.4.0 compiled glibc 2.10 works just fine for me on x86_64, i586, i686,
powerpc and powerpc64.
Anyway, if you say GCC 4.3.3 compiled glibc 2.8 works and 4.4.0 compiled
doesn't, then please do a binary search betwe
--- Comment #1 from pletzer at txcorp dot com 2009-04-23 04:38 ---
Created an attachment (id=17681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17681&action=view)
source code reproducing problem
I apologize but I cannot produce *.i files with -save-temps:
[plet...@localhost tes
The attached code takes 20 mins to compile on a Linux/Fedora 9 box when using
-O optimization, but only 21 seconds when using -O0
[plet...@quartic cxxps]$ time g++ -O -ftime-report -fmem-report -c cxxps.cpp >&
stat.txt
real21m41.494s
user16m24.774s
sys 0m19.713s
[plet...@quartic cxxp
--- Comment #21 from d at teklibre dot com 2009-04-23 03:44 ---
(In reply to comment #20)
> It successfully compiles, links, and runs my project (ScreamingRabbitCode) at
> -O3 -mtune=core2 w/o the asm code in 17.397s. gcc 4.3.2 takes 17.865s. (both
> are best case times over several runs
--- Comment #20 from d at teklibre dot com 2009-04-23 03:29 ---
I got gcc 4.4 built with the 1 line patch.
It assembles my 24 operand function just fine (which had several errors in the
asm that I couldn't detect without assembling it - pushed out to my repo now -
it even gets through a
--- Comment #9 from kargl at gcc dot gnu dot org 2009-04-23 02:52 ---
(In reply to comment #8)
> Getting back to this. We have a problem of choices here. In format
> statements
> such as:
> WRITE (*,'(1PD24.15E4)') 1.0d0
>
> Currently gfortran allows an extension of an optional
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-04-23 01:51
---
Getting back to this. We have a problem of choices here. In format statements
such as:
WRITE (*,'(1PD24.15E4)') 1.0d0
Currently gfortran allows an extension of an optional comma separating format
specifie
--- Comment #4 from sega01 at go-beyond dot org 2009-04-23 01:10 ---
(In reply to comment #3)
> It might be better if you use gdb instead of using ltrace because those two
> programs don't give enough information on what is going on. This could be
> still a bug in Lua or even in glibc i
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-23 00:57 ---
It might be better if you use gdb instead of using ltrace because those two
programs don't give enough information on what is going on. This could be
still a bug in Lua or even in glibc itself but without a testcase
--- Comment #2 from sega01 at go-beyond dot org 2009-04-23 00:55 ---
(In reply to comment #1)
> There is not enough information here. Do you have a source to a program which
> fails with the new glibc compiled with 4.4?
>
Thank you for the quick response.
The sources for the applicat
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-23 00:45 ---
The reason why this happens is because FUNCTION_BOUNDARY is defined as just 32
for both arm and thumb mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
When I compile this erroneous C++ program
namespace n { const int c = 1; }
int foo() { return n:c; }
I get this:
foo.cc: In function int foo():
foo.cc:2: error: expected primary-expression before : token
foo.cc:2: error: expected ; before : token
foo.cc:2: error: expected primary-express
--- Comment #4 from jingyu at gcc dot gnu dot org 2009-04-23 00:34 ---
Add HANDLE_PRAGMA_PACK_PUSH_POP to arm.
Tests are done for both gcc trunk and gcc-4.4.
These two failures become pass.
Patch was submitted to trunk and gcc-4.4.
--
jingyu at gcc dot gnu dot org changed:
--- Comment #3 from jingyu at gcc dot gnu dot org 2009-04-23 00:31 ---
Subject: Bug 39781
Author: jingyu
Date: Thu Apr 23 00:31:13 2009
New Revision: 146634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146634
Log:
PR testsuite/39781
* config/arm/arm.h: Define H
For this erroneous C++ test case:
extern void f(char**);
int main(int argc, char** argv) { f(argv[]); }
g++ reports
foo.cc: In function int main(int, char**):
foo.cc:2: error: expected primary-expression before ] token
This is pretty good, but I question the use of the term "primary-express
--- Comment #1 from strictlymike at gmail dot com 2009-04-23 00:23 ---
Created an attachment (id=17680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17680&action=view)
Preprocessed source as stored by gcc after segfault
Sorry, forgot to attach this, in a hurry. Cheers.
--
h
I had gcc segfault compiling the 2.6.18 Linux Kernel retrieved from
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2.
The special details of my kernel configuration (-O0 and -ggdb3) probably play
into this, since I've never seen this error compiling Linux 2.6.18 before.
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-23 00:11 ---
*** Bug 39854 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-23 00:11 ---
*** This bug has been marked as a duplicate of 38987 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39854
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-23 00:09 ---
There is not enough information here. Do you have a source to a program which
fails with the new glibc compiled with 4.4?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from jingyu at gcc dot gnu dot org 2009-04-23 00:05 ---
Subject: Bug 39781
Author: jingyu
Date: Thu Apr 23 00:05:03 2009
New Revision: 146629
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146629
Log:
PR testsuite/39781
* config/arm/arm.h: Define H
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-22 23:55 ---
*** This bug has been marked as a duplicate of 35828 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-22 23:55 ---
*** Bug 39822 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:53 ---
Can you try this again, there were some Exceptions handling issues recently.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-22 23:41 ---
#ifdef __cplusplus
#define EXPORTCALL __attribute__((stdcall))
#else
#define EXPORTCALL
#endif
Is wrong, you need to use the same ABI for the function on both sides of the
call, that is either use stdcall on both
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-22 23:39 ---
Can you give the output of gcc -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39641
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:34 ---
How is the libraries build? While linking do you use -fprofile-arcs
-ftest-coverage?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from joseph at codesourcery dot com 2009-04-22 23:34
---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4
in libstdc++ not exported anymore
On Wed, 22 Apr 2009, dave at hiauly1 dot hia dot nrc dot ca wrote:
> > From glibc's perspective there is no suc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39609
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhan
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 23:25 ---
Fixed in 4.5.0:
cmpltsd %xmm0, %xmm1
movsd .LC1(%rip), %xmm2
xorpd %xmm0, %xmm0
andpd %xmm1, %xmm2
orpd%xmm2, %xmm0
ret
--
pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-22 23:23 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-22 23:23 ---
Subject: Bug 31499
Author: pinskia
Date: Wed Apr 22 23:22:53 2009
New Revision: 146628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146628
Log:
2009-04-22 Andrew Pinski
PR C/31499
* c-t
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-22 23:09 ---
This problem is harder than what is mentioned, I am going to close this as
won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-22
23:06 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
> Perhaps I wasn't as clear as I should have been. The glibc port for
> hppa has always been configured ne
--- Comment #19 from pinskia at gcc dot gnu dot org 2009-04-22 23:06
---
Fixed in 4.3.0 by the new register allocator (IRA).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from carlos at codesourcery dot com 2009-04-22 22:42
---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4
in libstdc++ not exported anymore
>> * Original submitter is incorrect, there has never been a
>> __signb...@glibcxx_3.4 symbol, and there should n
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-22 22:41 ---
Hmm, I think there is a regression here in 4.3 and above (since
tuplicafication) in that we don't vectorize even the ?2:1 loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21997
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-04-22
22:38 ---
Created an attachment (id=17679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17679&action=view)
Part two of fix
This renames the DEBUG macro to __GCJ_DEBUG throughout. It fixed the build in
my t
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-22 22:20 ---
We now get:
foo:
movl$1, %eax
movlg+4, %edx
testl %edx, %edx
jne .L3
movl4(%esp), %edx
cmplg, %edx
jb .L3
ret
.p2alig
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-22 22:10 ---
Fixed in at least 4.3.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-22 22:06 ---
Fixed so far for 4.4.1 and 4.5.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Kn
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-22 22:05 ---
ICEs since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143757
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-22 22:03 ---
Subject: Bug 39855
Author: jakub
Date: Wed Apr 22 22:02:54 2009
New Revision: 146622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146622
Log:
PR c/39855
* fold-const.c (fold_binary) : When op
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-22 22:02
---
Fixed in 4.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-22 21:58 ---
Subject: Bug 39855
Author: jakub
Date: Wed Apr 22 21:57:52 2009
New Revision: 146617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146617
Log:
PR c/39855
* fold-const.c (fold_binary) : When op
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-22 21:56 ---
This also happens in 189.lucas where it prevents propagating constant 1 array
strides to the access.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-22 21:56 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from jb at gcc dot gnu dot org 2009-04-22 21:37 ---
Having a shot at backporting, assigning to myself.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-22 21:32 ---
Actually this comes down to:
int f(int a, int c)
{
if (a) return a*c;
return 0;
}
It might be faster to use the branch rather than the multiple, I don't know and
I think it depends on the target.
--
http://
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-22 21:25
---
On the trunk we get:
f:
cmpb$1, 4(%esp)
sbbl%eax, %eax
notl%eax
andb8(%esp), %al
ret
With the default arguments on i686-linux-gnu.
With -march=i686:
f:
--- Comment #3 from ryancacophony at gmail dot com 2009-04-22 21:20 ---
(In reply to comment #2)
> This is likely because a PCH is used and is not included from the main .cpp
> file (but Melody.h). Try using -include note.h on the commandline to use
> PCHs.
> Including a PCH from not t
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-22 21:17 ---
I think this was fixed for GCC 4.4.0 with the IRA but I can't test right now
since the preprocessed source uses builtin functions which are no longer exist
in 4.4.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-22 21:12 ---
This has been fixed for awhile now, since at least 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-22 21:08 ---
Created an attachment (id=17678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17678&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
SPEC CPU 2006 453.povray ICEs compiling super.cpp with
> g++-4.4 -S -O3 -fomit-frame-pointer -msse3 -m32 -march=i586 super.ii
super.cpp: In function 'void pov::Superellipsoid_Normal(double*, pov::OBJECT*,
pov::INTERSECTION*)':
super.cpp:515: internal compiler error: in subst_stack_regs_pat, at
reg
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-22 21:05 ---
This has been fixed for a while now, at least since 4.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-22 20:58 ---
With the patch we have issues with %< and %> not being converted to quotes, I
am going to unassign myself for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from vmakarov at redhat dot com 2009-04-22 20:37 ---
Actually YARA did not have a rematerialization as IRA. Reload has a primitive
rematerialization of constant values.
Although about 5 years I did implemented a register pressure relief through
rematerialization which is
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-22 20:20 ---
Argh, attached wrong version of the patch, the arguments to omit_one_operand of
course need to be swapped. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39855
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-22 20:17 ---
Created an attachment (id=17677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17677&action=view)
gcc45-pr39855.patch
Fix I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39855
--- Comment #6 from vmakarov at gcc dot gnu dot org 2009-04-22 20:16
---
Subject: Bug 39762
Author: vmakarov
Date: Wed Apr 22 20:16:13 2009
New Revision: 146612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146612
Log:
2009-04-22 Vladimir Makarov
PR rtl-optimizatio
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-04-22 19:55 ---
Subject: Bug 39824
Author: rguenth
Date: Wed Apr 22 19:55:24 2009
New Revision: 146611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146611
Log:
2009-04-22 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-22 19:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0
--- Comment #19 from d at teklibre dot com 2009-04-22 19:48 ---
@Andrew: I agree with Jakub's point too, but don't believe merely doubling the
number of operands will hurt much. Am trying it against 4.3.2... it's building
as I write.
When I figure out how to safely build 4.4 I will loo
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-22 19:36 ---
This is likely because a PCH is used and is not included from the main .cpp
file (but Melody.h). Try using -include note.h on the commandline to use PCHs.
Including a PCH from not the toplevel source is not supporte
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-22
19:32 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
> * Original submitter is incorrect, there has never been a
> __signb...@glibcxx_3.4 symbol, and there sho
--- Comment #5 from dodji at gcc dot gnu dot org 2009-04-22 19:21 ---
Fixed in 4.3, 4.4 and 4.5.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dodji at gcc dot gnu dot org 2009-04-22 19:17 ---
Subject: Bug 39639
Author: dodji
Date: Wed Apr 22 19:17:18 2009
New Revision: 146610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146610
Log:
2009-04-22 Dodji Seketeli
gcc/cp/ChangeLog:
PR c+
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-22 19:16 ---
Subject: Bug 39639
Author: dodji
Date: Wed Apr 22 19:16:13 2009
New Revision: 146609
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146609
Log:
2009-04-22 Dodji Seketeli
gcc/cp/ChangeLog:
PR c+
--- Comment #2 from dodji at gcc dot gnu dot org 2009-04-22 19:13 ---
Subject: Bug 39639
Author: dodji
Date: Wed Apr 22 19:13:40 2009
New Revision: 146608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146608
Log:
2009-04-22 Dodji Seketeli
gcc/cp/ChangeLog:
PR c+
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #18 from hjl dot tools at gmail dot com 2009-04-22 19:03
---
(In reply to comment #6)
> Pinska: Actually, no. I started with the intrinsics and looked hard at what
> the
> code scheduler was doing before settling on rewriting this in inline
> assembly.
>
> The intrinsics
--- Comment #3 from gcc at breakpoint dot cc 2009-04-22 18:41 ---
Wasn't
# echo 'int main(void) { return 0; }' > file.c
not enough or did you overlook that part?
The -E output is pretty much the same, it is:
$ cat test.i
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
int main(void)
{
re
--- Comment #17 from aph at gcc dot gnu dot org 2009-04-22 18:40 ---
I agree with Jakub's point.
David, can you try instead of register operands using named register variables
instead? I think that may work, unless there is some other limit of which I'm
unaware.
--
http://gcc.gnu.
#include
int foo() {
puts("Hello world");
return 0;
}
int main() {
foo() << 30 << 2;
return (unsigned)foo() >> 16 >> 16;
}
% gcc test.c
% ./a.out
%
--
Summary: Shift optimization discards operands' side effects
Product: gcc
Version: 4.3.3
--- Comment #16 from carlos at codesourcery dot com 2009-04-22 18:33
---
So what is required to close this issue?
* Original submitter is incorrect, there has never been a
__signb...@glibcxx_3.4 symbol, and there should not be one now?
* glibc on hppa-linux-gnu has never had a __signb
--- Comment #16 from d at teklibre dot com 2009-04-22 18:30 ---
@Jakub/Andrew:
max_recog_operands =
MIN(FIRST_PSEUDO_REGISTER*2,SOME_SANE_VALUE_DERIVED_FROM_SMASHING_THE_STACK_ON_IA64)
; // ?
I certainly am not in a position to make a one line change to gcc and test it
on ia64 or other
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-04-22 18:03
---
(In reply to comment #13)
> That old huh? Given that I/O operands take two virtual regs... methinks that
> the history of this is more of an x86ism...
>
> and symbolic register parameters date back to gcc 3.1
--- Comment #14 from d at teklibre dot com 2009-04-22 18:00 ---
@Jakub:
I'm going to build this thing today. (once I figure out the best way, and I
figure it will take a while, even so) Are there any specific tests I should run
to check for performance issues? I expect any stack overflo
--- Comment #13 from d at teklibre dot com 2009-04-22 17:55 ---
@Andrew
>I suspect the reason the limit is 30 is that when that code was written the
>largest register set was 32 registers, 2 of which were reserved to the
>implementation. Inline asm hasn't kept up with the hardware.
Tha
--- Comment #12 from jakub at gcc dot gnu dot org 2009-04-22 17:51 ---
That's not going to fly very well e.g. on ia64:
config/ia64/ia64.h:#define FIRST_PSEUDO_REGISTER 334
then we have automatic arrays like:
char operands_match[MAX_RECOG_OPERANDS][MAX_RECOG_OPERANDS];
etc., many of them
--- Comment #11 from aph at gcc dot gnu dot org 2009-04-22 17:47 ---
I suspect the reason the limit is 30 is that when that code was written the
largest register set was 32 registers, 2 of which were reserved to the
implementation. Inline asm hasn't kept up with the hardware.
--
ht
--- Comment #10 from aph at redhat dot com 2009-04-22 17:33 ---
Subject: Re: 16 symbolic register names generates error:
more than 30 operands in 'asm'
> 0) I will build gcc-4.4 and try that. I will also make the 1 line patch to it
> to try increasing the number of asm params, and tr
--- Comment #1 from ryancacophony at gmail dot com 2009-04-22 17:31 ---
Created an attachment (id=17676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17676&action=view)
ii file as requested
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39854
--- Comment #9 from d at teklibre dot com 2009-04-22 17:24 ---
Pinskia:
It is going to take me a long time to address these issues piecemeal, so...
0) I will build gcc-4.4 and try that. I will also make the 1 line patch to it
to try increasing the number of asm params, and try that. I
--- Comment #15 from paolo dot carlini at oracle dot com 2009-04-22 17:23
---
In order to make progress on the locale bits while following the usual
strategies of v3, we need some support from the underlying glibc, not
forthcoming, AFAIK...
--
paolo dot carlini at oracle dot com cha
--- Comment #3 from sandmann at daimi dot au dot dk 2009-04-22 17:03
---
Why not? If not using the return value is a bug, then it's also a bug if it
isn't used after being passed through a statement expression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808
--- Comment #8 from alexey dot zaytsev at gmail dot com 2009-04-22 16:57
---
Created an attachment (id=17675)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17675&action=view)
The gcc 4.3.3 testcase.
Sorry, wrong file.
--
alexey dot zaytsev at gmail dot com changed:
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
1 - 100 of 210 matches
Mail list logo
