>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk?
Looks mostly OK, but I have one question: I don’t understand what the wording
"Type IMPLICIT NONE statement” is supposed to mean. Why “type”?
FX
FX wrote:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Looks mostly OK, but I have one question: I don’t understand what the wording
"Type IMPLICIT NONE statement” is supposed to mean. Why “type”?
Well, I want to distinguish "IMPLICIT NONE (external)" which only
applies to proc
> If you have a better suggestion for the wording …
I’d suggest “IMPLICIT NONE (TYPE) statement at %C following an IMPLICIT
statement” (and the other way around).
OK, with or without the wording change, I let you decide
ping
> Hi all,
>
> The attached patch improves our code generation for some of the
> IEEE_ARITHMETIC functions: some testing functions (is*) and some arithmetic
> (logb, rint, scalb, …). The interfaces are still present in the module file
> generated as part of the library (which allows, in p
> In the test case, could you also add a "PR fortran/36534" to the
> as comment?
Sure.
> Additionally, I wonder whether instead of the name-based checking
> + && (sym->name[0] != '_' || sym->name[1] != '_'))
> it wouldn't be cleaner to check
> && sym->attr.intrinsic
> (If you chan
Jakub Jelinek writes:
>> make the result of combining separate .sum files the same as the .sum
>> file you'd get for -j1. As Jakub said upthread, that's a lost cause
>> with the new approach to parallel testing, but I think the comment was
>> valid while matching -j1 was still a goal.
>
> I'm sor
Uros Bizjak writes:
> On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov wrote:
>
> I guess we achieved the consensus about the following patch to fix
> PR61360
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
>
> The patch was successfully bootstrapped and tested (w/
On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford
wrote:
> Uros Bizjak writes:
>> On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov
>> wrote:
>>
>> I guess we achieved the consensus about the following patch to fix
>> PR61360
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Hi!
The following patch does fix random order for new decls generation during
Cilk_spawn generation.
As Jakub suggested in the PR first we deal with vectors, then sort them and
only then perform necessary generation of new decls.
Bootstrapped and regtested on trunk/4.9.
For trunk I couldn't che
Uros Bizjak writes:
> On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford
> wrote:
>> Uros Bizjak writes:
>>> On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov
>>> wrote:
>>>
>>> I guess we achieved the consensus about the following patch to fix
>>> PR61360
>>>
>>> https://gcc.gn
We have a -static-libgfortran option, but on targets where we support quad-prec
math through libquadmath, we didn’t have an equivalent -static-libquadmath so
far. This patch adds it, in what I think is a rather straightforward manner.
The only minor complication comes from the fact that previous
On 3 October 2014 23:29, Manuel López-Ibáñez wrote:
> The following patch adds two new functions. One of them is an overload
> of gfc_warning_cmdline() that takes an option. Thus now we get:
Don't review this one just yet. I must have messed up testing or new
testcases appeared because after doi
The following patch adds two new functions. One of them is an overload
of gfc_warning_cmdline() that takes an option. Thus now we get:
f951: Warning: Nonexistent include directory
'C:\msys\1.0.10\home\FX\ibin\i586-pc-mingw32\libgfortran/../../../trunk/libgfortran/generated'
[-Wmissing-include-dirs
On 10/03/2014 04:11 PM, DJ Delorie wrote:
Note that there is a separate __int128_t type that isn't part of the
"standard" extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
"long" is never 128 bits, it doesn't matter if the int128 test i
On 10/03/2014 05:31 PM, Siva Chandra wrote:
* decl2.c (grokfield): Mark special methods declared as default
to be artificial.
No, defaulted methods are still user-declared, not artificial.
Jason
On 10/03/2014 05:41 PM, Siva Chandra wrote:
I understand that knowing whether a copy-ctor or a d-tor has been
explicitly defaulted is not sufficient to determine the parameter
passing ABI. However, why is it not necessary? I could be wrong, but
doesn't the example I have given show that it is nec
> > Otherwise, I don't see what moving the test would accomplish. If
> > "long" is never 128 bits, it doesn't matter if the int128 test is
> > before or after it, and the other intN are never the same size as
> > standard types,
>
> I don't see how you can assert that these will never happen.
I
On 23/09/2014 13:27, Jonathan Wakely wrote:
Yes, OK for trunk - thanks very much.
Hi
There was in fact one last test failing, ext/profile/mh.cc, a
profile mode specific test. It must have been failing for quite a while
since malloc hooks has been deprecated. It is normally testing the
On 10/03/2014 07:34 AM, Cesar Philippidis wrote:
> On 09/24/2014 12:18 AM, Ilmir Usmanov wrote:
>> Hi Cesar!
>>
>> Thank you for the patch!
>>
>> On 24.09.2014 02:29, Cesar Philippidis wrote:
>>> This patch adds support for the async clause in the wait directive in
>>> fortran. It should be pretty
On 10/02/2014 11:42 AM, Jonathan Wakely wrote:
The library macros are safe and can't cause any issues, so I'm happy for them
to go on the branch.
I can think of at least two that aren't implemented on the branch:
and the std::is_final trait (although I'd be OK with the
trait going on the bra
Hi,
the ICE is caused by duplicate_thunk_for_node not copying DECL_ARGUMENTS in LTO
mode because they are not streamed in. This is gcc-4.9 branch version of the
fix,
I will prepare mainline version shortly.
Bootstrapped/regtested x86_64-linux, comitted.
PR lto/62026
* g++.dg/lto
Hi,
this is 4.9 version of patch fixing ICE on ipa-devirt.c:997.
The problem is that we get TYPE_SIZE NUll but code does not expect it.
Honza
PR ipa/62121
* ipa-devirt.c (restrict_to_inner_class): Do not ICE when type is
unknown.
* g++.dg/torture/pr62121.C: New te
On 9/25/14 8:12, Chen Gang wrote:
> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on
> Qemu, and try to make patches for it).
>
> And, I also need finish the testsuite under Darwin x86_64, next month for gcc.
I finish tried testsuit under Darwin x86_64, originally, I inco
On 10/5/14 11:15, Chen Gang wrote:
> On 9/25/14 8:12, Chen Gang wrote:
>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on
>> Qemu, and try to make patches for it).
>>
>> And, I also need finish the testsuite under Darwin x86_64, next month for
>> gcc.
>
> I finish tried
Hi,
this patch is in mainline for a while, but apparently I forgot to attach
PR info to it, so it did not make it to the release branch.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/61144
* varpool.c (ctor_for_folding): Do not fold WEAK symbols.
* gcc.dg/tr
25 matches
Mail list logo
