On Mon, Jan 11, 2010 at 8:14 AM, Wen Li wenli...@gmail.com wrote:
On x86 processors, I think bitwise operators should be optimized for
individual bit accesses, which should be converted to BT instructions.
For example:
x |= 1y; compiles to BTS instead of SHL/OR
x ^= 1y; compiles to BTC
Hi,
I've been trying to play with the Neon scheduler description in
config/arm/neon-schedgen.ml.
Running the description through the ocaml compiler gives me the
following errors
cam-bc3-b12:ramrad01 68 ocamlc -c neon-schedgen.ml
File neon-schedgen.ml, line 51, characters 0-10:
Unbound
Hi,
I'm doing some experiments on the STM implementation on GCC, but I
need some info since the documentation is still not available,
What is the syntax currently adopted in STM_GCC, martin told me that
the old syntax #pragma atomic is not used in the current
implementation and that possibly
On Mon, 11 Jan 2010 09:52:59 +
Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote:
cam-bc3-b12:ramrad01 68 ocamlc -c neon-schedgen.ml
File neon-schedgen.ml, line 51, characters 0-10:
Unbound module Utils
It sounds like a configuration issue but given my rather rusty ocaml
skills
On Mon, Jan 11, 2010 at 12:28:38PM +, Julian Brown wrote:
Another thing which might bite you is that recent OCaml versions don't
like hyphens in filenames: replacing them with underscores works OK
though (i.e. neon_schedgen.ml).
Fortunately it's just a warning; you can also ignore it.
--
Hello,
Is the a way to get access to the currently thrown
C++ exception object? cxxabi.h gives me only access
to its std::type_info via __cxa_current_exception_type().
On the other hand, the ABI documentation describes
the struct __cxa_exception, but it is not accessible
via cxxabi.h.
Would you like to try this out and see how you get on with it?
Followups set to gcc-patches.
Thanks - that works and I can confirm that those bits generate identical
code to what's auto-generated in cortex-a8-neon.md.
I'll submit a patch to gcc-patches@ unless you beat me to it.
cheers
In the absence of any discussion, I just went ahead and implemented my
new ideas, which are attached as a patch!
Whilst it is tailored to the specifics of our architecture - where we
have 32 C_REGS, of which there are 16 BOTTOM_REGS, and some insns
that only work with BOTTOM_REGS - I believe it
Hi all,
I am using gcc 4.3.4 to loop through the gimple tree to find
CALL_EXPR. This is what I have (even though I tried several variants,
none of which worked):
tree body_stmt = DECL_SAVED_TREE (current_function_decl);
while (body_stmt) //
{
if (TREE_CODE (body_stmt) ==
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types. Is it a feature, bug or lack
of development?
#cat test.cc
On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos pocma...@gmail.com wrote:
Hi all,
I am using gcc 4.3.4 to loop through the gimple tree to find
CALL_EXPR. This is what I have (even though I tried several variants,
none of which worked):
tree body_stmt = DECL_SAVED_TREE
On 01/11/2010 05:24 PM, Roman Kononov wrote:
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types. Is it a
On Mon, 2010-01-11 at 10:24 -0600, Roman Kononov wrote:
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types.
A rebuild test of the current Debian unstable distribution on x86_64-linux-gnu
was done, one rebuild test with the current gcc-4.4 from the branch, and another
one with GCC trunk 20100107. The latter did show about 200 additional build
failures, which are listed in [1] (minus some already known
Thank you,
There is one more link problem (for an intrinsic function) :
libitm.so: undefined reference to `__sync_add_and_fetch_8'
I found on the Net that there was a bug related to this on GCC 4.2,
the solution was to specify the architecture (-march=i686) at compile
time, but this doesn't
On Mon, 2010-01-11 at 17:51 +0100, Richard Guenther wrote:
On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos pocma...@gmail.com wrote:
Hi all,
I am using gcc 4.3.4 to loop through the gimple tree to find
CALL_EXPR. This is what I have (even though I tried several variants,
none of which
2010/1/11 Piotr Wyderski:
Hello,
Is the a way to get access to the currently thrown
C++ exception object? cxxabi.h gives me only access
to its std::type_info via __cxa_current_exception_type().
On the other hand, the ABI documentation describes
the struct __cxa_exception, but it is not
Any thoughts on this? The proposed patch has been applied to newlib's
math.h.
-- Jeff J.
Original Message
Subject: OpenMP vs. math.h
Date: Fri, 08 Jan 2010 12:42:35 -0600
From: Yaakov (Cygwin/X) yselkow...@users.sourceforge.net
To: new...@sources.redhat.com
POSIX allows for
Hi,
However, I just encountered tonight a much larger conflict: OpenMP/C++
and math.h are incompatible. STC attached:
$ g++ -D_GLIBCXX_PARALLEL -fopenmp openmp.cxx -lgomp
In file included from
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/parallel/algobase.h:46,
from
Some of the support for those
classes is in current trunk, but a crucial change to the compiler to
allow binary compatibility between those classes and the C builtin
types wasn't approved before the 4.5 feature cutoff (see
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01321.html).
Am a bit
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-11 08:16 ---
just waiting to see if this can be reproduced with clean sources.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from stevenb dot gcc at gmail dot com 2010-01-11 08:22
---
Subject: Re: redundant memory load
On Mon, Jan 11, 2010 at 7:47 AM, carrot at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3,
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-11 08:35 ---
See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c11 for one of the
possible reasons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
--- Comment #12 from gerald at pfeifer dot com 2010-01-11 08:36 ---
Closing per previous comment.
Yuri, is it possible a different (older) run-time library was picked
up during your original tests?
--
gerald at pfeifer dot com changed:
What|Removed
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-11 08:50 ---
Looks similar to pr42677. The patch in comment#3 fixes these PRs, but misses
also really(?) ambiguous interfaces, see:
gcc/testsuite/gfortran.dg/defined_operators_1.f90
gcc/testsuite/gfortran.dg/generic_7.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-11 08:51 ---
Similar to pr42677 (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684#c4 ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-11 08:52 ---
Similar to pr42677
Wrong window!-( Similar to pr42684.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #12 from carrot at google dot com 2010-01-11 08:55 ---
(In reply to comment #11)
Yes, I would have expected the block starting with .L4 to be *after*
the block starting with .L5, something like so:
iterate:
push{lr}
ldr r3, [r1]
.L6:
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-11 09:25 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pzhao at gcc dot gnu dot org 2010-01-11 09:33 ---
Fixed for 4.5.0
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pzhao at gcc dot gnu dot org 2010-01-11 09:34 ---
Fixed for 4.5.0
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-11 09:35 ---
Re. comment #5 -- rth, any suggestions what an algorithm would look like to
minimize the number of branches, or the total size of all of the branch
instructions? And what do you mean with some clever changes to the
--- Comment #5 from jzhang918 at gmail dot com 2010-01-11 09:36 ---
I just submitted a patch several days ago:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00130.html
I think it might be able to fix this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42662
g++ doesn't accept correct code:
namespace N
{
struct S { };
void f(const S ) { }
}
void f(const N::S ) { }
int main()
{
N::S v;
(f)(v); // no ambiguity: ADL is prevented with (), only ::f is considered
}
--
References:
1)
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-11 09:46 ---
Created an attachment (id=19537)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19537action=view)
gcc45-pr42662.patch
Fix.
Regarding the above mentioned patch, it looks like a big hammer, which will
create a lot
--- Comment #7 from jzhang918 at gmail dot com 2010-01-11 10:11 ---
Sorry, I should have checked my patch with the test code you posted before I
added that comment. My patch does not fix this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42662
--- Comment #7 from dominiq at lps dot ens dot fr 2010-01-11 10:27 ---
(In reply to comment #6)
This patch, reverting only the change to interface.c, appears to fix the
problem. No other regressions in testsuite.
The patch reintroduces pr42353 for the test in
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-11 10:31 ---
The problem here are different holes in SSA_NAMEs - with
-fvar-tracking-assignments most of the SSA_NAME_VERSION values are one larger
than without it. -fcompare-debug dumps include these versions in some MEMs, so
it
--- Comment #3 from zsojka at seznam dot cz 2010-01-11 10:45 ---
Created an attachment (id=19538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19538action=view)
different reduced testcase
$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/g++ -O1 -fcompare-debug -c
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:27
---
Jan, are you there?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-11 11:28 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:30
---
I think we should consider that x86_64-apple-darwin is not supported in 4.4 and
make sure that it will be in 4.5, in particular fix PR middle-end/42068.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:31
---
Still present?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-11 12:12 ---
Created an attachment (id=19539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19539action=view)
gcc45-pr42645.patch
Fix I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42645
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-11 12:18 ---
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00430.html
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00431.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42657
--- Comment #18 from dominiq at lps dot ens dot fr 2010-01-11 12:20 ---
Still present?
Yes!-(If it has not been fixed meanwhile, it still fails at revision 155621).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #20 from dominiq at lps dot ens dot fr 2010-01-11 12:29 ---
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
pr41478_1.f90:7:0: internal compiler error: Segmentation
--- Comment #32 from rahul at icerasemi dot com 2010-01-11 12:34 ---
I will re-test on our port and report my findings, cheers!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-11 12:38
---
Subject: Bug 41569
Author: rguenth
Date: Mon Jan 11 12:38:09 2010
New Revision: 155809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155809
Log:
2010-01-11 Richard Guenther rguent...@suse.de
PR
--- Comment #21 from pault at gcc dot gnu dot org 2010-01-11 12:50 ---
(In reply to comment #20)
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
Oh, that's weird! Does the
--- Comment #22 from burnus at gcc dot gnu dot org 2010-01-11 13:06 ---
(In reply to comment #20)
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
[...]
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-01-11
13:08 ---
Fixed in r155800.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
--- Comment #23 from dominiq at lps dot ens dot fr 2010-01-11 13:50 ---
(In reply to comment #21)
Oh, that's weird! Does the original testcase and the one supplied with the
patch work?
Yes, it was under all my tests.
(In reply to comment #22)
Because of that line: Dominique, do
--- Comment #24 from dominiq at lps dot ens dot fr 2010-01-11 14:04 ---
(In reply to comment #23)
Because of that line: Dominique, do you have the draft patch for PR 42647
installed? If so, it might be the reason for the problem. Just to add
another
possibility for the failure.
When you build sqlite using GCC and -O2 parameter you get the following
warning. During runtime EXPR_FULLSIZE-nSize is mostly non-zero so it seems
that the GCC optimizer makes some assumptions that doesn't not always hold
true.
In function memset,
inlined from exprDup at sqlite3.c:61011:
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from abel at gcc dot gnu dot org 2010-01-11 14:35 ---
(In reply to comment #2)
This is the other bug in our region walk iterator that happens when pipelining
outer loops. When looking for loop exits from an inner loop that is contained
in the outer loop currently being
Various diagnostics produced from specs with %e and %n are badly formatted.
There should be no \n or other whitespace at the end of these diagnostics,
since the driver inserts a newline at the end automatically.
A single diagnostic should not be split across multiple messages, for
the sake of
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-01-11 15:04 ---
Correction: the newlines get removed before the messages are printed.
But they don't get removed by exgettext either before or after the patch
for bug 39521. As they are unnecessary (at least once the message pairs
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-01-11 15:04
---
Our previous patch (http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01215.html)
failed to correctly fix the problem, and the new testcase uncovers a flaw in
that implementation.
We 'forgot' to recompute topological
--
Summary: Undefined reference errors with -flto -fuse-linker-
plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-11
15:25 ---
Created an attachment (id=19541)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19541action=view)
testcase
GCC 4.5.0 20100107.
gcc -flto -fuse-linker-plugin pr42690.c -DBUG
--
--- Comment #7 from jjcogliati-r1 at yahoo dot com 2010-01-11 15:50 ---
(In reply to comment #6)
Try
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155739)
+++ gcc/gimple.c(working copy)
@@
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #8 from rguenther at suse dot de 2010-01-11 15:54 ---
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #7 from jjcogliati-r1 at yahoo dot
--- Comment #6 from law at redhat dot com 2010-01-11 17:14 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/10/10 01:22, irar at il dot ibm dot com wrote:
--- Comment #5 from irar at il dot ibm dot com 2010-01-10 08:22 ---
In vector_alignment_reachable_p()
--- Comment #9 from jjcogliati-r1 at yahoo dot com 2010-01-11 17:15 ---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that
--- Comment #7 from law at redhat dot com 2010-01-11 17:16 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/08/10 10:25, rguenth at gcc dot gnu dot org wrote:
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-08 17:25
---
Well, indeed we have a
--- Comment #10 from rguenther at suse dot de 2010-01-11 17:22 ---
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #9 from jjcogliati-r1 at yahoo dot
--- Comment #18 from goeran at uddeborg dot se 2010-01-11 17:27 ---
I did try it out as you suggested, and it seems to work just fine.
(I.e. messages from fortran/arith.c were said to come from fortraarith.c in the
pot file. But I didn't bother to investigate that, it wasn't what I
--- Comment #16 from davek at gcc dot gnu dot org 2010-01-11 17:39 ---
Confirmed that it was just a glitch of some kind.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from dominiq at lps dot ens dot fr 2010-01-11 17:50 ---
I have applied the patch in comment #19 to a clean fortran-exp and I still see
the segmentation fault when compiling the test in comment #8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #3 from manu at gcc dot gnu dot org 2010-01-11 18:17 ---
There must be some reason why this:
if (warn_return_type
TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
!current_function_returns_value !current_function_returns_null
/* Don't complain
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-11 18:23 ---
I've looked briefly at the #c4 testcase, and the problem seems to be extremely
long loc_chains. var-tracking e.g. stops for huge amount of time (many
minutes) on one bb, EH pad with 162 incoming EH edges (and no
--- Comment #26 from pault at gcc dot gnu dot org 2010-01-11 18:23 ---
(In reply to comment #25)
I have applied the patch in comment #19 to a clean fortran-exp and I still see
the segmentation fault when compiling the test in comment #8.
A that's because allocatable scalars
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-11 18:37
---
This was changed by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#705 and didn't
appear in the working draft until November.
It's hardly surprising that a compiler released in October doesn't
--- Comment #13 from manu at gcc dot gnu dot org 2010-01-11 18:39 ---
If this doesn't occur in GCC 4.5, the best we can do is to put the testcases in
the testsuite and close this. Many things changed from 4.4. to 4.5 that may
have cause the bug to disappear and that won't be backported,
--- Comment #10 from manu at gcc dot gnu dot org 2010-01-11 18:46 ---
(From update of attachment 19531)
This file has nothing to do with this bug.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2010-01-11 18:52 ---
(In reply to comment #9)
Please recategorize this report as diagnostic quality, confirm, and assign
it.
Bugs are not assigned, they are taken. But confirmed it is. Patches welcome.
--
manu at gcc dot gnu dot
--- Comment #12 from manu at gcc dot gnu dot org 2010-01-11 18:54 ---
Comeau rejects it. Is this accepts-invalid, then?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jjcogliati-r1 at yahoo dot com 2010-01-11 18:58
---
(In reply to comment #10)
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
---
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-11
19:05 ---
Subject: Re: [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06
11:55 ---
[...]
I'm now
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-11 19:07 ---
(In reply to comment #3)
(even without the __noreturn__?)
Yes, even without.
I think this may be actually two bugs, one is the noreturn which should set
current_function_returns_abnormally to true, so no
--- Comment #18 from manu at gcc dot gnu dot org 2010-01-11 19:23 ---
(In reply to comment #17)
Fixed.
Richard, since this is a new feature of GCC 4.5, shouldn't we mention it in the
GCC 4.5 changes.html?
Even something short would be welcome by users, such as:
Better
A wrong REG_EQUAL is attached to SUBREG during forward propagation.
Before fwprop1
(insn 56 55 57 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ])
(const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil))
(insn 60 59 61 3 double.cpp:12 (set (reg:SI 189)
(const_int 2146435072
--- Comment #1 from jingyu at google dot com 2010-01-11 19:59 ---
I forgot to paste the wrong assembly code.
arm-eabi-g++ -Os -mthumb double.cpp --save-temps -c -o double.o
The assembly for the following part
_D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }};
if (*entry == _D_inf.val)
--- Comment #19 from burnus at gcc dot gnu dot org 2010-01-11 20:21 ---
(In reply to comment #1)
One detail I happened to see: The messages defined in gfc_arith_error doesn't
get any gcc-internal-format marker, though they do contain %L. Do you want a
separate bugzilla about that?
The bug is: if a class definition has a nested template class, then whenever a
code refers to a name in the nested class, gcc searches it not in the nested
template class, but it the outer class.
The bug results in gcc accepting a source text that should not be compiled, and
incorrectly compiling
--- Comment #5 from janis at gcc dot gnu dot org 2010-01-11 20:29 ---
Subject: Bug 42416
Author: janis
Date: Mon Jan 11 20:29:40 2010
New Revision: 155816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155816
Log:
PR target/42416
* config/rs6000/rs6000.c
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-11 20:59
---
Mainline is fine.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
The strings returned from gfc_arith_error in gcc/fortran/arith.h contain the
location marker %L. But as noticed in bug 36161, they are not marked
gcc-internal-format. This marking is valuable to avoid mistakes in the
translation.
--
Summary: Missing gcc-internal-format on messages
--- Comment #20 from goeran at uddeborg dot se 2010-01-11 21:02 ---
(In reply to comment #19)
Yes please.
I've filed bug 42693 about that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
--- Comment #14 from simon at pushface dot org 2010-01-11 21:35 ---
Concur with Eric.
Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
of procedure here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
Right now, the compiler has no special code to optimize pow (x, 0.75) into
something like sqrt (x) * sqrt (sqrt (x)) under -ffast-math, nor pow (x, 0.25)
into sqrt (sqrt (x)). On machines with a builtin sqrt instruction, it is often
times faster to do the calculations using sqrt than calling the
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2010-01-11 21:41
---
Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
of procedure here.
You'd need to go through the full testing procedure described here:
http://gcc.gnu.org/contribute.html
--
--- Comment #1 from meissner at gcc dot gnu dot org 2010-01-11 21:42
---
Created an attachment (id=19542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19542action=view)
Program to demonstrate the slowdown
This program calculates the speed of various pow arguments.
--
The build fails with
../../gcc-trunk-svn/gcc/config/vxworks.c: In function
vxworks_emutls_var_fields:
../../gcc-trunk-svn/gcc/config/vxworks.c:73:27: error: macro build_decl
requires 4 arguments, but only 3 given
../../gcc-trunk-svn/gcc/config/vxworks.c:72:11: error: build_decl undeclared
--- Comment #1 from simon at pushface dot org 2010-01-11 21:47 ---
Created an attachment (id=19543)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19543action=view)
Patch to gcc/config/vxworks.c
Adds new parameter required by change to gcc/tree.
--
--- Comment #9 from danglin at gcc dot gnu dot org 2010-01-11 21:51 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00066.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
1 - 100 of 124 matches
Mail list logo
