Dear Tobias,
That's fine - OK for trunk.
Thanks for the patch!
Paul
On 27 December 2012 23:16, Tobias Burnus 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 both
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 x86_64-unknown-linux-gnu.
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
>> +++ b/gcc
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 x86
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_ptr acb_ad(new derived[3]);
I get an error:
shm$ cat up.cc
#include
struct base { };
struct derived : base { virtua
>> 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-li
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 agre
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,
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
PR libfortran/55818
* io/lis
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 wrote:
> On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka wrot
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 wrote:
> 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
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 __thr
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 als
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:
http://gcc.gnu.org
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
18 matches
Mail list logo
