If it is just for C++ placement new, why don't implement it as a lang_hook.
Now other languages such as C have to be made conservative and produce worse
code.
Bingfeng
-Original Message-
From: Richard Biener [mailto:rguent...@suse.de]
Sent: 31 January 2014 19:44
To: Bingfeng Mei; gcc@gc
On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
> If it is just for C++ placement new, why don't implement it as a lang_hook.
> Now other languages such as C have to be made conservative and produce worse
> code.
Even in C++ code you don't use placement new that often, so e.g. by hav
Status
==
After two months of Stage 3 the trunk is now in release-branch mode
which means only patches fixing regressions and documentation issues
are appropriate.
We're getting a lot of bugs fixed and thus the quality data below
shows we are on track for a release around the beginning of Ap
On 02/03/2014 10:59 AM, Jakub Jelinek wrote:
On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
If it is just for C++ placement new, why don't implement it as a lang_hook.
Now other languages such as C have to be made conservative and produce worse
code.
Even in C++ code you don't u
On Mon, 3 Feb 2014, Jakub Jelinek wrote:
> On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
> > If it is just for C++ placement new, why don't implement it as a lang_hook.
> > Now other languages such as C have to be made conservative and produce worse
> > code.
But if you combine a
On Mon, 3 Feb 2014, Florian Weimer wrote:
> On 02/03/2014 10:59 AM, Jakub Jelinek wrote:
> > On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
> > > If it is just for C++ placement new, why don't implement it as a
> > > lang_hook.
> > > Now other languages such as C have to be made con
On Mon, 3 Feb 2014, Richard Biener wrote:
> And note that for the case in question we
> can derive non-aliasing because with
>
> p[i] += q[i];
>
> p[i] is both read _and_ written in the same iteration thus
> it cannot have the dynamic type of q[i] before it's stored
> into. Of course data-dep
For the following code, why can load be moved before store instruction? TBAA
still applies even it is an anti-dependency. Somehow alias analysis is
implemented differently in vectorization.
for
int foo (long long *a, short *b, int n)
{
*a = (long long)(n * 100);
return (*b) + 1000;
}
Even I change acc[i] += to acc[i] in the original example,
gcc still generates versioning due to alias. So it clearly
behave differently from scalar code aliasing analysis.
tst3.c:12: note: versioning for alias required: can't determine dependence
between _10->real and *_7
tst3.c:12: note: mark f
On 02/03/2014 11:11 AM, Роман Гареев wrote:
Dear Graphite contributors,
I am new to Graphite and want to find out if I could work on it. Could you
point me to a simple bug, please? I would be very grateful for your advise.
Hi,
maybe this bug seems a good start:
http://gcc.gnu.org/bugzil
On Mon, 3 Feb 2014, Bingfeng Mei wrote:
> For the following code, why can load be moved before store instruction?
> TBAA still applies even it is an anti-dependency. Somehow alias analysis
> is implemented differently in vectorization.
>
> for
> int foo (long long *a, short *b, int n)
> {
>
Thanks, Richard,
I think I can follow your logic. That patch works for my example. BTW, I have
a bug report (pr60012), if you are to check in the patch.
Should I also report the scalar example as a bug? It looks innocuous per se :-).
Bingfeng
-Original Message-
From: Richard Biener [mail
On Mon, 3 Feb 2014, Bingfeng Mei wrote:
> Thanks, Richard,
> I think I can follow your logic. That patch works for my example. BTW, I have
> a bug report (pr60012), if you are to check in the patch.
Thanks.
> Should I also report the scalar example as a bug? It looks innocuous per
> se :-).
I
Hi,
On Mon, 13 Jan 2014 10:26:03, Joey Ye wrote:
>
> Bernd,
>
> If that's the case, can you please firstly fix invoke.texi where the
> behavior of strict-volatile-bitfields is described? At least my
> interpretation of current doc doesn't explain the behavior of the case
> we are discussing. Also
Ping ?
On Fri, Jan 31, 2014 at 12:47 AM, Prathamesh Kulkarni
wrote:
> Hi, I was wondering if it's a good idea to add -Wheader-guard option
> that warns on mismatches between #ifndef and #define lines
> in header guard, similar to -Wheader-guard in clang-3.4 ?
> (http://llvm.org/releases/3.4/tools
On 2014.02.04 at 12:36 +0530, Prathamesh Kulkarni wrote:
> Ping ?
Patches should be posted to the gcc-patc...@gcc.gnu.org list.
Please follow up there.
--
Markus
Hello,
the PR 59150 seems to be fixed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150
On arm-rtems (this is virtually the same as ARM EABI) I get the following test
failure:
spawn -ignore SIGHUP
/scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../xg++
-B/scratch/git-rtems-t
17 matches
Mail list logo
