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 r
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 care about the warnings, why not just use -
no_warn_compac
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 Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote:
> yes, but i think that the reason this is a pr is that it seems to be needed
> for correctness.
Note that df_get_bb_dirty is defaulting to "return false", not
"abort". This is what tricked crossjumping and caused the bug.
If I can get hold o
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
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
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
On 03/19/2011 05:19 AM, Paolo Bonzini wrote:
On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote:
yes, but i think that the reason this is a pr is that it seems to be needed
for correctness.
Note that df_get_bb_dirty is defaulting to "return false", not
"abort". This is what tricked crossjum
On Fri, Mar 18, 2011 at 5:09 PM, Rainer Orth
wrote:
> I noticed that gcc.dg/vect/slp-multitypes-2.c is failing on Solaris
> 8/x86 with Sun as:
>
> FAIL: gcc.dg/vect/slp-multitypes-2.c (test for excess errors)
> WARNING: gcc.dg/vect/slp-multitypes-2.c compilation failed to produce
> executable
>
>
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
/opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
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 Zadeck
> >wrote:
> >>yes, but i think that the reason this is a pr is that it seems to be needed
> >>for correctness.
> >Note that df_get_bb_
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 ta
On Sat, Mar 19, 2011 at 12:29 AM, Joseph S. Myers
wrote:
> This week's London WG14 meeting decided that typedef redefinition
> should not be allowed in the case of variably modified types. This
> patch implements this, giving an error for such redefinitions.
>
> Bootstrapped with no regressions o
On Sat, Mar 19, 2011 at 01:20:41PM +0100, Richard Guenther wrote:
> On Sat, Mar 19, 2011 at 12:29 AM, Joseph S. Myers
> wrote:
> > This week's London WG14 meeting decided that typedef redefinition
> > should not be allowed in the case of variably modified types. This
> > patch implements this, gi
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 Zadeck wrote:
yes, but i think that the reason this is a pr is that it seems to be needed
for cor
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 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 wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32b
On 03/19/2011 09:01 AM, Jakub Jelinek wrote:
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_dirt
On Thu, Mar 17, 2011 at 5:21 AM, FX 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 strlen()
> 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 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
> cant_combine_
On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek 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 wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32b
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.)
Thi
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)
On Fri, Mar 18, 2011 at 10:08 PM, Richard Henderson wrote:
> On 03/18/2011 01:40 PM, Uros Bizjak wrote:
>> if (mode == SFmode)
>> - insn = gen_truncxfsf2 (operands[0], reg);
>> + insn = gen_truncxfsf2;
>> else if (mode == DFmode)
>> - insn = gen_truncxfdf2 (operands[0], r
Steve Kargl wrote:
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/msg000
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.
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 elemental
functions as well. I have also added an option which allo
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 tha
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
* trans-decl.c (gfc_generate_function_code): Call cgraph_create_node
instead of cgraph_get_create_node.
Index: src/gcc/for
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,
thi is really only based on successful testing and not much analyzis
of the context but it seems that we don't need lazy node construction
here. It would be nice not to have it after the big patch gets in.
Thanks,
Martin
2011-03-18 Martin Jambor
* objc-act.c (mark_referenced_m
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 1
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 c
... 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
* testsuite/lib/libstdc++.exp (check_v3_target_c
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 el
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 app
2011-03-19 Jakub Jelinek
* 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 another question i
On Sat, 19 Mar 2011, Jakub Jelinek wrote:
> > I think it should go into 4.6.0 as well.
>
> Seconded.
I have now committed both patches to 4.6 branch after bootstrap there with
no regressions on x86_64-unknown-linux-gnu, and applied this release notes
patch to note that these changes to semanti
On Sun, Mar 20, 2011 at 10:58:23AM +0800, harryxiyou wrote:
> On Sun, Mar 20, 2011 at 4:18 AM, Gerald Pfeifer 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 don't know
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
PR libgfortran/48030
* io/read.c (read_x): Re-implement using fbuf_getc.
Inde
44 matches
Mail list logo
