--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-04-11 06:38
---
Restoring the size check to gfortran-exp branch I get the following results
with the test case in comment #1.
Current trunk (4.6):
$ time gfc pr34554.f90
real8m26.965s
user8m21.252s
sys 0m2.477s
$
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-04-11 06:44
---
Created an attachment (id=20360)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20360action=view)
patch for fortran-exp branch
Please test on fortran-exp branch.
--
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-11 08:11 ---
With the patch in comment #9 applied to the fortran-exp branch, the timing for
the original test is slightly slower than trunk ~250s compared to ~240s.
Note that the procedure node_copy_and_append should be deleted
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-11 08:26 ---
+ /* If we can successfully get an array element at the max array size then
s/can/cannot/ ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
--- Comment #36 from iains at gcc dot gnu dot org 2010-04-11 10:18 ---
(In reply to comment #33)
(In reply to comment #32)
Note that when using the patch in comment #22 triggers pr43254: another side
effect of -lm is to prevent the run of dsymutil even with -g.
my 0,02 euro...
1.
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-11 10:29 ---
(In reply to comment #6)
I wrote
which means using gcc-4.0.1; I used *exactly* your configure line.
Did you have the gmp and mpfr sources in the gcc-4_4-branch source directory?
1. I re-tried with the current
--- Comment #6 from carrot at google dot com 2010-04-11 12:09 ---
Some experiment results:
Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums
without this optimization: 2830665
simplify-got before ra:2825737
simplify-got after ra: 2826853
So this optimization
--- Comment #7 from carrot at google dot com 2010-04-11 12:12 ---
(In reply to comment #6)
Some experiment results:
Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums
without this optimization: 2830665
simplify-got before ra:2825737
simplify-got after ra:
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-04-11 13:07
---
Dominique, thanks for testing. You are not getting near the same speedup I am.
It must be related to cache size. I will submit the patch for approval some
time in the next few days.
--
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2010-04-11
13:56 ---
Actually, it has to be...
@@ -30,8 +30,8 @@
#set_board_info host_library_path [file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print-prog-name=cc1]]/lib
-#
--- Comment #29 from rwild at gcc dot gnu dot org 2010-04-11 14:24 ---
Created an attachment (id=20361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20361action=view)
patch to address issue described in comment #21
The main issue described in this bug is fixed, and it has rightly
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2010-04-11
14:47 ---
Interestingly, while the change in Comment 37 eliminates the failures in
gcc.dg/torture/builtin-math-7.c, it introduces the failures...
FAIL: gcc.c-torture/execute/20020412-1.c compilation, -O3 -g
--- Comment #39 from iains at gcc dot gnu dot org 2010-04-11 15:10 ---
(In reply to comment #38)
Interestingly, while the change in Comment 37 eliminates the failures in
gcc.dg/torture/builtin-math-7.c, it introduces the failures...
FAIL: gcc.c-torture/execute/20020412-1.c
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2010-04-11
15:24 ---
Has the issue in Comment 33/38 been reported on radar? If so, let me know the
radar problem number and I'll ping the dsymutil developer at Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #41 from dominiq at lps dot ens dot fr 2010-04-11 15:36 ---
Has the issue in Comment 33/38 been reported on radar?
No. If you want to do it, be my guest!-(You got answer to my last one I did not
get, not even an acknowledgement).
--
--- Comment #8 from indy2718 at gmail dot com 2010-04-11 17:31 ---
reduced the test.cpp case to:
struct B
{
public:
int _a;
};
void func()
{
[](const B b) - const int { return b._a; };
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43641
--- Comment #32 from sherpya at netfarm dot it 2010-04-11 17:38 ---
I've repeated the test multiple times, I already done scan benchmarks before
I think I need to check if I have same results on linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
struct A
{
int const i;
};
void f ()
{
A a; // not accepted: OK
A aa[ 1 ]; // incorrectly accepted
}
--
Summary: uninitialized const member incorrectly accepted, using
an array
Product: gcc
Version: 4.6.0
Status:
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-11 18:02 ---
looks like we have a patch...
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #1 from fabien dot chene at gmail dot com 2010-04-11 18:04
---
related to PR 25811.
Mine. (it should be great if someone could grant me the access to the 'assign
bug' checkbox).
--
fabien dot chene at gmail dot com changed:
What|Removed
--- Comment #15 from rguenther at suse dot de 2010-04-11 18:08 ---
Subject: Re: [4.3 Regression] possible wrong
code bug
On Fri, 9 Apr 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #14 from jakub at gcc dot gnu dot org 2010-04-09 18:24
---
Testcase distilled
$ cat test1.cpp
templatetypename X
void zzz(X const x) {
return;
}
struct ttt_t {
static int const static_const_int=0;
int func()const {
zzz(static_const_int);
return 0;
}
};
int main() {
return ttt_t().func();
}
$ g++ -O test1.cpp --save-temps
#no errors
$ g++
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-11
19:10 ---
Revised patch posted at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00533.html. I do see any
combination of options for otool which would give us the required exported
symbol list. In any case, this
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-04-11
19:11 ---
(In reply to comment #3)
s/do/do not/g
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-11 19:22 ---
You need a proper definition for the constant.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-11 19:23 ---
Use a bugzilla account with your @gcc.gnu.org address.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-11 19:28 ---
Well, I believe --with-system-zlib is a promise. Thus, I think this bug is
invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-11 19:53 ---
TREE_USED is not redundant. The patch looks good to me, though I can't approve
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
--- Comment #2 from ubizjak at gmail dot com 2010-04-11 20:35 ---
Works with -fno-omit-frame-pointer. We expand to:
(insn 8 7 0 pr43653.c:4 (set (reg:V2DI 61 [ vect_cst_.2 ])
(vec_duplicate:V2DI (reg/f:DI 54 virtual-stack-vars))) 1700
{*vec_dupv2d
i} (nil))
(insn 9 8 0
Consider the following code:
int divmod(int a, int b)
{
int q = a / b;
int r = a % b;
return q + r;
}
For an ARM EABI target, this results in one __aeabi_idivmod() call and one
__aeabi_idiv() call even though the former already calculates the quotient.
--
Summary:
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-11 22:52 ---
It's possible that the message from dsymutil is misleading:
Is this correct ?
I'm very new to dwarf - but it looks like the DW_AT_upper_bound is missing a
value?
.byte 0x6 # uleb128 0x6; (DIE (0x10d)
--- Comment #33 from steven at gcc dot gnu dot org 2010-04-11 22:59 ---
A common mistake is to not pass the optimizer flags properly to the linker.
There is a thread about that, too:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00438.html
--
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-04-11
23:07 ---
Hopefully the final revision posted at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00539.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-11
23:42 ---
Opened radar://7851516 and have pinged the Apple dsymutil maintainer to take a
look.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #34 from sherpya at netfarm dot it 2010-04-11 23:58 ---
good point :) it should be written in caps, it's not common usage of linking
flags :)
anyway the reason is easy to understand
results aren't exactly as expected by at least not crazy :)
--- SCAN SUMMARY
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-12 00:55 ---
this causes the message at any optimization 0.
which kinda points to variable length arrays as the issue (wherever that issue
is).
extern long random(void);
int main(int ac,char *av[])
{
int n = random();
int
--- Comment #26 from rob1weld at aol dot com 2010-04-12 01:54 ---
(In reply to comment #25)
I understand that this is INVALID because all the points raised by comment
#21.
If crlibm is better than what we have, but we cannot use it, it is the same as
if it didn't exist.
It is
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-04-12
01:54 ---
The response from the dsymutil maintainer was...
The warning was cause for alarm, and the root cause has been fixed (checked
in), though it isn't affecting your test case.
If you see this type of warning
--- Comment #5 from rob1weld at aol dot com 2010-04-12 02:23 ---
(In reply to comment #4)
Rob, this is very old. Is it still a problem?
Thank you kindly for being the one to reply to my Report.
Due to the fact that it often takes a year for some replies, and in this case
three years,
Giving GCC 4.4.3 the following code with the arguments -O1 -mcpu=cortex-a8
-mfpu=neon -mfloat-abi=softfp:
#include stdio.h
#include arm_neon.h
void printv_f32(const float32x4_t v)
{
printf(%f\n, vgetq_lane_f32(v, 0));
}
int
--- Comment #1 from liranuna at gmail dot com 2010-04-12 03:24 ---
I would like to add that changing
void printv_f32(const float32x4_t v)
into:
void printv_f32(float32x4_t v)
makes the problem go away, but the generated code is suboptimal.
--
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-04-12
03:25 ---
I confirmed with the dsymutil maintainer that my reading of his response was
correct. Indeed, the warning may or may not be significant and has to be
checked for each instance. So if all four test cases
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-12
03:31 ---
Third (and hopefully really the final) revision of the patch posted at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00545.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
--- Comment #6 from pzhao at gcc dot gnu dot org 2010-04-12 03:43 ---
Subject: Bug 36774
Author: pzhao
Date: Mon Apr 12 03:43:21 2010
New Revision: 158214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158214
Log:
gcc/
2010-04-12 Shujing Zhao pearly.z...@oracle.com
PR
--- Comment #1 from astrange at ithinksw dot com 2010-04-12 03:54 ---
Still the case with 4.5.
arm-none-linux-gnueabi-gcc -Os -S divmod.c
cat divmod.s
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
Source:
struct s { int i; } __attribute__((packed));
int a(struct s *s)
{
return s-i;
}
Using 4.5:
/usr/local/gcc-arm/bin/arm-none-linux-gnueabi-gcc -Os -mcpu=cortex-a8 -S
unaligned.c
cat unaligned.s
.cpu cortex-a8
.fpu softvfp
.eabi_attribute 20, 1
--- Comment #7 from pzhao at gcc dot gnu dot org 2010-04-12 04:00 ---
Fixed on trunk.
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from siarhei dot siamashka at gmail dot com 2010-04-12
05:26 ---
(In reply to comment #1)
mov r3, #0
vdup.32 d16, r3
Also maybe veor.32 d16, d16, d16 here?
Or drop this NEON register initialization completely because it is a redundant
operation
The intrinsic family for vdupq_n_XXX with argument of 0.
The code generated is:
mov r0, #0
vdup.32 q8, r0
Instead of the faster
veor.32 q8, q8, q8
Thing to note is that GCC will use xorps on x86[_64] for SSE when using
_mm_setzero_ps() or _mm_set1_ps(0).
--
51 matches
Mail list logo
