Hello,
I am unable to see the expected performance gain using vectorizatio on
powerPC using Linux Suse.
I've prepared a simple test and compiled it once with vectorization and once
without the vectorization flags. I'd appriciate if someone could point me as to
what Im doing wrong here.Bellow
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35116
--- Comment #21 from ismail at pardus dot org dot tr 2008-02-07 09:05
---
-fno-tree-reassoc fixes the problem here,
With -fno-tree-reassoc :
vect-iv-9.c:15: note: === vect_mark_stmts_to_be_vectorized ===
vect-iv-9.c:10: note: vectorized 1 loops in function.
vect-iv-9.c:26: note:
--- Comment #16 from jpr at csc dot fi 2008-02-07 09:19 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
Well, the internal write case is anyway a regression introduced by this
patch
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html
---
--- Comment #20 from ubizjak at gmail dot com 2008-02-07 09:01 ---
From the logs:
tree-reassoc in failed case transforms:
D.2020_7 = a[i_17];
D.2021_8 = D.2020_7 + i_17;
s_9 = D.2021_8 + s_18;
to:
D.2020_7 = a[i_17];
D.2021_8 = s_18 + i_17;
s_9 = D.2021_8 + D.2020_7;
--- Comment #22 from ubizjak at gmail dot com 2008-02-07 09:37 ---
(In reply to comment #21)
-fno-tree-reassoc fixes the problem here,
So, what happens to reassociation that sometimes produce (working case):
Rank for D.2002_7 is 327681
Transforming D.2002_7 + i_18 into i_18 +
--- Comment #1 from dominiq at lps dot ens dot fr 2008-02-07 09:50 ---
Confirmed on i686-apple-darwin9:
[ibook-dhum] /Users/dominiq% /opt/gcc/gcc4.3w/bin/g++
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/vector13.C
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/vector13.C:6: internal
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-02-07 10:20
---
qsort with sort_by_operand_rank is unstable, as it may return zero. But, IMHO
the vectorizer should simply recognize the other pattern as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #1 from tim at klingt dot org 2008-02-07 10:22 ---
Created an attachment (id=15113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15113action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35118
On i686-apple-darwin9, g++.dg/template/spec35.C fails for
FAIL: g++.dg/template/spec35.C scan-assembler .glob(a|)l[\t ]*_Z2f2IfEvT_
FAIL: g++.dg/template/spec35.C scan-assembler .weak[\t ]*_Z2f2IiEvT_
A quick look to the assembly shows that the regular expressions should be
something like
--- Comment #67 from olga at gcc dot gnu dot org 2008-02-07 10:26 ---
(In reply to comment #66)
I looked wo_prof_global_var.c. The test passes with the above options.
The floating point convert operations look similar to those with
-fipa-struct-reorg. However, there's just one
gcc crashes with an ICE, when generating code with debugging information. if
the flag -g is omitted, the code compiles fine ...
gcc is invoked like this:
gcc-4.2 -v -save-temps -DNDEBUG -D_PTHREADS -D_THREAD_SAFE -D_REENTRANT
-D_POSIX_SOURCE -march=i686 -O -Wfatal-errors -I../../Demo
--- Comment #13 from bonzini at gnu dot org 2008-02-07 10:09 ---
when was this approved? I think I have a better patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35049
I see the following failure while compiling vect-64.con power:
unrecognizable insn:
(insn 129 337 130 5
/home/razya/mainline_r131741/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:23
(parallel [
(set (reg:V4SI 241 [ vect_cst_.61 ])
(reg:V4SI 315))
(unspec [
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from eyal at geomage dot com 2008-02-07 10:36 ---
Yes the loop is vectorized. What do you mean by memory bound? dont you think
that vectorization can help here? I see around 20% performance gain in the real
application.
Bellow is the compiler output:
Eyal.cpp:34: note:
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-07 10:40 ---
That is PR 23383.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35117
--- Comment #5 from eyal at geomage dot com 2008-02-07 10:43 ---
(In reply to comment #3)
I think this is a dup of another bug I filed with respect of the builtin
operator new that getting the malloc attribute.
Are you refering to using malloc instead of new?
using malloc didnt make
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-07 10:43 ---
PR 34930#3 has the best information on what is going wrong. As I mentioned in
that, I think it is really a bug in instantiate_virtual_regs_in_insn which is
seperating the memory load from the other instruction.
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-02-07 10:43 ---
*** Bug 35120 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from irar at il dot ibm dot com 2008-02-07 10:53 ---
(In reply to comment #2)
Yes the loop is vectorized.
...
Eyal.cpp:34: note: created 9 versioning for alias checks.
Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition
The vectorizer created runtime checks
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-07 10:37 ---
I think this is a dup of another bug I filed with respect of the builtin
operator new that getting the malloc attribute.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-07 10:29 ---
The testcase looks completely memory bound. Does the compiler tell you it
does vectorization at all? Have you tried without -fprefetch-loop-arrays
(with todays HW prefetchers and the simple access patterns it's
ld reports this problem when finds undefined sysmbols.
This has been reported in 2006. Please see the link below:
http://arc-linux.org/pipermail/arc-gnu-tools/2006q2/000202.html
Is there a fix for that ? Can you suggest a workaround if not.
--
Summary: Misleading linker messages -
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-07 11:00 ---
If that is what other testcases do, then yes, this would be appreciated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-07 11:03 ---
Well ld is not part of GCC but rather the binutils project or is provided with
your OS. So you should be reporting it to them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from eyal at geomage dot com 2008-02-07 11:06 ---
(In reply to comment #6)
(In reply to comment #2)
Yes the loop is vectorized.
...
Eyal.cpp:34: note: created 9 versioning for alias checks.
Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition
The
GCC version:
$ ppu-gcc -v
Using built-in specs.
Target: ppu
Configured with: ../toolchain/gcc/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --with-as=/usr/bin/ppu-as
--with-ld=/usr/bin/ppu-ld --enable-threads --with-system-zlib
--disable-checking --enable-__cxa_atexit
--- Comment #22 from belyshev at depni dot sinp dot msu dot ru 2008-02-07
11:36 ---
(In reply to comment #21)
No new failures with this patch and two tests failed previously
(gcc.c-torture/compile/pr33855.c and gcc.dg/torture/fp-int-convert-timode.c)
did PASS:
The test case produces the following output on both 4.2.3 and 4.2.2; works fine
under 4.3-20080201
---
[EMAIL PROTECTED] bugtest]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.3/configure --prefix=/usr/local/gcc42
--- Comment #1 from sfilippone at uniroma2 dot it 2008-02-07 12:02 ---
Created an attachment (id=15114)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15114action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35123
--- Comment #2 from pcarlini at suse dot de 2008-02-07 12:07 ---
Just wanted to add that we are also providing a tr1/cmath, conforming to the
TR1 specifications, which indeed makes available std::tr1::log2, and also, in
the forthcoming 4.3.0, std::log2, as part of cmath, enabled in the
--- Comment #4 from ian dot rogers at manchester dot ac dot uk 2008-02-07
12:10 ---
There are two improvements described here:
1) avoid synchronization by the use of StringBuilder rather than StringBuffer
this is some what trivial and has largely been carried out in the Classpath
--- Comment #8 from eyal at geomage dot com 2008-02-07 12:16 ---
Hi Ira,
Here is the compiler output for the real code.
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86651_134 and *D.8_160
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check
--- Comment #2 from dominiq at lps dot ens dot fr 2008-02-07 12:21 ---
If that is what other testcases do, then yes, this would be appreciated.
I am not sure to understand the sentence. What I can do is test the proposed
regular expressions on Darwin9and see if the failures
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-07 12:30
---
Created an attachment (id=15115)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15115action=view)
Annotated profile
I am attaching dump with profile read in. It shows the hot spots in
longest_match at least:
The method _alloca assemble implementation is written that way, that it does
not return the stack pointer. I just reserves and probes the stack space.
The MSVCRT variant declares it as a synonym for POSIX alloca().
Here are three problems by the gcc variant:
1) The stack pointer isn't returned in
--- Comment #24 from ubizjak at gmail dot com 2008-02-07 12:39 ---
It happens that we already have specialization to detect reduction in
rewrite_expr_tree:
--cut here--
The alternative we try is to see if this is a destructive
update style statement, which is like:
b =
--- Comment #10 from eyal at geomage dot com 2008-02-07 12:58 ---
(In reply to comment #9)
(In reply to comment #8)
{
float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
*m_nSamples);
float *pTempSum2Phase_Temp_cre_angle = (float*) malloc
--- Comment #25 from ismail at pardus dot org dot tr 2008-02-07 12:43
---
Uros you rock! That patch fixes the problem for me, thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #9 from irar at il dot ibm dot com 2008-02-07 12:54 ---
(In reply to comment #8)
{
float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
*m_nSamples);
float *pTempSum2Phase_Temp_cre_angle = (float*) malloc (sizeof(float)
*m_nSamples);
--- Comment #26 from ubizjak at gmail dot com 2008-02-07 12:56 ---
Testing the patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from irar at il dot ibm dot com 2008-02-07 13:04 ---
(In reply to comment #10)
Is there some pragma or a coding convention I can use to make the compiler
understant those pointers have nothing to do with each other?
There is __restrict__, but it is useful only for
--- Comment #12 from eyal at geomage dot com 2008-02-07 13:07 ---
(In reply to comment #11)
(In reply to comment #10)
Is there some pragma or a coding convention I can use to make the compiler
understant those pointers have nothing to do with each other?
There is __restrict__, but
--- Comment #14 from bonzini at gnu dot org 2008-02-07 13:11 ---
posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html
--
bonzini at gnu dot org changed:
What|Removed |Added
i compiled the following code on
Red Hat Linux Enterprise AS Realease 4
Kernel 2.6.9-5 Elsmp
and the code was compiled successfully and was running.
//I dont know how this code is working.
#includeiostream
using namespace std;
int main()
{
int size;
int arr[size];
coutEnter
--- Comment #13 from irar at il dot ibm dot com 2008-02-07 13:22 ---
CC'ing Daniel and Diego, maybe they can help with the alias analysis issues.
--
irar at il dot ibm dot com changed:
What|Removed |Added
[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/execute/*.c
gcc.c-torture/execute/pr7284-1.c:/* { dg-options -std=c89 } */
gcc.c-torture/execute/wchar_t-1.c:/* { dg-options -finput-charset=utf-8 } */
[EMAIL PROTECTED] testsuite]$
But those dg-options are ignored since
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-07 15:22 ---
VLA in C++ is an extension, if you use -pedantic, you will get an error.
Also VLA uses the value at the time at definition and no other value after
wards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35125
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-07 15:16 ---
I can also confirm that
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html
does _not_ fix the problem. We still ICE with
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/ext/vector13.C:6: internal
--- Comment #3 from sfilippone at uniroma2 dot it 2008-02-07 14:54 ---
(In reply to comment #2)
gfortran 4.1 errors with
In file t.f90:3
integer, allocatable :: md(:), g2l(:)
1
Error: Attribute at (1) is not allowed in a TYPE definition
The failure
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-02-07 18:03
---
*** Bug 33205 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-07 18:03 ---
Ok, that's quite likely.
*** This bug has been marked as a duplicate of 33887 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janis at gcc dot gnu dot org 2008-02-07 18:21 ---
I talked to Steve Munroe about the ABI issues. We determined that for
powerpc*-linux, vector types that cannot be passed in vector registers should
be passed as aggregates according to the relevant ABI (32-bit or
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-07 19:56 ---
Created an attachment (id=15117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15117action=view)
Patch
Bootstrapped with --enable-languages=all and regression tested on
x86_64-unknown-linux-gnu
--
manu at gcc
-pedantic converts enumerators to 'int', while without -pedantic they are
handled as-is.
--
Summary: -pedantic changes code-generation for unsigned
enumerators
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity:
--- Comment #40 from dave at genussoft dot com 2008-02-07 19:39 ---
I am trying to use g++ 4.0.0 on AIX 5.3 and have run into this problem and also
the problem reported in bug 18257. What recommendation do you have for using
g++ on AIX? Should I go back to an earlier version, or has
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-02-07 19:06 ---
Fixed.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-07 19:04 ---
Subject: Bug 35115
Author: dgregor
Date: Thu Feb 7 19:03:40 2008
New Revision: 132173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132173
Log:
2008-02-06 Douglas Gregor [EMAIL PROTECTED]
*
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-07 20:50 ---
Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
earlier versions.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-07 20:49 ---
Subject: Bug 32754
Author: manu
Date: Thu Feb 7 20:48:24 2008
New Revision: 132175
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132175
Log:
2008-02-07 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-02-07 19:52 ---
*** Bug 35126 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-07 20:34 ---
*** This bug has been marked as a duplicate of 15236 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-07 20:34 ---
*** Bug 35129 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-07 20:19 ---
Sorry for the delay, this seems to have fallend through bugzilla's cracks.
GCC 3.3.1 is not supported anymore. Can you reproduce the bug in a recent
release like GCC 4.2.3 or preferably in GCC 4.3?
Thanks for the
--- Comment #32 from ghazi at gcc dot gnu dot org 2008-02-07 19:14 ---
Jason - Should the fix for PR28834 (AKA PR29436) be backported to 4.2/4.1?
I still see errors from mayalias-2.c on 4.2. (4.1 doesn't have the testcase,
but I suspect it still has the bug.)
--
ghazi at gcc dot
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-07 18:59 ---
This is fallout from my comptypes patch.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-07 18:05 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rth at gcc dot gnu dot org 2008-02-07 17:46 ---
Subject: Bug 33410
Author: rth
Date: Thu Feb 7 17:45:24 2008
New Revision: 132171
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132171
Log:
PR rtl-opt/33410
* config/alpha/alpha.c
--- Comment #6 from janis at gcc dot gnu dot org 2008-02-07 17:32 ---
A regression hunt on powerpc-linux showed that the test starts passing with:
http://gcc.gnu.org/viewcvs?view=revrev=131823
r131823 | rguenth | 2008-01-25 12:06:31 + (Fri, 25 Jan 2008)
That's a fix for
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-02-07 17:24 ---
Could somebody check the memory leakage for me, please?
type :: a
integer, allocatable :: i(:)
end type a
type(a) :: x, y
x = a ((/ 1,2,3 /))
! y = a (x%i(1:3)) ! ok
! y = a (x%i(1:))!
--- Comment #6 from michael dot meissner at amd dot com 2008-02-07 17:22
---
Subject: RE: Adding 4 more tree codes causes a crash in
building libstdc++ pre-compiled headers
The problem is there are two different vector shifts. There is vector
shift by a scalar amount (each element
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-02-07 16:36 ---
This is fixed by the call frequency patch on mainline.
.L2:
cvtsi2ss(%ebx,%eax,4), %xmm0
addl$1, %eax
cmpl$1000, %eax
mulss %xmm2, %xmm0
addss %xmm0, %xmm1
--- Comment #4 from hjl dot tools at gmail dot com 2008-02-07 15:55 ---
Can we move them into gcc.dg/torture?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #19 from Jerry_V_DeLisle at rl dot gov 2008-02-07 15:54 ---
Writing to an internal unit is nothing more than a fancy (formatted)
assignment. Each thread allocates its own unit structure. Its not like file
I/O where threads are accessing a common shared resource.
I should
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-07 15:53 ---
My point is those dg-options aren't applied to the testcases. We should
either remove them or make sure that they are used.
--
hjl dot tools at gmail dot com changed:
What|Removed
[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/compile/*.c | grep O
gcc.c-torture/compile/20031125-1.c:/* { dg-options -O2 } */
gcc.c-torture/compile/20031125-2.c:/* { dg-options -O2 } */
gcc.c-torture/compile/20031203-1.c:/* { dg-options -O2 } */
gcc.c-torture/compile/acc1.c:/* {
--- Comment #4 from bonzini at gnu dot org 2008-02-07 15:19 ---
Indeed. I developed my 35049 patch in an old check-out (to avoid conflicts
with Doug's patch), but after updating the tree it fails for me too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35113
--- Comment #7 from pault at gcc dot gnu dot org 2008-02-07 15:19 ---
Created an attachment (id=15116)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15116action=view)
A tentative patch for the PR
This is regtesting but all the allocatable component tests are OK.
Could somebody
--- Comment #4 from debian-gcc at lists dot debian dot org 2008-02-07
15:15 ---
reproducible with 20080206, gcc is configured with
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080206-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-02-07 15:01
---
Once again, good detective work by jpr. This then does make this a regression
wrt 4.1. I do not have a 4.1 build on my windows machine to check. Regardless
...
This begs a question. Why do we even want
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-07 14:16 ---
This code doesn't work reliably. Change it to
int main()
{
int size;
coutEnter size of array: ;
cinsize;
int arr[size];
...
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #4 from dominiq at lps dot ens dot fr 2008-02-07 14:16 ---
I get
[ibook-dhum] i686-darwin/gcc% make -k check-g++
RUNTESTFLAGS=dg.exp=template/spec35.C
test -d testsuite || mkdir testsuite
test -d testsuite/g++ || mkdir testsuite/g++
(rootme=`${PWDCMD-pwd}`; export rootme;
--- Comment #28 from ubizjak at gmail dot com 2008-02-07 14:15 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-07 14:13 ---
I mean that other testcases should be using similar patterns, and if they do
the second underscore is probably there. A quick grep only finds
rtti/tinfo1.C:// { dg-final { scan-assembler-not (.globl|.global)\[
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-07 20:41 ---
Subject: Bug 32754
Author: manu
Date: Thu Feb 7 20:40:19 2008
New Revision: 132174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132174
Log:
2008-02-07 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-07 19:57 ---
Got the blocks/depends thing wrong, sorry.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-02-07 19:52 ---
*** This bug has been marked as a duplicate of 20567 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-02-07 18:56 ---
This is definitely a canonical-types bug.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-02-07 22:52 ---
See:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9e38ff2694bfdab1/
If I understand it correctly, the right solution is do the same as NAG f95 does
and print the following:
123456
ASDFef
--- Comment #9 from ubizjak at gmail dot com 2008-02-07 20:52 ---
Related to PR33992 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720
--- Comment #18 from ubizjak at gmail dot com 2008-02-07 20:47 ---
(In reply to comment #17)
P2 - this should not block the release (it's not that profiledbootstrap was
never
broken in released compilers). It's also hard to analyze (no, I'm not on it,
volunteers welcome).
It looks
--- Comment #14 from irar at il dot ibm dot com 2008-02-07 20:44 ---
Giving it another thought, this is not necessary an alias analysis issue, even
that it fails to tell that the pointers not alias. Since in this case the
pointers do differ, the runtime test should take the flow to the
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-07 18:06 ---
Sure. Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2008-02-07 22:44 ---
*** Bug 35133 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35130
--- Comment #1 from jakub at gcc dot gnu dot org 2008-02-07 22:44 ---
*** This bug has been marked as a duplicate of 35130 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rondesot at yahoo dot com 2008-02-07 17:15 ---
I would like to confirm this bug and discuss a work around that I used.
This bug seems to be the only thing that keeps gcc 4.3 with java from
completing a native build under mingw.
With the two patches below, I was
--- Comment #5 from bonzini at gnu dot org 2008-02-07 17:10 ---
Unrelated, but why couldn''t vector/vector shifts/rotates overload LSHIFT_EXPR
instead? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
As reported by Ignacio Fernández Galván, the following program prints with
gfortran -fopenmp 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.
See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html
I believe the program is valid, compare also
As reported by Ignacio Fernández Galván, the following program prints with
gfortran -fopenmp 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.
See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html
I believe the program is valid, compare also
1 - 100 of 154 matches
Mail list logo
