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
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
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 change it to
Jakub Jelinek ja...@redhat.com 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.
Uros Bizjak ubiz...@gmail.com writes:
On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov vmaka...@redhat.com 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
On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Uros Bizjak ubiz...@gmail.com writes:
On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov vmaka...@redhat.com
wrote:
I guess we achieved the consensus about the following patch to fix
PR61360
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
Uros Bizjak ubiz...@gmail.com writes:
On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Uros Bizjak ubiz...@gmail.com writes:
On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov
vmaka...@redhat.com wrote:
I guess we achieved the consensus about the following
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
On 3 October 2014 23:29, Manuel López-Ibáñez lopeziba...@gmail.com 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
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'
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 is
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
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.
It's checked
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 straight
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:
experimental/any and the std::is_final trait (although I'd be OK with the
trait
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
*
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
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
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 testsuit
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.
*
25 matches
Mail list logo
