On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
Xcode 4.0's linker now defaults on...
-warn_compact_unwind
So, if this is a flag, and we can turn the warning off, and we truly don't care
about the warnings, why not just use -no_warn_compact_unwind? That would be
preferable, I think.
On Mar 18 2011, Tobias Burnus wrote:
Thomas Koenig wrote:
+ if (!(*e)-value.function.esym-attr.pure
+ !(*e)-value.function.esym-attr.implicit_pure
+ !(*e)-value.function.esym-attr.elemental)
+ return 0;
I have not followed the discussion nor have I fully read the
On Wed, Mar 16, 2011 at 10:05:41AM -0700, Benjamin Kosnik wrote:
Here's the 4_6-branch version, approved by Jakub.
Comparing the additions in x86_64-linux libstdc++, I still see a couple of
wrong exports, in particular since gcc 4.5 the following symbols
_ZTIn@@CXXABI_1.3 OBJECT WEAK DEFAULT
On Sat, Mar 19, 2011 at 10:19:04AM +0100, Jakub Jelinek wrote:
On Wed, Mar 16, 2011 at 10:05:41AM -0700, Benjamin Kosnik wrote:
Here's the 4_6-branch version, approved by Jakub.
Comparing the additions in x86_64-linux libstdc++, I still see a couple of
wrong exports, in particular since
On Fri, Mar 18, 2011 at 11:22:11PM -0700, Mike Stump wrote:
On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
Xcode 4.0's linker now defaults on...
-warn_compact_unwind
So, if this is a flag, and we can turn the warning off, and we truly don't
care about the warnings, why not just
On Sat, Mar 19, 2011 at 08:52:32AM +, IainS wrote:
On 19 Mar 2011, at 06:22, Mike Stump wrote:
On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
Xcode 4.0's linker now defaults on...
-warn_compact_unwind
So, if this is a flag, and we can turn the warning off, and we truly
don't
Paolo,
The test 26_numerics/random/binomial_distribution/operators/values.cc fails
on *-apple-darwin* (see
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01893.html)
with
[macbook] f90/bug% g++47
Hi,
The test compiles and runs if I add -D_GLIBCXX_USE_C99_MATH_TR1:
Unfortunately I cannot debug the issue over the next few hours. If you are
willing to further help I suggest checking why the dg-require I addes and used
exactly because of that doesn't automatically skip the testcase on
On 03/19/2011 08:15 AM, Jakub Jelinek wrote:
On Sat, Mar 19, 2011 at 08:08:48AM -0400, Kenneth Zadeck wrote:
On 03/19/2011 05:19 AM, Paolo Bonzini wrote:
On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeckzad...@naturalbridge.com wrote:
yes, but i think that the reason this is a pr is that it
On Sat, Mar 19, 2011 at 08:48:55AM -0400, Kenneth Zadeck wrote:
i think that there are two separate questions here:
1) should your original patch go in as you did it, or should it go
in with the last return false be an abort?
bool
df_get_bb_dirty (basic_block bb)
{
return bitmap_bit_p
On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson r...@redhat.com wrote:
On 03/18/2011 02:56 PM, H.J. Lu wrote:
X86 backend uses Pmode for hardware pointer size.
On Thu, Mar 17, 2011 at 5:21 AM, FX fxcoud...@gmail.com wrote:
Thanks for the review!
- Use the type size_t for tempdirlen as that is the return type of
strlen() and argument type for get_mem().
- You can use a const size_t variable for the length of the string
slash rather than calling
The new test failed on Linux/x86.
Yes, it might if you have a low limit on the number of concurrently open files.
I've lowered the number to 30 (revision 171180).
FX
On Fri, Mar 18, 2011 at 3:39 PM, Richard Henderson r...@redhat.com wrote:
On 03/18/2011 02:51 PM, H.J. Lu wrote:
See analysis in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47502
You're patching the wrong place. See can_combine_p,
which can test for specific sources, rather than
On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson r...@redhat.com wrote:
On 03/18/2011 02:56 PM, H.J. Lu wrote:
X86 backend uses Pmode for hardware pointer size.
This patch adds a first support for a coarray communication library.
Note: The patch does not yet allow communication (i.e. access to remote
coarrays); thus it is only of limited practical use. (If you restrict
yourself to barriers and this_image/num_images, you can already
parallelize.)
On Sat, Mar 19, 2011 at 05:23:17PM +0100, Tobias Burnus wrote:
My idea is to place those library into libgfortran/caf. The user has to
compile them themselves and link it then to their gfortran
-fcoarray=lib compiled program. (Cf.
http://gcc.gnu.org/ml/fortran/2011-03/msg3.html).
See
On Fri, 18 Mar 2011, Richard Guenther wrote:
! @item --with-plugin-ld=@var{pathname}
! Enable an alternate linker to be used at link-time optimization (LTO)
! link time when @option{-fuse-linker-plugin} is enabled.
I will admit that link-time optimization link time may be a bit
confusing. ;-)
Hi Tobias,
void
_gfortran_caf_init (int *argc, char ***argv, int *this_image, int *num_images)
{
int flag;
/* The following is only the case if one does not have a Fortran
main program. */
MPI_Initialized (flag);
if (!flag)
MPI_Init (argc, argv);
[...]
}
/*
Hi,
I believe the general consensus is that lazy call graph node creation
is no longer a good idea and a few of us have seen bugs caused by a
creation of a node when we did not expect it. Therefore I embarked on
getting rid of it. In the process I quickly realized it would be
difficult to do
Hi,
it seems to me that fortran can call cgraph_create_node directly
without checking for its existence first.
Thanks,
Martin
2011-03-18 Martin Jambor mjam...@suse.cz
* trans-decl.c (gfc_generate_function_code): Call cgraph_create_node
instead of cgraph_get_create_node.
I concede that my understanding of the C++ front-end inner workings
are quite narrow and so the folling is basically a suggestion. But it
seems to me that at a few places where C++ queries the call graph for
a node, the lazy node creation is not necessary. If a maintainer can
verify and approve
Hi,
I hope I explained everything in the introductory email. This patch
is the core, the subsequent ones are only small tweaks in the front
ends.
Let me remind you this is to be applied on top of
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01170.html. (I have
tested the patch on top revision
I've committed this patch to note a change in G++, as requested in the
comments of PR c++/44499
Index: htdocs/gcc-4.6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v
retrieving revision 1.114
diff -u -r1.114
... turns out, something insane is going on with name: if I use
*c99_math anywhere the dg-require is totally ignored. For the time being
I'm simply renaming everything per the below.
Paolo.
//
2011-03-19 Paolo Carlini paolo.carl...@oracle.com
*
On Tue, 15 Feb 2011, Mingjie Xing wrote:
The mirror site in China is unavailable for a long time. I believe it
is helpful if we can have one, though I don't know the requirements of
being a mirror.
Indeed; for the time being I am removing this mirror per the patch
below. David, if you can
On Saturday 19 March 2011 19:59:56 Thomas Koenig wrote:
Am 19.03.2011 00:23, schrieb Tobias Burnus:
I have not followed the discussion nor have I fully read the patch, but
what's the reason for allowing ELEMENTAL functions?
Here's an updated version of the patch, which removes the
Hi Ralf,
Ralf Wildenhues wrote:
Some MPI implementations require that the thread that called MPI_Init
also calls MPI_Finalize. How can this be ensured in this case?
Well, the front-end only calls (via the wrapper) MPI_Finalize for STOP
and at the end of the main program. However, the end of
Hi,
The attached patch is to work around PR debug/48178 on SH
which causes ~2000 failures in the test for sh4-unknown-linux-gnu.
s390 has avoided the same issue with the target specific patch
and the patch below is quite similar with it.
Tested with make -k check on sh4-unknown-linux-gnu and
2011-03-19 Jakub Jelinek ja...@redhat.com
* config/abi/pre/gnu.ver (CXXABI_1.3): Don't export _ZT[IS][PK]*[no].
(CXXABI_1.3.5): Export _ZTI[PK]*[no].
This looks good to me, nice catch. I'll figure out what happened with
check_abi when I'm back, conductivity-wise.
And:
And
On Sun, Mar 20, 2011 at 10:58:23AM +0800, harryxiyou wrote:
On Sun, Mar 20, 2011 at 4:18 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Tue, 15 Feb 2011, Mingjie Xing wrote:
The mirror site in China is unavailable for a long time. I believe it
is helpful if we can have one, though I
Hi,
The attached patch re-implements read_x using fbuf_getc. Self explanatory.
Regression tested on x86-64 linux. No new test case needed.
Ok for trunk?
Regards,
Jerry
2011-03-19 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/48030
* io/read.c (read_x): Re-implement
32 matches
Mail list logo
