https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290
Ev Drikos changed:
What|Removed |Added
Attachment #49990|0 |1
is obsolete|
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735
Ev Drikos changed:
What|Removed |Added
Attachment #50129|0 |1
is obsolete|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #8
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #6
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #5
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70863
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #6
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #3
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #7
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #2
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)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #2
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #12
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
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
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
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
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
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
43 matches
Mail list logo
