On Mon, Mar 03, 2014 at 02:14:51PM +1030, Alan Modra wrote:
> I'll post update-copyright.py separately.
--- /src/gcc-current/contrib/update-copyright.py2013-02-07
12:55:28.272161270 +1030
+++ ./update-copyright.py 2014-03-03 13:44:35.650293322 +1030
@@ -74,6 +74,8 @@
Hi,
I saw
http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1
And LLVM/clang beaten gcc in serval tests.But I ran that
tests,e.g.SciMark,it didn't appear to be like this on my i7 machine.Was that
article written by Apple?
--
Regards
lin zuojian
On 03/02/2014 04:55 PM, Fabien Chêne wrote:
Hmm, sorry to iterate on this rather trivial issue, but it seems
difficult to mimic the c++98 diagnostic. Actually, the c++98 diagnosic
raises an error at the point of use, mention the class implied, and
add a note at the ref/const member uninitialized.
On Sun, Mar 02, 2014 at 02:49:20PM -0800, Jerry DeLisle wrote:
>
> For this patch I chose to stay consistent with what we currently do. I can
> change it to standard conforming. Anyone else have any comments on this?
>
I would prefer standard conformance, but I'm not the one doing the
work (so
On 03/02/2014 12:50 PM, Tobias Burnus wrote:
--- snip ---
>
> gfortran seems to be special as it defaults to printing the " (quote)
> delimiter
> by default while other compilers seem to default to "none".
>
Looking back at the draft F95 standard that I have I am amazed. As you stated
in your
Hi,
this patch fixes simple ordering issue in function_and_variable_visibility.
Bootstrapped/regtested x86_64-linux, comitted.
PR ipa/60150
* ipa.c (function_and_variable_visibility): When dissolving comdat
group, also set all symbols to local.
* g++.dg/lto/pr60150.
2014-02-28 22:52 GMT+01:00 Fabien Chêne :
> 2014-02-28 22:27 GMT+01:00 Jason Merrill :
>> Let's change the C++11 diagnostic to match the C++98 diagnostic. So,
>> "uninitialized const member in %q#T" + "%qD should be initialized".
>
> OK.
Hmm, sorry to iterate on this rather trivial issue, but it
Hi,
testcase in this PR shows interesting bug in detect_type_change. The function
basically looks up in the alises walk and tries to find explicit stored to
vtable. If none are found the type is assumed to be fully built. If some are
found and they are all agree, the type is assumed to be in the co
Hello,
inlining operator new (with LTO or otherwise), I noticed that it has a
complicated implementation, which makes it hard to use this inlined code
for optimizations. This patch does two things:
1) there are 2 calls to malloc, I am turning them into just one. At -Os,
it does not change th
Dear Jerry, hi all,
Jerry DeLisle wrote:
The attached patch fixes this by actually implementing it. I cleaned up some of
the code by getting rid of the tmp_delim variables and adding a "mode" to
write_character which is used to ignore delimiters when writing out variable
names and other namelis
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.9-b20140202.sv.po',
On 03/01/2014 08:13 PM, Patrick Palka wrote:
On Sat, Mar 1, 2014 at 7:53 PM, Marc Glisse wrote:
On Sat, 1 Mar 2014, Patrick Palka wrote:
+ error_at (input_location,
+ "redefinition of %q+#D with C language
linkage",
+
Bernd Edlinger wrote:
This patch tries to solve the problem in a more general way, by classifying the
target's expected
result by using vect_element_align and vect_call_sqrtf attributes.
This patch has been tested on armv7l-unknown-linux-gnueabihf,
x86_64-unknown-linux-gnu and
powerpc-apple-d
Ping.
> Subject: [PATCH] Fix fortran/pr60236
> Date: Sun, 23 Feb 2014 14:50:46 +0100
>
> Hi,
>
> the test case gfortran.dg/vect/pr32380.f was found to fail on
> armv7l-unknown-linux-gnueabihf.
> The reason for this is that one out of 6 loops does not get vectorized,
> because this target does
>
> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
> But the implication seems to be that unspec_volatile and volatile asms
> are volatile in different ways. IMO they're volatile in the same way
> and the problems for volatile asms apply to unspec_volatile too.
I disagree
Hi Bernd,
I think about whether the best mode is so important to x86_64.There
is no mov r/m64,imm64 refering to Intel Software Developer's Manual
Volume 2A 3-505.imm32 is the biggest number.And asan clears stack
using imms.
And even if there is a mov r/m64,imm64 in the future.The gcc
16 matches
Mail list logo
