Recently, I was debugging an issue in the GCC/UPC front-end
that related to some problems compiling specific UPC type
declarations. The front-end was, in certain cases, dropping
UPC's "shared" qualifier.
The relevant code is in grokdeclarator:
if (!flag_gen_aux_info && (TYPE_QUALS (element_typ
Samuel Tardieu wrote:
> Yes, this is exactly what I was thinking: cover more configurations. For
> example, in the engineering school where I teach, we have many ARM boards
> with different CPUs, and we would really like to have a single cross-compiler
> that our students can use or install on the
On 05/19/09 12:10:43, Andrew Pinski wrote:
> Gary wrote:
> > Is the __thread feature now more universally/portably
> > supported?
>
> Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
> expand_expr_real_1 in expr.c.
> [...] for the emulated support which is
> implemented on th
Snapshot gcc-4.4-20090519 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090519/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Rebuilt using GNU as and ld and the number
of libgomp failure came down to 18 from 80:
=== gcc Summary ===
# of expected passes50313
# of unexpected failures14
# of unexpected successes 3
# of expected failures 231
# of unsupported tests
On Tue, May 19, 2009 at 12:04 PM, Gary Funck wrote:
> On 05/19/09 11:29:57, Andrew Pinski wrote:
>> On Tue, May 19, 2009 at 11:25 AM, Gary Funck wrote:
>> >
>> > For UPC code generation, we're building an alternate
>> > method of accessing thread-local data that does not depend upon
>> > operatin
On 05/19/09 11:29:57, Andrew Pinski wrote:
> On Tue, May 19, 2009 at 11:25 AM, Gary Funck wrote:
> >
> > For UPC code generation, we're building an alternate
> > method of accessing thread-local data that does not depend upon
> > operating system support of the __thread qualifier.
>
> GCC has alr
On Tue, May 19, 2009 at 11:25 AM, Gary Funck wrote:
>
> For UPC code generation, we're building an alternate
> method of accessing thread-local data that does not depend upon
> operating system support of the __thread qualifier.
GCC has already added generic support for the __thread qualifier whi
For UPC code generation, we're building an alternate
method of accessing thread-local data that does not depend upon
operating system support of the __thread qualifier.
The motivation for this change is that we've noticed that
__thread has varying levels of support across operating
system/hardwar
Richard Guenther wrote:
>> - The tree alias oracle got similar functionality, refs_anti_dependent
>>and refs_output_dependent and the tree level data dependence
>>analysis code makes use of these.
Do we still use TBAA for the original motivating reason for adding it,
e.g.,:
void f(flo
Dave Korn wrote:
> Doing a parallel make in an entirely new and freshly-configured $objdir, the
> first thing I see is:
>
> $ make -j4 2>&1 | tee build-parallel.log
> sed: can't read stage_last: No such file or directory
> [ -f stage_final ] || echo stage3 > stage_final
>
>
> Does everyone g
Doing a parallel make in an entirely new and freshly-configured $objdir, the
first thing I see is:
$ make -j4 2>&1 | tee build-parallel.log
sed: can't read stage_last: No such file or directory
[ -f stage_final ] || echo stage3 > stage_final
Does everyone get this, or do I have a platform-r
On Tue, May 19, 2009 at 11:18, Joseph S. Myers wrote:
> On Tue, 19 May 2009, Eric Fisher wrote:
>
>> Hello,
>>
>> I have the libelf installed in a non-standard path, so when I build
>> the lto branch, I set the such env variables,
>>
>> $ export CPPFLAGS="-I" <- Only needed if
>> libelf is in a n
On Tue, 19 May 2009, Eric Fisher wrote:
> Hello,
>
> I have the libelf installed in a non-standard path, so when I build
> the lto branch, I set the such env variables,
>
> $ export CPPFLAGS="-I" <- Only needed if
> libelf is in a non-standard path
> $ export LDFLAGS="-L" <- Only needed i
On Tue, May 19, 2009 at 10:30, Diego Novillo wrote:
> Maybe I could skip step #1 and always define LTO_TORTURE_OPTIONS?
> Then it's up to every individual .exp file to decide if it wants
> to add LTO to the mix.
Actually, scratch this idea. This is still needed to protect against
builds that do
On Mon, May 18, 2009 at 13:16, Janis Johnson wrote:
> Implement check_effective_target_lto to report whether LTO is supported
> and check that when setting up TORTURE_OPTIONS in one of the files in
> gcc/testsuite/lib/*.exp. Look at fortran-torture.exp, which adds
> options for vectorization if
On Fri, 8 May 2009, Richard Guenther wrote:
>
> This adjusts the middle-end memory model to properly honor type-based
> aliasing rules set by the C and C++ standards.
>
> The bulk of the patch gets rid of our previous attempts to fix
> the issues around placement new and friends, CHANGE_DYNAMIC_
Ben Elliston wrote:
> On Tue, 2009-05-19 at 14:57 +0200, Richard Guenther wrote:
>
>> The patch is ok.
>
> I fell off the Cc: list, but I assume you are talking to me. :-)
Sorry, I forked the thread, but I did change the subject! :)
cheers,
DaveK
On Tue, 2009-05-19 at 14:57 +0200, Richard Guenther wrote:
> The patch is ok.
I fell off the Cc: list, but I assume you are talking to me. :-)
Thanks,
Ben
Andrew Haley wrote:
> Dave Korn wrote:
>> Ben Elliston wrote:
>>> This patch silences the following warnings when building libgcc:
>>>
>>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x-
On Tue, May 19, 2009 at 2:44 PM, Andrew Haley wrote:
> Dave Korn wrote:
>> Ben Elliston wrote:
>>> This patch silences the following warnings when building libgcc:
>>>
>>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>
>>> - const _Unwind_
Dave Korn wrote:
> Ben Elliston wrote:
>> This patch silences the following warnings when building libgcc:
>>
>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>
>> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x->pc_begin;
>> - const _U
Ben Elliston wrote:
> This patch silences the following warnings when building libgcc:
>
> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x->pc_begin;
> - const _Unwind_Ptr y_ptr = *(const
Hello all,
I recently encountered a strange performance drop on a test code. I
have two versions of the same code (I believe so at least), one
parallelized with OpenMP pragmas and one other manually parallelized
with pthread. The test machine is made of a Intel Core i7 920
processor (x86_64, 4 cor
On Tue, May 19, 2009 at 02:29, Eric Fisher wrote:
> I look into the Makefile and find that LDFLAGS is set as BOOT_LDFLAGS
> scine stage2, so I have to set this variable also.
>
> Is it a right way that it should go?
Yes, thanks for catching this. I will update the wiki.
Diego.
On Tue, May 19, 2009 at 2:02 AM, Daniel Berlin wrote:
> On Sat, May 16, 2009 at 5:49 AM, Richard Guenther
> wrote:
>> On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost
>> wrote:
>>>
>> I think it is useful to have a bugzilla here.
>
> will do.
>>>
>>> http://gcc.gnu.org/bugzilla/
2009/5/19 Ian Lance Taylor :
> Ben Elliston writes:
>
> Yep, a bug. Looks like it should be something like
So 2 bugs now found by -Wlogical-op. Well, at least, it was not a
_total_ failure. :-)
Cheers,
Manuel.
27 matches
Mail list logo
