Dear Tobias,
That's fine - OK for trunk.
Thanks for the patch!
Paul
On 27 December 2012 23:16, Tobias Burnus bur...@net-b.de wrote:
*ping*
http://gcc.gnu.org/ml/fortran/2012-12/msg00167.html
Tobias Burnus:
Fix one of the remaining issues of PR 55763: MOVE_ALLOC with CLASS(*)
either for
Hi all,
here is a close-to-obvious patch for an ICE-on-invalid problem with
ASSOCIATED: The relevant checks to catch the error were already there,
but were not reached due to a gcc_assert(0) appearing earlier. The
patch basically just removes the gcc_assert.
Regtested on
Joseph, Maxim, thank you for your input. I converted this macro into
a target hook as you said. I had to add gcc/config/linux-protos.h in order
to declare linux (that works for android) version of this hook - otherwise
I don't know where to declare it..
--- a/gcc/config/i386/i386.c
+++
Hello!
New processors core-avx and core-avx2 are added. It was done to have
possibilities to turn new features on for these processors. Please review.
I don't think this is a good approach, you are mixing an architecture
with an ISA extension in the name. We already have
processor_alias_table,
Hi Janus,
Janus Weil wrote:
here is a close-to-obvious patch for an ICE-on-invalid problem with
ASSOCIATED: The relevant checks to catch the error were already there,
but were not reached due to a gcc_assert(0) appearing earlier. The
patch basically just removes the gcc_assert.
Regtested on
On 28 December 2012 01:51, Lawrence Crowl wrote:
I'm not getting errors when converting from derived to base.
E.g. the following compiles, when it should not.
std::unique_ptrconst base [] acb_ad(new derived[3]);
I get an error:
shm$ cat up.cc
#include memory
struct base { };
struct derived
here is a close-to-obvious patch for an ICE-on-invalid problem with
ASSOCIATED: The relevant checks to catch the error were already there,
but were not reached due to a gcc_assert(0) appearing earlier. The
patch basically just removes the gcc_assert.
Regtested on x86_64-unknown-linux-gnu. Ok
971
/tmp/20121227/gcc/testsuite/g++/../../xg++ version 4.8.0 20121228
(experimental) [trunk revision 194742] (GCC)
=== gcc tests ===
Running target unix
FAIL: gcc.c-torture/execute/loop-5.c compilation, -O3
-fomit-frame-pointer -funroll-loops
UNRESOLVED: gcc.c-torture/execute/loop
David,
Support for native TLS on AIX exposed a problem with this patch. A
similar problem exists on Solaris 9.
Some helper functions for TLS on AIX and Solaris 9 only are provided
by libpthread. Promoting ic related variables to TLS breaks profiling
of non-pthread appications. I completely
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
It would be nice to finally move
the call to cgraph_finalize_compilation_unit to the middle-end ...
(warning, if you try
On 12/27/2012 05:51 PM, Jerry DeLisle wrote:
Hi,
The attached patch fixes this problem by not calling hit_eof if EOF can be a
valid separator.
Regression tested on x86-64.
OK for trunk with test case from PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle jvdeli...@gcc.gnu.org
PR
Is there a way to tell if the program is going to be multi-threaded?
If not, it might be useful to introduce a compiler option such as -fmt
which also enables -lpthread. Using tricks like weakrefs can
introduce unnecessary runtime overhead.
David
On Fri, Dec 28, 2012 at 8:26 AM, David Edelsohn
Hi Honza,
In the other thread of discussion (similar patch in google-4_7
branch), you said you were thinking if to let this patch into trunk in
stage 3. Can you give some update?
Thanks,
-Rong
On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu x...@google.com wrote:
On Fri, Dec 21, 2012 at 1:25 AM,
It would be great if this can make into gcc4.8. The patch has close to
0 impact on code stability.
David
On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu x...@google.com wrote:
Hi Honza,
In the other thread of discussion (similar patch in google-4_7
branch), you said you were thinking if to let
Hi, David
The front-end drivers use -pthread and that often adds -lpthread. But
-pthread is not passed to cc1, etc.
I am not certain if there is a way for the compiler to ascertain that
it is being invoked to compile a file intended for a multi-threaded
application. It knows bout OpenMP and
On 12/27/2012 12:08 AM, Uros Bizjak wrote:
The alternative approach is changing cpuid definition in cpuid.h (as
in attached patch) to preserve %rbx, but we can't detect various code
model settings there. Since the change depends on the definition of
__PIC__, we unnecessary preserve %rbx also
In http://gcc.gnu.org/PR54711 Andrew wrote the following:
I am not sure where the sources
for the web pages are. Are they in the GCC source tree somewhere?
Weird, IIRC instructions used to be on the write-access page.
Gerald?
They are on the cvs.html page:
Hello,
processor_alias_table contains the same processor type for all
corei7, corei7-avx, core-avx-i and core-avx2. At least, it has
consequence on checking x86_avx256_split_unaligned_load
ix86_tune_mask: for all these processors it results the same. Moreover
we cannot turn new features on for
18 matches
Mail list logo
