http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50023
--- Comment #4 from Dominique d'Humieres 2012-01-09
21:11:35 UTC ---
> To me it seems it was committed 10.10.2011. Here the relevant commit:
> http://gcc.gnu.org/viewcvs?view=revision&revision=179762
>
> Does this commit not show up for you?
Obv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50077
--- Comment #1 from Dominique d'Humieres 2012-01-09
21:45:19 UTC ---
I have tested the -mcmodel=large option on some simple C tests and I got the
same kind of failures.
So -mcmodel=large seems broken on x86_64-apple-darwin10 (gcc 4.4.6, 4.5.3, a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51816
Dominique d'Humieres changed:
What|Removed |Added
CC||bur...@net-b.de
--- Comment #2 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51816
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51828
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Dominique d'Humieres changed:
What|Removed |Added
Target|x86_64-apple-darwin10 |x86_64-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830
Bug #: 51830
Summary: FAIL: libitm.c/mem(cpy|set)-1.c execution test
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
--- Comment #17 from Dominique d'Humieres
2012-01-11 21:45:35 UTC ---
> --- Comment #15 from Aldy Hernandez 2012-01-10
> 17:53:25 UTC ---
> Folks, I am going to close this PR since it is a potpourri of failures across
> different architectures,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48754
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013
--- Comment #13 from Dominique d'Humieres
2012-01-12 16:58:36 UTC ---
Closing as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51057
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51848
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #13 from Dominique d'Humieres
2012-01-13 23:02:09 UTC ---
Created attachment 26318
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26318
test findenv
Test of findenv found in
http://www.opensource.apple.com/source/Libc/Libc-498.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #14 from Dominique d'Humieres
2012-01-13 23:11:40 UTC ---
Created attachment 26319
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26319
patch for libgcc/libgcov.c to debug findenv
Patch to use the findenv in
http://www.opensourc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #16 from Dominique d'Humieres
2012-01-13 23:46:47 UTC ---
> disas x
>
> would be interesting here to find out what insn is at 0x29c0 and what is
> around
> that.
0x291b <+0>:push %ebp
0x291c <+1>:mov%esp,%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #25 from Dominique d'Humieres
2012-01-14 11:33:20 UTC ---
> I don't think this is a regression - I think it's been there for(ever/long
> time).
I don't want to waste time arguing about the regression tag, but
gcc.dg/tree-prof/pr44777
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
Dominique d'Humieres changed:
What|Removed |Added
Attachment #25270|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51865
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51865
--- Comment #3 from Dominique d'Humieres 2012-01-15
16:09:20 UTC ---
Created attachment 26333
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26333
preprocessed testcase
> Please attach preprocessed testcase.
r183091 is OK
r183136 gives the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
--- Comment #15 from Dominique d'Humieres
2012-01-15 21:46:37 UTC ---
Between revisions 183030 and 183181,
23_containers/unordered_multiset/erase/24061-multiset.cc has also started to
fail in a similar manner (see
http://gcc.gnu.org/ml/gcc-testre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #37 from Dominique d'Humieres
2012-01-19 11:03:58 UTC ---
Regstrapped with the patch in comment #35. The patch fixes this PR without
regression (down to 2 failures with some pending patches) and the tests for
pr10901 pass with the dif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #4 from Dominique d'Humieres 2012-01-19
20:27:50 UTC ---
On x86_64-darwin10 (Xcode 3.2.6) r183290 is OK.
On powerpc-apple-darwin9 (Xcode 3.1.4) 183218 is OK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
Bug #: 51916
Summary: FAIL: gcc.dg/lto/trans-mem-3
c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link,
-flto (internal compiler error)
Classification: Unclassified
Product
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #25 from Dominique d'Humieres
2012-01-20 15:54:14 UTC ---
On x86_64-apple-darwin10, the patch in comments #22 breaks most of the tests I
have for extends_type_of (3 out of 5) and in the test suite (only
gfortran.dg/extends_type_of_2.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
--- Comment #2 from Dominique d'Humieres 2012-01-20
16:09:11 UTC ---
> I don't have a Darwin machine on which to test the link sequence. Do you mind
> finding out which is the fcode in question? It is a matter of setting a gdb
> breakpoint on t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
--- Comment #26 from Dominique d'Humieres
2012-01-20 16:24:34 UTC ---
I have done a clean bootstrap of r183305 on powerpc-apple-darwin9 with the
patch in comment #25.
Regtesting in progress (allow for ~20 more hours), but gcc at -m32 has only 28
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
--- Comment #4 from Dominique d'Humieres 2012-01-20
19:15:08 UTC ---
> Try building the compiler without optimization (-O0).
I have never done that!-(I guess I have to pass something like CFLAGS and
CXXFLAGS in configure or make). What is the of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
Dominique d'Humieres changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #26 from Dominique d'Humieres
2012-01-21 11:41:15 UTC ---
Running the regression test suite gives:
FAIL: gfortran.dg/coarray_poly_1.f90 -O (internal compiler error)
FAIL: gfortran.dg/coarray_poly_1.f90 -O (test for errors, line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
Bug #: 51934
Summary: FAIL: g++.dg/torture/pr51344.C -O0 (test for excess
errors) on powerpc*-*-*
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #2 from Dominique d'Humieres 2012-01-21
16:15:52 UTC ---
> Also broken on 4.6 and 4.5 branches ...
Mikael can you confirm that the failures are due to the warning "'cdecl'
attribute directive ignored"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #6 from Dominique d'Humieres 2012-01-21
23:15:31 UTC ---
> The test just should use some attribute that is common to all targets, like
> __attribute__((noinline)) or similar, unless it didn't fail with that
> attribute
> before the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #8 from Dominique d'Humieres 2012-01-21
23:58:19 UTC ---
> You mean errors out? format attribute must have 3 arguments.
> Try leaf, or nothrow etc. attributes instead, format is a bad idea for a
> method
> that isn't printf/scanf li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941
Bug #: 51941
Summary: FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51942
Bug #: 51942
Summary: FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times ...
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060
--- Comment #14 from Dominique d'Humieres
2012-01-22 16:42:36 UTC ---
Still failing on trunk r183385!-(see
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg02085.html ).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
--- Comment #17 from Dominique d'Humieres
2012-01-22 16:51:12 UTC ---
Is the test still failing? It does not appear in the
powerpc64-unknown-linux-gnu logs (both -m32 and -m64) at
http://gcc.gnu.org/ml/gcc-testresults/2012-01/ .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
--- Comment #11 from Dominique d'Humieres
2012-01-23 10:21:38 UTC ---
> Yes. Can you please post it to gcc-patches@ and commit it? It's preapproved
> as obviously correct. Thx.
A patch has already been submitted by Patrick Marlier at
http://g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51963
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
Dominique d'Humieres changed:
What|Removed |Added
CC||Greta.Yorsh at arm dot com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
Dominique d'Humieres changed:
What|Removed |Added
Target|powerpc*-*-*|powerpc*-*-* arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941
--- Comment #4 from Dominique d'Humieres 2012-01-23
12:51:06 UTC ---
> > Could some Darwin savvy people confirm that the fix works for them?
>
> As a fix for the test-case this works for me (and, logically, there is no
> reason to exclude darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #13 from Dominique d'Humieres
2012-01-23 14:55:08 UTC ---
> Log:
> PR target/51934
> * g++.dg/torture/pr51344.C: Use noreturn instead of cdecl.
>
> Should be fixed now.
The use of 'noreturn' yields a warning with g++ 4.6.2 an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #15 from Dominique d'Humieres
2012-01-23 15:19:37 UTC ---
> Well, if it hangs before the fix with the noreturn attribute, then it is
> trivial to replace the return a; with for (;;);
It does not hang:
macbook] f90/bug% cat pr51344_d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #17 from Dominique d'Humieres
2012-01-23 15:50:16 UTC ---
> g++.dg/torture/pr51344.C: Limit to x86.
Note that using 'format' instead of 'cdecl' hangs also on
powerpc-apple-darwin9:
[karma] f90/bug% time g++-fsf-4.6 pr51344_db.C
^C0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970
Bug #: 51970
Summary: gimplification failed for an avatar of pr51948
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #19 from Dominique d'Humieres
2012-01-23 22:05:44 UTC ---
> g++.dg/torture/pr51344.C: Limit to x86.
>
> -/* { dg-do compile } */
> +/* { dg-do compile { target { i?86-*-* && ilp32 } } } */
Any reason to limit the test to i?86 and 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823
--- Comment #3 from Dominique d'Humieres 2012-01-24
11:09:05 UTC ---
> It is guaranteed to be non-NULL for omp parallel/do/task and many others, see
> the ew_st.ext.omp_clauses = something lines in openmp.c.
Then is the 'if (clauses)' necessary?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42934
--- Comment #1 from Dominique d'Humieres 2012-01-24
11:41:21 UTC ---
> The following example shows this: For LOC(f) it prints the address of the
> function, for LOC(f()) the result of the function call; but it fails for
This is the case for gfor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
Bug #: 51985
Summary: [4.7 Regression] Bootstrap failure at revision 183497
on x86_64-apple-darwin10
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970
--- Comment #4 from Dominique d'Humieres 2012-01-24
22:35:43 UTC ---
The patch attached to comment #4 + the "hack" let the test compile without
error (although I don't know if it is valid). I have noticed the following
changes:
For 51948, before
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
Dominique d'Humieres changed:
What|Removed |Added
Target||x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
--- Comment #2 from Dominique d'Humieres 2012-01-24
23:16:45 UTC ---
Looking at the log, I see
copying selected object files to avoid basename conflicts... <--- :-(
copying selected object files to avoid basename conflicts...
libtool: link:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
Dominique d'Humieres changed:
What|Removed |Added
Target|x86_64-apple-darwin10 |*-apple-darwin*
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51995
--- Comment #1 from Dominique d'Humieres 2012-01-25
10:59:09 UTC ---
I confirm that on x86_64-apple-darwin10 from
gcc version 4.6.0 20100723 (experimental) [trunk revision 162456] (GCC) up to
now,
gfortran gives the following errors for the test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #4 from Dominique d'Humieres 2012-01-25
12:59:39 UTC ---
> Well, ok, the 2 tests are just different and should raise different errors.
Your original test gives
pr51991.f90:11.11:
j = a%j
1
Error: 'j' at (1) is not a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at redhat dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #7 from Dominique d'Humieres 2012-01-25
13:32:34 UTC ---
> ... I do observe the error reported in my first message with gfortran trunk
> ...
I am quite confused: in order to have 'savej' in the error message, you must
have it in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
--- Comment #6 from Dominique d'Humieres 2012-01-25
16:12:49 UTC ---
> Untested fix. ...
I just finished to bootstrap revision 183518 with the patch. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51995
--- Comment #12 from Dominique d'Humieres
2012-01-25 19:06:40 UTC ---
On x86_64-apple-darwin10 and an almost clean tree (i.e., with only the patch
for pr 51985) at revision 183528, compiling
testsuite/gfortran.dg/typebound_proc_25.f90 gives an IC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51995
--- Comment #13 from Dominique d'Humieres
2012-01-25 20:23:02 UTC ---
Reduced test case exhibiting the ICE:
MODULE factory_pattern
TYPE CFactory
PRIVATE
CHARACTER(len=20) :: factory_type !! Descriptive name for database
CL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52002
--- Comment #1 from Dominique d'Humieres 2012-01-25
21:23:31 UTC ---
Likely a duplicate of pr51985. Can you try the patch at
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01307.html .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985
Dominique d'Humieres changed:
What|Removed |Added
Target|*-apple-darwin* |*-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #30 from Dominique d'Humieres
2012-01-26 16:12:13 UTC ---
(In reply to comment #28)
> Created attachment 26468 [details]
> better patch
>
> This one should work.
It does;-)
I have applied the patch on revision 183541 on top of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #1 from Dominique d'Humieres 2012-01-26
16:22:51 UTC ---
> The attached examle generates a compiler error about not being able to convert
> from CLASS to TYPE being the object of the same declared type.
There is no attachment!-(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52011
Bug #: 52011
Summary: FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o
assemble, -flto -fgnu-tm in 32 bit mode
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52016
Bug #: 52016
Summary: [OOP] Polymorphism and elemental: missing diagnostic
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52011
Dominique d'Humieres changed:
What|Removed |Added
Summary|FAIL: |[4.7 Regression] FAIL:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754
--- Comment #3 from Dominique d'Humieres 2012-01-27
22:15:48 UTC ---
Trunk r183622 now gives
pr51754.f90:19.15:
BGet => self%componentB(1)
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
(r183618 g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754
--- Comment #5 from Dominique d'Humieres 2012-01-28
11:32:40 UTC ---
> The message is valid: one has to add the TARGET attribute to "self" or make
> "componentB" a POINTER. Doing so, one gets again the ICE in
> gfc_conv_descriptor_offset.
Confir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #31 from Dominique d'Humieres
2012-01-28 11:40:17 UTC ---
> The test in comment #23 gives an ICE with/without the patch:
>
> pr50981_4.f90: In function 'MAIN__':
> pr50981_4.f90:16:0: internal compiler error: in fold_convert_loc, at
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076
--- Comment #5 from Dominique d'Humieres 2012-01-28
11:54:51 UTC ---
> Proposed fix:
> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00708.html
A "stronger" fix has been proposed at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00895.html and appr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52028
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47399
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52024
--- Comment #5 from Dominique d'Humieres 2012-01-28
20:41:28 UTC ---
With the patch in comment #4 I get
[macbook] f90/bug% gfc pr52024.f90
pr52024.f90:46.6:
use m_test
1
Error: 'i_equal_t' and 't_equal_i' for GENERIC '==' at (1) are am
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
--- Comment #7 from Dominique d'Humieres 2012-01-28
21:51:33 UTC ---
> Additionally, it needs to pass some more review (J3 and then WG5). Current
> STATUS: J3 consideration in progress
Any progress three years later?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418
--- Comment #5 from Dominique d'Humieres 2012-01-28
23:07:49 UTC ---
With gfortran 4.4.6, 4.5.3, 4.6.2, and trunk, the test in comment #0 gives the
error while the test in comment #1 with the 'function fun(f,x)' block
uncommented compiles and run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412
--- Comment #2 from Dominique d'Humieres 2012-01-28
23:47:42 UTC ---
With trunk at revision 183668, compiling the test in comment #0 gives the error
[macbook] f90/bug% gfc pr43412.f90
pr43412.f90:8.27:
class(t), pointer :: y(*) ! <<< invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52038
Dominique d'Humieres changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #32 from Dominique d'Humieres
2012-01-29 12:09:57 UTC ---
Using 'symbol_as' without prototypes, as in comment #28, breaks bootstrap when
configured with '--disable-build-poststage1-with-cxx' (see pr52038).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #34 from Dominique d'Humieres
2012-01-29 12:20:56 UTC ---
> As written in comment 27, if it is only used in resolve.c, not a prototype but
> "static" should be used.
AFAICT it could also be used in gcc/fortran/expr.c (as changed in r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041
Bug #: 52041
Summary: [4.7 Regression] Bootstrap failure at revision 183650
with --enable-checking=release
Classification: Unclassified
Product: gcc
Version: 4.7.0
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041
--- Comment #1 from Dominique d'Humieres 2012-01-29
14:36:29 UTC ---
Created attachment 26501
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26501
Assembler for gcc/tree-ssa-strlen.c at stage 2
Assembler generated by
/opt/gcc/p_build/stage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041
--- Comment #2 from Dominique d'Humieres 2012-01-29
14:42:13 UTC ---
Created attachment 26502
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26502
bzipped assembler for gcc/tree-ssa-strlen.c at stage 3
Assembler generated by
/opt/gcc/p_bui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041
--- Comment #3 from Dominique d'Humieres 2012-01-29
14:44:55 UTC ---
Created attachment 26503
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26503
bzipped preprocessed file for gcc/tree-ssa-strlen.c at stage 3
AFAICT the only differences be
1701 - 1800 of 7788 matches
Mail list logo
