--- Comment #11 from iains at gcc dot gnu dot org 2010-04-12 06:57 ---
(In reply to comment #9)
> checked for each instance. So if all four test cases are actually emitting
> valid dwarf, we can drop the usage of -lm on darwin[921]
The two things are totally unrelated - AFAICT the reas
--- Comment #10 from iains at gcc dot gnu dot org 2010-04-12 06:43 ---
(In reply to comment #9)
> 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
--- Comment #6 from manu at gcc dot gnu dot org 2010-04-12 06:41 ---
(In reply to comment #5)
>
> Some three years later we might expect I am unable to assist further and might
> focus my efforts where they are more productive.
Sorry about that. I totally understand your frustration. L
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-04-12
06:17 ---
Or just "vmov.i32 q8, #0" would be better to avoid any potential data
dependency.
--
siarhei dot siamashka at gmail dot com changed:
What|Removed |Added
--
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).
--
--- 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
--- 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
Status|ASSI
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
.ea
--- 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,
--- 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=gcc&view=rev&rev=158214
Log:
gcc/
2010-04-12 Shujing Zhao
PR c/36774
* c-d
--- 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 #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 are
--- 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.
--
http://gcc.gnu.org/bugzilla
Giving GCC 4.4.3 the following code with the arguments "-O1 -mcpu=cortex-a8
-mfpu=neon -mfloat-abi=softfp":
#include
#include
void printv_f32(const float32x4_t &v)
{
printf("%f\n", vgetq_lane_f32(v, 0));
}
int main()
{
--- 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,
--- 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 #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 p
--- 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 x
--- 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 #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 #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 #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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- 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)
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: Failur
--- 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 pr43653
--- 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
--
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 #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=43716
--- 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
--
--- 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 #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 #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 wouldn
$ cat test1.cpp
template
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++ test1.cpp --sav
--- 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 f
--- 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 #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
Key
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: UNCON
--- 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
--- 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 #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).
--
http://gcc.gnu.org/bugzilla/show_bu
--- 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 #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 compi
--- 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
FAIL:
--- 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=20361&action=view)
patch to address issue described in comment #21
The main issue described in this bug is fixed, and it has rightl
--- 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 #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.
--
http://gcc.gnu.org/
--- 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 #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 should
--- 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 g
--- 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...
--- 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 #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
53 matches
Mail list logo
