--- Comment #6 from ubizjak at gmail dot com 2008-10-29 07:10 ---
According to Intel [1]:
According to Dan, __sync_fetch_and_nand intrinsic should be implemented as
~(target & val). Uros's patch is correct.
[1] http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01214.html
--
ubizjak at g
--- Comment #2 from bonzini at gnu dot org 2008-10-29 07:17 ---
Subject: Re: [4.4 Regression] IRA generates slower
code for -mtune=core2
hjl dot tools at gmail dot com wrote:
> --- Comment #1 from hjl dot tools at gmail dot com 2008-10-29 05:44
> ---
> It looks like the cost
Sent from my iPhone
On Oct 29, 2008, at 12:17 AM, "bonzini at gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #2 from bonzini at gnu dot org 2008-10-29 07:17
---
Subject: Re: [4.4 Regression] IRA generates slower
code for -mtune=core2
hjl dot tools at gmail dot com wrot
--- Comment #3 from pinskia at gmail dot com 2008-10-29 07:25 ---
Subject: Re: [4.4 Regression] IRA generates slower code for -mtune=core2
Sent from my iPhone
On Oct 29, 2008, at 12:17 AM, "bonzini at gnu dot org"
<[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #2 from bonzini
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-29 08:28 ---
I've bootstrapped/regtested the trunk last night on s390-linux just fine.
Can you reproduce this with current trunk (there has been e.g. an IRA fix
for s390* compiler miscompilation)?
If yes, can you say which stage cc
--- Comment #33 from jakub at gcc dot gnu dot org 2008-10-29 08:29 ---
In this case they should be fixed with your backend change too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org
|dot org
--- Comment #7 from kokseng at ieee dot org 2008-10-29 09:37 ---
The only problem is whether there are codes out there that depend on
"NEGATE-and-AND"? Frankly speaking, when I was reminded about the 'nand'
comment on gcc manual, only then I remembered many moons ago, I read that li
Given various methods for determining byte order on different platforms, the
following can be used in C++ to find the byte order across platforms.
static const uint32_t bytes = 0x03020100ul;
static const unsigned lo = *(const unsigned char*)&bytes;
Unfortunately, the value of 'lo' is determin
--- Comment #8 from ubizjak at gmail dot com 2008-10-29 10:55 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01224.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
gas_dyn fails when autopar is enabled.
The failure is durig alias computation for one of the new parallel functions
created by autopar.
gas_dyn.f90: In function âcortesa._loopfn.0â:
gas_dyn.f90:1791: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:565
Please submit a full bug repo
Compiling ma57 with
"gfortran -O -ftree-parallelize-loops=2 -c ma57.f -o ma57.o"
produces the following error messages:
= 1,2
--
ma57.f: In function 'ma57od':
ma57.f:2724: error: edge from 676 to 686 should be marked irreducible
ma57.f:2724: error: basic block 686 should be marked irredu
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-29 12:39 ---
(In reply to comment #2)
> counter += inc(&counter);
>
> That is undefined code as you access counter without a sequence point where
> you
> assign it.
Is it only undefined because inc modifies counter? We do not
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-29 12:40 ---
(In reply to comment #3)
> Thanks for the quick answer. Is it possible to get a warning if I write
> undefined code like this? -Wall didn't tell me anything.
-Wsequence-point should but it doesn't right now. The sooner
gas_dyn fails when autopar is enabled.
The failure is durig alias computation for one of the new parallel functions
created by autopar.
gas_dyn.f90: In function âcortesa._loopfn.0â:
gas_dyn.f90:1791: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:565
Please submit a full bug repo
--- Comment #4 from hjl dot tools at gmail dot com 2008-10-29 13:08 ---
(In reply to comment #2)
> Subject: Re: [4.4 Regression] IRA generates slower
> code for -mtune=core2
>
> hjl dot tools at gmail dot com wrote:
> > --- Comment #1 from hjl dot tools at gmail dot com 2008-10-2
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-29 13:18
---
*** Bug 37952 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37950
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-29 13:18
---
*** This bug has been marked as a duplicate of 37950 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-29 14:38 ---
Waiting for a testcase. May be related to PR37485.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-29 14:34 ---
Warning is (reliably) only possible if we can tell if the function call
modifies
the passed storage. This requires some IPA analysis and thus moving the
warning to the middle-end.
--
http://gcc.gnu.org/bugzilla
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.3.2 4.4.0 |4.3.0 4.3.2 4.4.0
Target Milestone|--- |4.3
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
--
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 #34 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-29
15:00 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> In this case they should be fixed with your backend change too.
No, my change was only for the 64-bit t
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-29 15:19 ---
Subject: Bug 37913
Author: jakub
Date: Wed Oct 29 15:19:24 2008
New Revision: 141426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141426
Log:
PR middle-end/37913
* tree-cfgcleanup.c (split_bb
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-29 15:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from dennis dot wassel at googlemail dot com 2008-10-29
15:27 ---
(In reply to comment #1)
> Waiting for a testcase. May be related to PR37485.
Much as I would like to help, but I will not be able to distill a testcase out
of ma57 due to license and time constraints. So
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-29 15:31 ---
The problem is that -fno-toplevel-reorder is often more restrictive than
-fno-unit-at-a-time used to be. I guess instead of removing the testcase we
should just remove -fno-unit-at-a-time, or add -ftoplevel-reorder.
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-29 15:46 ---
(In reply to comment #6)
> Warning is (reliably) only possible if we can tell if the function call
> modifies
> the passed storage. This requires some IPA analysis and thus moving the
> warning to the middle-end.
I do
--- Comment #6 from manu at gcc dot gnu dot org 2008-10-29 16:05 ---
Subject: Bug 26997
Author: manu
Date: Wed Oct 29 16:05:27 2008
New Revision: 141429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141429
Log:
2008-10-29 Manuel López-Ibáñez <[EMAIL PROTECTED]>
PR
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-29 16:06 ---
FIXED in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-29 16:07 ---
Subject: Bug 37870
Author: jakub
Date: Wed Oct 29 16:07:39 2008
New Revision: 141430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141430
Log:
PR middle-end/37870
* expmed.c (extract_bit_field
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-29 16:08 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #9 from joel at gcc dot gnu dot org 2008-10-29 16:30 ---
ACATS results for powerpc-rtems4.10 with the "maybefix"
http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02107.html
They look very good with 6 failure cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2008-10-29
16:36 ---
I have also seen this, and it seems that --with-libiconv-prefix=/sw/
does not do the trick anymore with the trunk (unless some other
difference in my setup is responsible for this).
Googleing a bit sho
hi there,
I am testing a package with three source files.
I saw lots of information about solving 'undefined reference to ###', but it
stucks me.
compile the object file with
'gfortran -c optnhp3ma.f middle3.f optnhp3.f'
when I run these objects, coupled with a problem input. Things happen...
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-29 17:00 ---
You should link using gfortran, that is
gfortran -c optnhp3ma.f middle3.f optnhp3.f
gfortran -o xxx optnhp3ma.o middle3.o optnhp3.o
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #29 from janis at gcc dot gnu dot org 2008-10-29 17:05 ---
On powerpc-linux the submitter's testcase gets better code with the patch from
comment #17, but the same testcase with the loop starting with 1 instead of
zero gets worse code. From the 4.1 branch with -O2:
.L2:
--- Comment #4 from jsm28 at gcc dot gnu dot org 2008-10-29 17:06 ---
Subject: Bug 36578
Author: jsm28
Date: Wed Oct 29 17:05:42 2008
New Revision: 141432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141432
Log:
PR middle-end/36578
* convert.c (convert_to_real)
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-10-29 17:12 ---
Fixed for 4.4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-29 17:17 ---
Subject: Bug 11492
Author: manu
Date: Wed Oct 29 17:16:46 2008
New Revision: 141434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141434
Log:
2008-10-29 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 11
--- Comment #8 from manu at gcc dot gnu dot org 2008-10-29 17:24 ---
FIXED in GCC 4.4. Thanks for the report and sorry for the time this took!
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from edwintorok at gmail dot com 2008-10-29 18:48 ---
I just noticed that this testcase also fails with -O3 on gcc version 4.1.2
20070626 (Red Hat 4.1.2-14), but works on gcc version 4.1.3 20080623
(prerelease) (Debian 4.1.2-23)
--
edwintorok at gmail dot com changed:
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-29 19:14 ---
Actually, the behaviour of -fno-toplevel-reorder is documented this way:
`-funit-at-a-time'
This option is left for compatibility reasons. `-funit-at-a-time'
has no effect, while `-fno-unit-at-a-time' implies
--- Comment #6 from sje at gcc dot gnu dot org 2008-10-29 19:41 ---
Subject: Bug 37339
Author: sje
Date: Wed Oct 29 19:41:26 2008
New Revision: 141440
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141440
Log:
PR middle-end/37339
* gcc.dg/pr33545-3.c: Remove.
Re
It appears that although an array of packed structures is done correctly, when
a routine is called that references an element of said packed structures the
compiler believes it to be word aligned.
--
Summary: odd sized packed structures, under ARM, cause lockup of
--- Comment #7 from sje at cup dot hp dot com 2008-10-29 19:43 ---
Deleted test as it is no longer valid since we don't support
non-unit-at-a-time.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-29 19:44 ---
Do you have an example code that shows this? I almost want to say this is
expected behavior.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from sje at gcc dot gnu dot org 2008-10-29 19:46 ---
Subject: Bug 32277
Author: sje
Date: Wed Oct 29 19:46:16 2008
New Revision: 141442
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141442
Log:
PR target/32277
* libgcov.c ( __gcov_indirect_call_pr
--- Comment #2 from damon dot michaels at navico dot com 2008-10-29 19:49
---
Subject: RE: odd sized packed structures, under ARM, cause lockup of
application
Yes, I'm figuring out how to move it from VMWare to my Windows system.
It is unexpected to me. X86 doesn't do it under 3 dif
--- Comment #4 from sje at cup dot hp dot com 2008-10-29 19:49 ---
Fixed with patch to libgcov.c
--
sje at cup dot hp dot com changed:
What|Removed |Added
Sta
--- Comment #3 from damon dot michaels at navico dot com 2008-10-29 19:52
---
Created an attachment (id=16580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16580&action=view)
.c source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #4 from damon dot michaels at navico dot com 2008-10-29 19:52
---
Created an attachment (id=16581)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16581&action=view)
requested .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #5 from damon dot michaels at navico dot com 2008-10-29 19:53
---
Created an attachment (id=16582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16582&action=view)
requested options
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
Attached is a sample from OpenSSL.
When compiled with -O3 the error comes up.
I tried to remove as much code as I could, but it looks like every line I
remove also avoid the error.
I use rev141361
--
Summary: internal compiler error: in vectorizable_store, at tree-
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-29 20:28 ---
Created an attachment (id=16583)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16583&action=view)
Bugfix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
--- Comment #1 from alon dot barlev at gmail dot com 2008-10-29 20:28
---
Created an attachment (id=16584)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16584&action=view)
sample1.c
sample1.c: In function âaep_rsa_mod_expâ:
sample1.c:619: internal compiler error: in vectoriza
--- Comment #1 from mikael dot morin at tele2 dot fr 2008-10-29 20:59
---
Reduced case:
subroutine subr (m, n, a, b, c, d, p)
implicit none
integer m, n
real a(m,n), b(m,n), c(n,n), d(m,n)
integer p(n)
d = a(:,p) - matmul(b, c)
end subroutine
The problem is with a(:,p) - ma
--- Comment #2 from mikael dot morin at tele2 dot fr 2008-10-29 21:06
---
Created an attachment (id=16585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16585&action=view)
proposed patch, regression tested
This patch solves the problem by going through all the loop dimensions in
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-29 21:12 ---
works for me on x86_64-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dodji at gcc dot gnu dot org 2008-10-29 21:56 ---
I think the problem is due to the fact that in general, grokdeclarator() in
gcc/cp/decl.c does not properly set the type variant node for typedef
statements.
To understand this way of representing the relationship bet
On my continuous tester I noticed that with trunk ac3207a sometimes hangs.
Using a slightly modified testcase and a shell loop I managed to reproduce it
after one hour of looping (140k loop exec), please find below the gdb
backtrace.
$ gcc -v
gcc version 4.4.0 20081029 (experimental) [trunk
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-29 22:42 ---
(In reply to comment #1)
> May be related to PR37485.
I highly doubt it is related to that PR as this is reported against 4.3.2 and
graphite was not in 4.3.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3795
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-29 22:46 ---
The cfg manipulation code on the branch has the same "bug" as on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
--- Comment #13 from dje at gcc dot gnu dot org 2008-10-29 23:33 ---
Subject: Bug 37878
Author: dje
Date: Wed Oct 29 23:33:02 2008
New Revision: 141450
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141450
Log:
PR target/37878
* config/rs6000/predicates.md (word_
--- Comment #31 from jakub at gcc dot gnu dot org 2008-10-29 23:33 ---
Any progress on this patch? IMHO an option that doesn't work on most of the
primary and secondary arches deserves to be disabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-10-29 23:54 ---
Subject: Bug 37909
Author: kkojima
Date: Wed Oct 29 23:54:35 2008
New Revision: 141452
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141452
Log:
PR target/37909
* config/sh/sh.c (untangle_mo
--- Comment #14 from lucier at math dot purdue dot edu 2008-10-30 00:02
---
Thank you, this fixes the original bug.
I took the liberty of closing this bug report.
Thanks again.
Brad
--
lucier at math dot purdue dot edu changed:
What|Removed |Ad
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 00:09 ---
What revision is this? Seems fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-30 00:11 ---
Subject: Bug 36668
Author: jakub
Date: Thu Oct 30 00:11:23 2008
New Revision: 141453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141453
Log:
PR debug/36668
* g++.dg/other/PR23205.C: Allow fo
--- Comment #3 from lucier at math dot purdue dot edu 2008-10-30 00:19
---
You're right, it was fixed by
Revision 141193 - (view) (download) - [select for diffs]
Modified Fri Oct 17 14:50:07 2008 UTC (12 days, 9 hours ago) by krebbel
File length: 238566 byte(s)
Diff to previous 140914
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-30 00:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-30 01:47 ---
Under FreeBSD x68 this works in trunk and branch.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from hjl dot tools at gmail dot com 2008-10-30 02:04 ---
Change Core 2 cost with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948#c1
doesn't help. Re-enable regmove with
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16571
fixes the performance regression.
--
hjl d
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-30 04:15 ---
Created an attachment (id=16586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16586&action=view)
Add POINTER_PLUS_EXPR - Improvement?
It seems we miss the POINTER_PLUS_EXPR. In most cases in tree-scalar-evol.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
CC||grosser at gcc dot gnu dot
|
--- Comment #3 from grosser at gcc dot gnu dot org 2008-10-30 04:28 ---
(From update of attachment 16586)
This patch was thought for another bug.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from alon dot barlev at gmail dot com 2008-10-30 06:45
---
Created an attachment (id=16587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16587&action=view)
sample2.c
Maybe the complete source will be better...
$ x86_64-pc-mingw32-gcc -O3 -c sample2.c
e_aep.c: In
--- Comment #5 from cnstar9988 at gmail dot com 2008-10-30 06:57 ---
fixed in gcc 4.3 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37879
80 matches
Mail list logo
