--- Comment #14 from bonzini at gnu dot org 2007-06-25 07:01 ---
wrong bug marked as duplicate... reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** This bug has been marked as a duplicate of 30563 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** Bug 30537 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from bonzini at gnu dot org 2007-06-25 07:03 ---
... to close as fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|REOPENED
I believe this is not what gcc was supposed to do.
The code below produces a segmentation fault. I have written the reason of the
segmentation fault in a comment block toward the end of the code below.
And I don't think this is how gcc is supposed to behave.
#include
#include
typedef struct ch
Greetings,
Please consider the scenario below:
Since i'm using "-ffunction-sections and -fdata-sections", my segments are put
int (.text.*) and (.data.*) instead of just (.text) and (.data). This results
in arm-elf-size outputs as follows:
When I use 'arm-elf-size -B' I get:
arm-elf-size -B Outp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 07:22 ---
b+4096 is the same as (typeof(b)) ( ((char*)b) + 4096 * sizeof(*b) ) which is
not you wanted.
You should write it as:
(chunk*) ( ((char*)b) + 4096+sizeof(chunk) )
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 07:29 ---
The size program is not part of GCC but part of binutils, report this issue to
them: http://www.sourceware.org/bugzilla/ .
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ftwilliam at gmail dot com 2007-06-25 07:39 ---
(In reply to comment #1)
> b+4096 is the same as (typeof(b)) ( ((char*)b) + 4096 * sizeof(*b) ) which is
> not you wanted.
>
> You should write it as:
> (chunk*) ( ((char*)b) + 4096+sizeof(chunk) )
>
Thank you very m
--- Comment #2 from fink at racemouse dot net 2007-06-25 07:57 ---
(In reply to comment #1)
> The size program is not part of GCC but part of binutils, report this issue to
> them: http://www.sourceware.org/bugzilla/ .
>
You're ofcourse right. I wasn't thinking. Please delete this repo
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-25 08:02 ---
> Seen this before
> I think this is the same bug as something I filed.
I found it (PR31301) after looking for closed bugs; it was marked as duplicate
of
PR31301.
*** This bug has been marked as a duplicate of
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-25 08:02 ---
*** Bug 32489 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
--- Comment #28 from rearnsha at gcc dot gnu dot org 2007-06-25 08:06
---
(In reply to comment #27)
> As for the code size regression, Richard E., have you had a chance to identify
> a specific CSiBE file that expands, so that Zdenek can look at that?
>
There were a number of files t
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-25 09:53 ---
Could you try it with gfortran 4.3, available from:
http://gcc.gnu.org/wiki/GFortranBinaries
As this is fixed in 4.3 and it is neither a regression nor a wrong-code bug, I
don't think we will fix it for 4.2 due to la
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror
--disable-libunwind-exceptions --disabl
--- Comment #1 from malitzke at metronets dot com 2007-06-25 10:15 ---
Created an attachment (id=13782)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13782&action=view)
standrd *.i file
drivers/acpi/ec.c:124: sorry, unimplemented: inlining failed in call to
'acpi_ec_write_cmd': re
> cat bug.ii
__attribute__((always_inline)) void f1() {}
__attribute__((always_inline)) void f2(char) {}
void f3() { f1(); f2(0); }
> g++ bug.ii
bug.ii: In function void f3():
bug.ii:2: sorry, unimplemented: inlining failed in call to void f2(char):
recursive inlining
bug.ii:3: sorry, unimplem
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-25 10:53 ---
Might be related to (dupe of?) PR21023?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32487
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-25 10:54 ---
Ups, meant PR21203 ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from namolaru at il dot ibm dot com 2007-06-25 11:17 ---
(In reply to comment #5)
> This bug should be assigned to Mircea Namolaru <[EMAIL PROTECTED]>. I have
> sent him mail asking that he get a proper bugzilla id.
> ==
> The underlying pr
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-06-25 11:43 ---
The problem of the cyclic definition is (more or less), the same described in
PR24886, isn't it? E.g. replace
implicit character(len(ouch)) (x)
implicit character(len(x)+1) (y)
intent(in) x,y
by
character(
--- Comment #3 from kazu at gcc dot gnu dot org 2007-06-25 11:50 ---
Richard Sandiford says that this bug is probably what
MODE_INDEX_REG_CLASS is intended to fix. Unfortunately, the patch to
add MODE_INDEX_REG_CLASS
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00782.html
has been r
--- Comment #29 from mmitchel at gcc dot gnu dot org 2007-06-25 11:38
---
Richard --
Thank you for refreshing my memory as to the code-size issue and putting the PR
numbers in the audit trail here.
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 11:33 ---
A dupe of 31306?
Here, I don't get an endless loop but an ICE (20070522).
*** This bug has been marked as a duplicate of 31306 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-25 11:33 ---
*** Bug 32488 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31306
--- Comment #2 from kazu at gcc dot gnu dot org 2007-06-25 11:44 ---
Here is the command line for configure.
/scratch/kazu/ce/2007-06-23-1351-0/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-elf
--enable-shared --enable-threads --disable-libm
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 12:16 ---
You need to learn this is not a bug.
if you do:
long long f(long long a, long long b)
{
return a/b;
}
You will get a reference to divdi3. There is no bug here except inside the
lInux kernel.
Linus is wrong in s
--- Comment #2 from eres at il dot ibm dot com 2007-06-25 12:31 ---
I would like to be assigned to this bug.
Thanks,
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
On Fri, 18 May 2007, Andrew Morton wrote:
>
> gcc-4.3 appears to have cunningly converted this:
Very cunning indeed.
Considerign that gcc converted straightforward and simple code to a total
disaster with a 64-bit divide, I'd call it a gcc bug.
> into a divide-by-10 operation, so it em
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 12:37 ---
Huh? This bug is invalid. Linus is incorrect. Please read all the emails
including Segher's. Note GCC is not ignorining unlikely at all (except maybe
for a code size issue).
--
pinskia at gcc dot gnu dot org
--- Comment #31 from samjnaa at gmail dot com 2007-06-25 12:58 ---
Just mentioning: printf() and std::cout need to be updated if the binary values
are also to be *output*. Any ideas on how or where that is to be done?
Thanks.
--
samjnaa at gmail dot com changed:
What
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-25 12:53 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRME
--- Comment #5 from malitzke at metronets dot com 2007-06-25 12:50 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-25 12:33 ---
Also by the way the divide is only inside the unlikely part of the code so it
will not slow down the common code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
--- Comment #3 from malitzke at metronets dot com 2007-06-25 12:35 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 12:53 ---
What is there to ping?
The problem again is in the Linux kernel.
Please read http://lkml.org/lkml/2007/5/18/371 as I mentioned before.
Linus is incorrect. GCC is not ignoring unlikely as the divide is only
reac
--- Comment #8 from malitzke at metronets dot com 2007-06-25 13:03 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #32 from j at uriah dot heep dot sax dot de 2007-06-25 13:38
---
(In reply to comment #31)
> Just mentioning: printf() and std::cout need to be updated if the
> binary values are also to be *output*. Any ideas on how or where
> that is to be done?
That would be a library i
___ added for emphasis
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror
--disable-libunwind-exceptions --disable-checking --disable-decimal-f
--- Comment #1 from schwab at suse dot de 2007-06-25 13:58 ---
__udivdi3 is not a builtin. It is a libcall that implements 64 bit division for
architectures that don't have support for it in the ISA.
--
schwab at suse dot de changed:
What|Removed |
Configure command:
/n/12/rask/src/all/configure --target mipsisa64-unknown-elf
--with-newlib--enable-sim --disable-gdb --disable-nls
Build fails with this:
libtool: compile: /home/rask/build/gcc-mipsisa64-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-mipsisa64-unknown-elf/./gcc/ -nostdinc
-B/hom
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-25 13:06 ---
Now you are getting annoying. Richard closed the bug already too. Please read
my whole comments and Segher's. Nobody has really looked into the code
produced except for the fact GCC is emitting a call to divdi3 wh
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 14:19 ---
Try this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01800.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |eres at il dot ibm dot com
|dot org
Configure string:
$ /n/12/rask/src/all/configure --target=powerpc-unknown-eabisim --with-newlib
--enable-sim --disable-libffi --disable-gdb --disable-nls
Build fails:
libtool: compile: /home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/xgcc
-B/home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 14:49 ---
boehm-gc should not be enabled for the embedded ppc. In fact all of libjava
should most likely not be enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32498
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-25 14:51 ---
I have a fix for this that needs a bit of cleaning up - will submit tonight.
For some reason, gfc_simplify_repeat denies even the possibility of character
literal arguments - it's not even a question of a failing atte
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-25 14:56 ---
I'd better take this on since I have had my patch for it accepted!
Thanks for the report, Michael.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
NetBSD autobuild cluster is a mixture of i386 and amd64 machines, and
when sh3 builds hit an amd64 build host the build fails when
cross-compiling native /usr/bin/gcc for sh3 target.
/usr/nb/tools/bin/shle--netbsdelf-gcc ... -c insn-emit.c
insn-emit.c: In function 'gen_mshfhi_l_di':
insn-emit.c:54
I noticed that the libstdc++ testsuite fails to run on mips-sgi-irix6.5 and
mips-sgi-irix5.3::
ERROR: tcl error sourcing
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not link libtestc++.a
while executing
"error "could not link libtestc++.a""
(procedure
Hello,
On the FreeBSD -CURRENT mailing lists a user of the upcoming FreeBSD release
discovered a bug in the GCC that is shipped with the base system (4.2.0
20070514). This bug causes the amount of iterations in a loop to be limited to
the range of an array used in a single part of the loop. When t
--- Comment #1 from ed at fxq dot nl 2007-06-25 15:35 ---
Created an attachment (id=13783)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13783&action=view)
C source code which triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #2 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13784&action=view)
GCC intermediate code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #3 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13785&action=view)
Generated assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 15:45 ---
i.10_10: [5, 12]
D.2123_11 = i.10_10 - 7;
D.2123_11: [0fffa, +INF]
I think this might have been already fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |tree-optimizat
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 15:46 ---
This works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #6 from ed at fxq dot nl 2007-06-25 15:50 ---
Thanks for confirming this. Will the fix in question be part of 4.2.1 as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- Comment #1 from hjl at lucon dot org 2007-06-25 16:07 ---
Revision 125997 also fails at -O2 on Linux/x86-64 and the 4.2 patch
for PR 30252 fixes this bug for 4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #7 from ache at nagual dot pp dot ru 2007-06-25 16:08 ---
Still not works with
gcc version 4.2.1 20070614 prerelease [FreeBSD]
try
cc -O2 foo.c; ./a.out
and
cc -O foo.c; ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
I recognize that because of limits.h and float.h the C compiler has to
implement
functions or in-line code to make available ways to offer something to provide
operations for types referenced via freestanding headers. However, the C
specification says nothing about ___ramming down my throat___ ope
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-25 16:31 ---
There is no builtin udivdi3. This is a runtime library function that get's
called
if the processor does not support this instruction (Unsigned DIVide for DImode
with 3 arguments) natively.
--
rguenth at gcc dot
--- Comment #2 from malitzke at metronets dot com 2007-06-25 16:38 ---
I want to reiterate that I am as little a linux-kernel maintainer as I am a GCC
maintainer. The linux-kernel is in excellent hands and does not need me. Out of
sheer laziness and/or intellectual poverty the example gi
--- Comment #3 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
--- Comment #4 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-25 16:41 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenth at
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 16:44 ---
This is related to or really a dup of bug 4417.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
This was reported a long time ago as PR 16470, if you think otherwise you need
to go back and talk to the C standards committee. What the issue here is you
are using long long and there is no hardware support for it
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.1.2 4.2.0
--- Comment #8 from ed at fxq dot nl 2007-06-25 16:52 ---
(In reply to comment #0)
> When the size of the loop is increased (in the attached example, to 6 or
> higher) the problem disappears.
This should read:
> When the size of the array is increased (in the attached example, to 6 or
--- Comment #7 from malitzke at metronets dot com 2007-06-25 16:52 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16470
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
Who are you pinging? Because if you read the bug report I pointed to, you will
see that this was already decided this is not a bug a long long time ago.
Please read all of my comments instead of just reopening the
--- Comment #10 from malitzke at metronets dot com 2007-06-25 17:01 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
CC|rguenth at g
--- Comment #9 from malitzke at metronets dot com 2007-06-25 17:02 ---
Read the standard
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-25 17:08
---
You missed:
> Any library facilities available to a freestanding
> program, other than the minimal set required by clause 4, are
> implementation-> defined.
This is from C99/5.1.2.1.
And C99/4/6 says:
The two fo
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-25 17:12
---
The standard is clear that long long is fully supported by freestanding
programs which means that the implementation needs to support it. GCC supports
it by providing libgcc.a support library.
4/6:
The two forms o
--- Comment #2 from nemet at gcc dot gnu dot org 2007-06-25 17:21 ---
Subject: Bug 32495
Author: nemet
Date: Mon Jun 25 17:21:46 2007
New Revision: 125998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125998
Log:
PR libfortran/32495
* runtime/backtrace.c (local_
--- Comment #3 from nemet at gcc dot gnu dot org 2007-06-25 17:22 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from simon_baldwin at yahoo dot com 2007-06-25 17:24 ---
Indeed it can -- thanks for the reminder. Marking as FIXED.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #8 from simon_baldwin at yahoo dot com 2007-06-25 17:26 ---
Resolved by revision 122434.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-06-25
17:38 ---
Subject: Re: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code
despite -fPIC
hjl at lucon dot org writes:
> --- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 ---
> On Linux,
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spark at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |zadeck at gcc dot gnu dot
|dot org
--- Comment #30 from spark at gcc dot gnu dot org 2007-06-25 18:13 ---
The following patch will essentially disable the warning
for template instantiations in the anonymous namespace.
Index: gcc/cp/decl2.c
===
--- gcc/cp/de
--- Comment #1 from ro at gcc dot gnu dot org 2007-06-25 18:16 ---
I forgot to mention: this is a regression from the 4.2 branch.
Besides, the same error happens with gas 2.17 and the native assembler.
With both gas and gld 2.17, the problem does not occur, but all java programs
tail t
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 31494
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126000
Log:
2007-06-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 32464
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126000
Log:
2007-06-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #11 from pault at gcc dot gnu dot org 2007-06-25 18:30 ---
Fixed on trunk.
Thanks for the report, Harald.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from patchapp at dberlin dot org 2007-06-25 18:50 ---
Subject: Bug number PR 32130
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01856.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-25 18:51 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01858.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
--- Comment #4 from patchapp at dberlin dot org 2007-06-25 19:03 ---
Subject: Bug number PR32359
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01222.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-25 19:29
---
I cannot recreate this bug.
I have tried building both 32 and 64 bit compilers with both revision 125972
and the current 126001.
All of my machines are suse, so if this requires someone elses abi, I am out of
The following subroutine has an orphaned OpenMP "do" directive (i.e. no
enclosing "parallel" region in the program unit) containing a reduction clause.
gfortran reports an error involving the scope of the reduction variable and
fails to compile the code. I believe this code is valid. For referen
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01172.html (PR 32239):
"At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant integer
power
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-25 19:52 ---
"At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 19:56 ---
> Additionally: It would be great if there would be a variant for long integers
> (8 byte integers) and long long (16 byte integers) as PR32239 could only use
> __builtin_powi for int4 and not for int8 or int16.
Actu
1 - 100 of 149 matches
Mail list logo
