[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 Ev Drikos changed: What|Removed |Added Attachment #49990|0 |1 is obsolete|| --- Comment #6 from Ev Drikos --- Created attachment 54109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54109=edit Deallocation on Intrinsic Assignment Hello, This message follows a post by P. Thomas to c.l.f: https://groups.google.com/g/comp.lang.fortran/c/n62ukWe3TmY/m/5t4RWHELBAAJ So, I'd like to add to this PR a patch with few relevant test cases. The test case "realloc_class_8.f95" has been confirmed by feedback at: https://fortran-lang.discourse.group/t/deallocation-on-intrinsic-assignment/567 Ev. Drikos
[Bug fortran/99183] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 --- Comment #1 from Ev Drikos --- It turns out that the title isn't very accurate. It's a compile time error! Ev. Drikos
[Bug fortran/99183] New: Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 Bug ID: 99183 Summary: Incompatible Runtime types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: drikosev at gmail dot com Target Milestone: --- Having post a question in c.l.f I was informed that the program below is invalid but gfortran accepts it (several versions). This is the question: https://groups.google.com/g/comp.lang.fortran/c/jWHX3kJMeYY/m/4IMgy19hDgAJ Hope it isn't a duplicate! $ gfortran8 dream-casting.f90 && ./a.out allocatedx = d1(ind=1,i=1) allocatedv = d2(ind=2,j=2) assigned v = x, now v%ind= 1 j= 1 $ cat dream-casting.f90 program test implicit none type :: d0 integer :: ind end type d0 type, extends(d0) :: d1 integer :: i end type d1 type, extends(d0) :: d2 integer :: j end type d2 class(d1), allocatable :: x class(d2), allocatable :: v allocate ( x ,source = d1(1,1)) print *, "allocatedx = d1(ind=1,i=1)" allocate ( v ,source = d2(2,2)) print *, "allocatedv = d2(ind=2,j=2)" v = x print *, "assigned v = x, now v%ind=", v%ind, "j=", v%j end program test
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 --- Comment #6 from Ev Drikos --- (In reply to martin from comment #5) > Hi Ev, > > the testcase is actually derived from a smart pointer implementation (where > i is the reference count, shared between all smart pointers [hence > allocatable will not do], and incremented upon sharing). It would be nice to > have the bug fixed, though I have seen too many (subtle) bugs with > assignments by different compilers that I try not to use them. But thanks > for providing a better and more thorough testcase. Ok, then. Of course I don't think my test case is better. But as I see the underlying implementation, I feel (maybe wrong) that any allocatables would sky rocket the complexity of the solution. Regards.
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 Ev Drikos changed: What|Removed |Added Attachment #50129|0 |1 is obsolete|| --- Comment #4 from Ev Drikos --- Created attachment 50137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50137=edit Also a test case without allocatable components (In reply to martin from comment #0) Hello Martin, I'm also interest in seeing this bug fixed. The attached test case contains more fields in structure 's'. Yet, it's still a simple reproducer in the sense that a solution may also be relative simple in 'trans_scalar_assign'. If however the structure 's' contained allocatable components the solution would be more complex (again in trans_scalar_assign) and may have many side effects, as happens also with a general solution for the PR/64290. IMHO, there is a piece of code in assignments that perhaps needs redesign. Let's see if a prime maintainer will join the discussion here (or fix the bug). Hope this helps, Ev. Drikos
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 --- Comment #3 from Ev Drikos --- Created attachment 50129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50129=edit Test Case IMHO, a simple workaround might be a deep copy in 'gfc_trans_scalar_assign' if the LHS is finalizable (not pointer, artificial, or associate variable), just in case it's also somewhere a dummy argument with the intent(out) attribute. If this ok, the value b%x%i should be 124 after the assignment 'a=b' in #0 Hope this helps, Ev. Drikos
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #8 from Ev Drikos --- (In reply to Bill Long from comment #6) > Is there a released version with the fix noted in this bug? The code compiles with some older versions, without being sure that it produces correct results, a complete program is needed. Whereas, fortran-8.4 indeed raises an error. See ie: $ gfortran8 -c pr95038-00.f90 pr95038-00.f90:9:28: real(kind(x)) a(:) 1 Error: 'x' argument of 'kind' intrinsic at (1) must be a data entity $ gfc -c pr95038-00.f90 $ gfc --version GNU Fortran (GCC) 4.8.5
[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 --- Comment #5 from Ev Drikos --- Created attachment 49990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49990=edit realloc_class_8.f95 Hello, Having seen a Note in F2018 draft, specifically 10.2.1.3 Interpretation of intrinsic assignments, I wrote a test case that I thought should be ok, but I face this: $ gfortran8 realloc_class_8.f95 && ./a.out DEFERRED LENGTH NAME NAME=NONE [LEN= 4 ] USER=NONE [LEN= 4 ] NAME=Mr. John Richard Doe [LEN= 20 ] USER=Mr. John RichardMr. [LEN= 20 ] STOP 6 Of course, there are no finalizers in this case, yet I think that is closely related because they have the same bug fix (class reallocations). Hope this helps, Ev. Drikos
[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 --- Comment #4 from Ev Drikos --- Hello, There are some open PRs related to elemental finalisers. Having seen how you reallocate arrays, I'd the impression that the functionality for polymorphic entities would had a similar design. As one may also need ie to reset at least the '_len' field, ie class(*) x; x='a'; Which in turn may not cause regressions to "finalize_25.f90" and I see that this test counts some finalisation calls. Of course I don't doubt that finalization may be partially implemented as you say. Admittedly the interpretation of 10.2.1.3 & 7.5.6.3 seems to be a herculean task. To my understanding, an outcome of the discussion in c.l.f is that the reallocation takes place if the LHS & RHS have different runtime types, at least this seems to be a criterion for no rank polymorphic entities. Hope this helps, Ev. Drikos
[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #6 from Ev Drikos --- Hello Thomas, It's my impression that the solution in this PR may be a prerequisite for other PRs, ie PR/92065. Are there any plans for updating also the branch gcc-8, or it has been closed? Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #24 from Ev Drikos --- The hack outlined in comment #23 had raised an error with coarrays that turns to be an uncovered error: https://groups.google.com/g/comp.lang.fortran/c/E3RGBJZt4ag/m/MTXpOqPgAwAJ In short, the hack has no regressions with gcc-4.8.5 But I am neither a committer, nor I can create draft patches for the code on trunk at the moment. Yet, I'll be glad to go into further details if asked. Ev. Drikos
[Bug fortran/91648] [9/10/11 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #5 from Ev Drikos --- Hello, Is this PR still open once PR/92587 is done? Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #23 from Ev Drikos --- Created attachment 49841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49841=edit Test Cases Only Hello, I'm wondering whether a quick and dirty hack that would keep derived type data per class array declaration could work, coarrays are excluded at the moment (I know nothing about). The attached file contains only test cases for this PR. The first of them demonstrates what the hack could do. Let's see the vtab names: current vtab name: __class_m_T_1_0a hacked vtab name: __class_m_T_1_0a_b.sub2.m Where 'b' is a class array of type 'T' in the subroutine 'sub2', which in turn is in module 'm'.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #22 from Ev Drikos --- Created attachment 49836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49836=edit module + driver A slightly modified example gives me the impression that some local objects that are class arrays share the same Array Specification, even if they have been declared in a different scope, even they have quite different names and size. But they have been declared with an explicit shape that turns to be common, perhaps accidentally. The Array Specification is retrieved like that: as = IS_CLASS_ARRAY (sym) ? CLASS_DATA (sym)->as : sym->as; Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #17 from Ev Drikos --- Created attachment 49817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49817=edit module + driver (In reply to Dominique d'Humieres from comment #12) > The following test compiles (swapping fun1 and fun2): > ... Hello, It's my impression that the code compiles also with -O2 or -O3, which might be an interim solution until this bug is fixed. Hope this helps, Ev. Drikos
[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #3 from Ev Drikos --- Created attachment 49809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49809=edit deferred length character array Hello P. Thomas, At first, this is obviously a complex patch, which as it seems should normally have no regressions, so far. It's my impression that the attachment is relevant, ie due to variable realloc_flag in trans-expr.c, but currently I can't rebuild the code from trunk. So, I can't be sure if the test case would fail or pass. Note that this example have been submitted to c.l.f by a third person, I haven't written it. Hope this helps, Ev. Drikos
[Bug fortran/70863] [F03] Finalization of array of derived type causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70863 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #5 from Ev Drikos --- (In reply to janus from comment #3) > (In reply to Dominique d'Humieres from comment #1) > > related to/duplicate of pr69298? > > Yes, I think it's the same problem. It's my impression that these examples run ie with '-O3': macbook:finalizers suser$ gfc -O3 pr70863-02.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr70863-04.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr69298-06.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-00.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-01.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-02.f90 && ./a.out > /dev/null macbook:finalizers suser$ gfc -O3 pr82996-10.f90 && ./a.out > /dev/null Whereas, Valgrind reports no errors. Any ideas? Hope this helps Ev. Drikos
[Bug fortran/68778] [F03] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #6 from Ev Drikos --- (In reply to janus from comment #5) > ... > With current trunk I always get F, so apparently this has been fixed on > trunk. > > Can anyone confirm this? The chances are that this has been fixed! $ gfortran8 pr68778-00.f90 $ ./a.out TEST2: ASSOCIATED? (EXPECT: F) F (20 times) $ gfortran8 -v Using built-in specs. COLLECT_GCC=gfortran8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin18.7.0/8.4.0/lto-wrapper Target: x86_64-apple-darwin18.7.0 Configured with: ../gcc-8.4.0/configure --prefix=/opt/local --program-suffix=8 --enable-languages=lto,c,c++,fortran --enable-checking=release --disable-nls --with-system-zlib CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ CPP=/usr/local/bin/cpp GCC=/usr/local/bin/gcc CC_FOR_TARGET=/usr/local/bin/gcc CXX_FOR_TARGET=/usr/local/bin/g++ CPP_FOR_TARGET=/usr/local/bin/cpp GCC_FOR_TARGET=/usr/local/bin/gcc Thread model: posix gcc version 8.4.0 (GCC)
[Bug fortran/98016] Host association problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 --- Comment #7 from Ev Drikos --- Created attachment 49659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49659=edit attachment for pr98016-07 (In reply to Paul Thomas from comment #6) > Created attachment 49645 [details] > Fix for the PR > > Unless there are objections, ... Not an objection, rather just an observation: 1. This code is inside "resolve_symbol" and the following double declaration seems redundant: bool saved_specification_expr The reason I'm mentioning it is that I debugged the example with gcc-4.8 and the debugger makes this call: gfc_resolve_array_spec (sym->as, check_constant) So, the declaration below could be at the top of the function declarations like the code below
[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224 --- Comment #10 from Ev Drikos --- (In reply to Dominique d'Humieres from comment #9) > I think the two attached patches are not pertinent... Possibly, you are right. I have no access to the particular source code. > I get > > 8 | call AIMPAC(ACO,AIC,EXPON,ICENT,ITYPE,OE,OCCNO) > |1 > Error: PROCEDURE attribute conflicts with COMMON attribute in 'aimpac' at (1) > Indeed, this is the error message by gcc-8.4 but the user hasn't reported such an error message. I hope he will give some feedback.
[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224 --- Comment #8 from Ev Drikos --- Created attachment 49301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49301=edit test-case with a module Hello again, Here is another test-case with a module. It's a question if this should fail or pass. But gcc-8.4 compiles it without errors. Ev. Drikos
[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #7 from Ev Drikos --- Created attachment 49286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49286=edit regression example Hello, Indeed, the solution in PR/95614 has regressions, because the attached program ie is rejected but it was accepted by gcc-8.4 One could also exclude GSYM_SUBROUTINE & GSYM_FUNCTION in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614#c3 to have the attached program pr95614_aim2.f90 compile smoothly. Hope this isn't out of topic, Ev. Drikos
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #3 from Ev Drikos ---
Hello,
Perhaps, an additional check in file resolve.c might be necessary, or
one would have to adjust one-two "common*.f" test cases.
Hope this helps,
Ev. Drikos
--
if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON)
+ gsym = gfc_find_gsymbol (gfc_gsym_root, csym->name);
+ if (gsym && gsym->type != GSYM_UNKNOWN)
+ gfc_error_now ("Global entity %qs at %L cannot appear in a "
+ "COMMON block at %L", gsym->name,
+ >where, >common_block->where);
+
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 --- Comment #5 from Ev Drikos --- (In reply to Ev Drikos from comment #3) > Created attachment 48765 [details] > Various Test Cases, including one for PR/93635 > > Hello S. Kargl, > > The attached patch contains various test cases for the PR's you mentioned at: > https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ > > You simply apply it to your local working tree (ignore whatever fails). > > patch -p0 < gcc48-tc93635-n.patch > > Just ensure that these test cases indeed make some sense; they need a review. > > Ev. Drikos Hello again, 1. The first test case in the patch file (elemental_optional_args_6.f90) likely doesn't apply smoothly but one has to change the test case (manually). 2. As I run the tests again I see that the test case coarray_3.f90 fails? due to PR/95613. So, I've removed: gcc/testsuite/gfortran.dg/pr95613.f90 Ev. Drikos PS: Hope you haven't committed these patch file yet!
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #3 from Ev Drikos --- Created attachment 48765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48765=edit Various Test Cases, including one for PR/93635 Hello S. Kargl, The attached patch contains various test cases for the PR's you mentioned at: https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ You simply apply it to your local working tree (ignore whatever fails). patch -p0 < gcc48-tc93635-n.patch Just ensure that these test cases indeed make some sense; they need a review. Ev. Drikos
[Bug fortran/92785] expressions passed as real arguments to a dummy polymorphic argument fail with indexing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785 --- Comment #5 from Ev Drikos --- (In reply to Paul Thomas from comment #4) > Committed as revision r10-6924-g7485ace81de9ec9dd5c87edf67e359d31ce35a20 > > Paul Hello Mr. P. Thomas, With fortran-8.2, the test case prints 'FAILED' but exits with return code 0. So, a regression in the future might go unnoticed. Regards, Ev. Drikos
[Bug target/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199 --- Comment #5 from Ev Drikos --- Hello, At first, I'd like to note that these 2 options are also ok in MacOS-10.13: (a) g++8 -g -std=c++11 lib.cpp main.c -o main && ./main (b) g++8 -g -std=c++11 -I . main.c-S g++8 -g -std=c++11 -I . lib.cpp -S g++8 -g -std=c++11 -I . lib.s main.s -o main && ./main Just for the record, a fresh built gcc-4.8.5~36 in OS X Yosemite (10.10) doesn't have this problem but I just faced it in OS X Mavericks (10.9), where I had to properly comment the stmt "ld_uses_coal_sects = true" in file "darwin.c", added by an unofficial backport of PR/71767. Hope this helps, Ev. Drikos
[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #7 from Ev Drikos --- Hello, There is perhaps a Darwin specific problem reproduced in various versions, ie 8.2: Not really sure if the problem I face is indeed related to this PR. $ gcc8 -mfunction-return=thunk gcc/testsuite/gcc.target/i386/ret-thunk-26.c -arch i386 Undefined symbols for architecture i386: "__x86_return_thunk", referenced from: _foo in ccQ3DlYI.o _bar in ccQ3DlYI.o _main in ccQ3DlYI.o (maybe you meant: ___x86_return_thunk) ld: symbol(s) not found for architecture i386 collect2: error: ld returned 1 exit status $ $ gcc8 -v Using built-in specs. COLLECT_GCC=gcc8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17.5.0/8.2.0/lto-wrapper Target: x86_64-apple-darwin17.5.0 Configured with: ../gcc-8.2.0/configure --prefix=/opt/local --program-suffix=8 --enable-languages=c,c++,fortran --enable-checking=release --disable-nls --with-system-zlib Thread model: posix gcc version 8.2.0 (GCC) $
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 --- Comment #10 from Ev Drikos --- (In reply to Jonathan Wakely from comment #9) > ... I'm not sure either. But I've confirmed in macOS (10.13) the following simple hack. If the routine that initialises the Emulated TLS created two keys and then deleted the first, immediately after, the former key would be reassigned to the one used in function "__cxa_thread_atexit". The destructors would run in the desired order. Ideally, this routine would like to know, if the following two symbols are defined: _GLIBCXX_HAVE___CXA_THREAD_ATEXIT, and _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL To avoid the hack then, one would need to know which "__cxa_thread_atexit" is used. Ev. Drikos
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 --- Comment #8 from Ev Drikos --- (In reply to Iain Sandoe from comment #4) > ... > > A quick look says that __cxa_thread_atexit exists in libc from Darwin13, > macOS 10.9 / Mavericks onwards. > ... This is a very thorough analysis that essentially answers my question. Thanks BTW, perhaps this problem wasn't OS X specific only but was perhaps affecting MinGW users as well. The PR/80816 has been reported also with similar symptoms to PR/58142 as explained at: https://sourceforge.net/p/mingw-w64/bugs/727/ Ev. Drikos
[Bug c++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #2 from Ev Drikos --- Hello, I cannot reproduce this problem in a newer MacOS (10.12 & 10.13) when a program has been compiled by the newer GNU GCC versions (ie 7.3 & 8.2). To my understanding, the problem discussed in PR/58142 has been solved for the newer Darwin systems by the solution applied to PR/78968. Is PR/58142 still open just for older OS X systems? Thanks, Ev. Drikos
[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199 --- Comment #4 from Ev Drikos --- Created attachment 45574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45574=edit program output & gcc configuration in Sierra Hello, Having run this small test in older systems also, Yosemite (10.11) and sierra (10.12), I see that the results vary. I can reproduce the problem in Yosemite, not in Sierra. IMHO opinion, this issue depends either on GNU GCC configuration or to some patch I've applied in the meantime. My guess is that the reason is likely the configuration. Ev. Drikos
[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199 --- Comment #3 from Ev Drikos --- Created attachment 45573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45573=edit program output & gcc configuration in Yosemite
[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #2 from Ev Drikos --- (In reply to Eric Gallager from comment #1) > My first guess would be that the difference is Linux has native TLS, whereas > macOS only has emutls, which would be bug 52268. I'll wait for someone else > to confirm, though. Not really sure if my response is indeed the confirmation you want. If I compile the above example in macOS High Sierra (10.13) with the much older GNU gcc-4.8.5, then the output is "constest". Whereas with the newer gcc-8.2 I see the same results with the OP. $ g++ --version && uname -r g++ (GCC) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 17.5.0 $ g++ -g -std=c++11 -c -I . main.c $ g++ -g -std=c++11 -c -I . lib.cpp $ g++ -o main main.o lib.o $ ./main constest$ $ g++8 -g -std=c++11 -c -I . main.c $ g++8 -g -std=c++11 -c -I . lib.cpp $ g++8 -o main main.o lib.o $ ./main $ Ev. Drikos
[Bug c/82695] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82695 --- Comment #3 from Ev Drikos --- gcc 8.1 on macos 10.13.4 successfully passes this test. Thanks, Ev. Drikos
[Bug c/82695] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82695 --- Comment #2 from Ev Drikos --- The patch in PR/69960 indeed solves the problem described in PR/69960. I'll wait until next gcc release to see if it also solves the problem described in this PR. Thanks, Ev. Drikos
[Bug fortran/69455] [6/7/8 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #12 from Ev Drikos --- Is there any chance to see this patch? Thanks, Ev. Drikos
[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787 --- Comment #6 from Ev Drikos --- 1) the exact version of GCC: $ gcc7 --version gcc7 (GCC) 7.1.1 20170622 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2) the system type: $ uname -a Darwin miniserver.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64 3) the options given when GCC was configured/built $ gcc7 -v Using built-in specs. COLLECT_GCC=gcc7 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17/7.1.1/lto-wrapper Target: x86_64-apple-darwin17 Configured with: ../gcc-7-20170622/configure --prefix=/opt/local --program-suffix=7 --build=x86_64-apple-darwin17 --enable-languages=c,c++,fortran --disable-bootstrap --disable-nls --enable-checking=release --with-system-zlib --enable-threads=posix --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-ar=/usr/bin/ar AR_FOR_TARGET=/usr/bin/ar AS_FOR_TARGET=/usr/bin/as LD_FOR_TARGET=/usr/bin/ld NM_FOR_TARGET=/usr/bin/nm OBJDUMP_FOR_TARGET=/usr/bin/objdump RANLIB_FOR_TARGET=/usr/bin/ranlib STRIP_FOR_TARGET=/usr/bin/strip OTOOL=/usr/bin/otool OTOOL64=/usr/bin/otool LIPO=/usr/bin/lipo LIPO_FOR_TARGET=/usr/bin/lipo CC=/opt/local/bin/gcc CXX=/opt/local/bin/g++ CPP=/opt/local/bin/cpp GCC=/opt/local/bin/gcc CC_FOR_TARGET=/opt/local/bin/gcc CXX_FOR_TARGET=/opt/local/bin/g++ CPP_FOR_TARGET=/opt/local/bin/cpp GCC_FOR_TARGET=/opt/local/bin/gcc CFLAGS='-O2 -g -mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4 ' CXXFLAGS='-O2 -g -mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4' 'CFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4 ' 'CXXFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4' Thread model: posix gcc version 7.1.1 20170622 (GCC) 4) the complete command line that triggers the bug: $ gcc7 -save-temps syslog.c 5) the compiler output (error messages, warnings, etc.): In file included from /usr/include/syslog.h:23:0, from syslog.c:1: /usr/include/sys/syslog.h:227:84: error: expected ',' or ';' before '__asm' void syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called __DARWIN_ALIAS_STARTING(__MAC_10_13, __IPHONE_NA, __DARWIN_EXTSN(syslog)); ^ 6) the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command. It's the attachment syslog.i
[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787 --- Comment #5 from Ev Drikos --- Created attachment 42513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42513=edit syslog.i
[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787 --- Comment #3 from Ev Drikos --- Created attachment 42512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42512=edit On Darwin 10.13: "cpp7 /usr/include/syslog.h>cpp7syslog.h" If this isn't what you expect, please feel free to tell me how I should run the preprocessor. Ev. Drikos
[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787 --- Comment #2 from Ev Drikos --- (In reply to Andrew Pinski from comment #1) > Can you provide the preprocessed source? What command I should run? Ev. Drikos
[Bug c/82787] New: gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787
Bug ID: 82787
Summary: gnu gcc (4.8 - 7.1) cannot parse some system headers
in macOS (10.13)
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drikosev at gmail dot com
Target Milestone: ---
Hi,
gcc fails to parse various system headers in the latest macOS release (High
Sierra, 10.13).
One of the failures is this:
$ cat syslog.c
#include
int main() {
return 0;
}
$ gcc7 syslog.c
In file included from /usr/include/sys/cdefs.h:587:0,
from /usr/include/sys/syslog.h:65,
from /usr/include/syslog.h:23,
from syslog.c:1:
/usr/include/sys/syslog.h:227:124: error: expected ',' or ';' before '__asm'
void syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called
__DARWIN_ALIAS_STARTING(__MAC_10_13, __IPHONE_NA, __DARWIN_EXTSN(syslog));
^
$ gcc7 --version | head -n 1
gcc7 (GCC) 7.1.1 20170622
Regards,
Ev. Drikos
[Bug c/82695] New: gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82695
Bug ID: 82695
Summary: gnu gcc (4.8 - 7.1) cannot parse some system headers
in macOS (10.12)
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drikosev at gmail dot com
Target Milestone: ---
Hi,
gnu gcc cannot parse some system headers in macOS (10.12)
. One bug is this:
$ cat framework-1.c
#include
int main(){
return 0;
}
$ gcc framework-1.c
In file included from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGContext.h:18:0,
from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGBitmapContext.h:9,
from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:11,
from
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:35,
from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
from framework-1.c:1:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGFont.h:53:1:
error:initializer element is not constant
static const CGFontIndex kCGGlyphMax = kCGFontIndexMax;
The error is issued in gcc/c/c-typeck.c by the following fragment (7 lines):
else if (require_constant
&& !initializer_constant_valid_p (inside_init,
TREE_TYPE (inside_init)))
{
error_init ("initializer element is not constant");
inside_init = error_mark_node;
}
Is there a workaround that would allow gcc to accept such an initialisation?
Ev. Drikos
