Hi,
Whilst this bug has been marked as resolved, I am still experiencing the same
problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1).
My gcc version info : gcc (GCC) 4.1.0 20050924 (experimental)
The following is the stack dump for the problem:
--
--- Comment #4 from davejmurphy at me dot com 2008-12-27 21:46 ---
Created an attachment (id=16992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16992&action=view)
preprocessed source for arm-eabi testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
--- Comment #5 from davejmurphy at me dot com 2008-12-27 21:48 ---
(From update of attachment 16992)
I've tripped over this bug on arm-eabi too, with this code, compiled as thumb.
extern int doStreamReadBlock(int *, char *, int size, int);
char readStream(int *s)
{
char
c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davejmurphy at me dot com
GCC build triplet: i386-apple-darwin9.6.0
GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #1 from davejmurphy at me dot com 2008-12-27 22:10 ---
Created an attachment (id=16993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16993&action=view)
preprocessed source for arm-eabi testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #8 from me at cgf dot cx 2005-12-10 05:45 ---
Subject: Re: Broken gcc mailing list archives
On Sat, Dec 10, 2005 at 05:30:21AM -, pinskia at gcc dot gnu dot org wrote:
>
>--
>
>pinskia at gcc dot gnu dot org changed:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318
--- Comment #8 from cgf at gcc dot gnu.org ---
email from sourceware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #6 from Fangrui Song ---
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
Correction: It is incorrect to reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #10 from Fangrui Song ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }
This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereferen
rrect usage for your use case. If you don't like it is not
> my fault.
A wontfix/invalid does not seem a proper resolution to the bug(s).
We need a solution, instead of a workaround (SHN_ABS _binary_*_size can be
changed to _binary_*_end minus _binary_*_start).
Let me repeat. The code has
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Given the following simple program, the line that static_asserts changed from
gcc 8 to gcc 9 (and remains so for current trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #2 from Alisdair Meredith ---
Thanks for the speedy response, really appreciated!
I believe this is well-defined behavior, but can accept that the value of
__LINE__ may be unspecified - I do struggle with pre-processor wording.
Ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #4 from Alisdair Meredith ---
(In reply to Andrew Pinski from comment #3)
> I miss-remembered the issue, the issue was only with preprocessor directives
> inside macro functions (this changed in GCC 3.3 and above really).
>
> But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #8 from Alisdair Meredith ---
(In reply to Andrew Pinski from comment #6)
> Why not do this:
> static_assert(X == 3 || X == 4);
>
> There that works for both cases.
The code example was intended to the be smallest reproducible examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #9 from Alisdair Meredith ---
(In reply to Martin Sebor from comment #7)
> The following proposal was accepted into C2X last year:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm
> It seems to me like it&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #10 from Alisdair Meredith ---
And double-checking the C++ Standard again, I think I have wording in favor of
my report and contradicting the recommended best practice for the pending C
standard:
[cpp.line]p2 "The line number of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91867
me at myrrec dot space changed:
What|Removed |Added
CC||me at myrrec dot space
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-ffunction-sections produces sections .text.foo , .text.bar , etc, which can
take significant amount of string table space.
In clang, -fno-unique-section-names emits
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-gsplit-dwarf has an undesired property: it sets the debug info level to 2.
When plugged into a build system, this can enable debug info unnecessarily
(when the user does not specify -g or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096
--- Comment #1 from Fangrui Song ---
Created https://sourceware.org/pipermail/gcc-patches/2020-May/545638.html
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
In general, we do not expect array types to be copyable according to the
'is_copy_constructible_v' trait. However, the following started passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153
--- Comment #1 from Alisdair Meredith ---
Forgot to add this is specific to -std=c++20 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #13 from Alisdair Meredith ---
As this has shipped for two releases now (gcc9 and 10) I recommend closing as
Works As Designed, citing C standard paper N2322 as reason for the change.
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pkh dot me
Target Milestone: ---
Given the following C code:
% cat a.c
#include
static const float z[1] = {0};
int f(float x) { return memcmp(&x, z, sizeof(x)); }
GCC 10 generates this on x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #1 from Fangrui Song ---
I just learned that `int main() {}` compiles to .text.startup in -O2 or -Os
It seems that .text.startup. may be better to not accidentally move a C
function named `startup` (`startup.` is not a valid C identi
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
DWARF v5 Appendix F. says
> The sections that do not require relocation, however, can be written to the
> relocatable object (.o) file but ignored by the linker, or they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #5 from gcc at pkh dot me ---
I'd like to point out that this regression impacts badly a production app.
We're using this pattern to compare an input vector of floats to a vector of
zeros, but the comparison always ret
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
GCC seems to overlap register bewteen DEST and SOURCE in different machine
mode,
e.g. RISCV vector extension:
when VMUL > 1, most
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Created attachment 48834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48834&action=edit
Validate allocator propagat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153
--- Comment #3 from Alisdair Meredith ---
Sorry, thought I had confirmed that I agree with the analysis above - this is a
(perhaps surprising) change to the specification of C++20.
What is the best way to withdraw this report as invalid?
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
% gcc-10 -ffile-prefix-map=/tmp/c=/src --coverage -c -g /tmp/c/a.c
# -ffile-prefix-map implies -fdebug-prefix-map
% llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
jojo changed:
What|Removed |Added
CC||rjiejie at me dot com
--- Comment #35 from jojo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092
--- Comment #3 from Fangrui Song ---
(In reply to Martin Liška from comment #2)
> Apparently we've got a patch in queue that does something similar:
>
> +fprofile-prefix-path=
> +Common·Joined·RejectNegative·Var(profile_prefix_path)
> +remove·p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #38 from jojo ---
(In reply to Martin Liška from comment #36)
> (In reply to jojo from comment #35)
> > (In reply to Martin Liška from comment #30)
> > > A possible solution can be usage of '-flinker-output=nolto-rel -r' for
> > > hu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #4 from Fangrui Song ---
https://sourceware.org/pipermail/gcc-patches/2020-July/550659.html [PATCH v3]
Add --ld-path= to specify an arbitrary executable as the linker
I changed the title to --ld-path because -fuse-ld=/absolute/path/
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 48942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48942&action=edit
inflated text section with ipa inline
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix at piedallu dot me
Target Milestone: ---
Created attachment 48951
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48951&action=edit
minimal code for missing maybe-uninitialized warning
There are cases wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368
Salamandar changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #2 from Salamandar --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96352
--- Comment #2 from jojo ---
(In reply to Richard Biener from comment #1)
> It was a bugfix. If you want to have small binaries use -Os. You can also
> tune the inliner with various knobs, the most important maybe
> --param inline-unit-growth w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #19 from
ormal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This is a minor display issue.
>a.cc cat<b.cc cat<a.h cat<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #17 from
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I can understand that defaulting -fprofile-update=prefer-atomic in GCC 7 and
using atomic counters when -pthread is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85351
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #5 from Fangrui Song ---
Ping
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
insn seqs:
s1:
__builtin_set_float_convert_mode(0);
r1 = __builtin_load(a1, a2);
r2 = __builtin_float_convert(r1);
__builtin_store(a3, r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97170
--- Comment #2 from jojo ---
(In reply to Andrew Pinski from comment #1)
> target_fcvt is wrong.
> try:
> (define_insn "target_fcvt"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (unspec:SI [(match_operand:SF 1 "register_operan
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [cpp.predefined], the __CPP_THREADS__ macro should be (implicitly)
predefined "if and only if a program can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92138
Alisdair Meredith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ilya at alfs dot me
Target Milestone: ---
Hello,
I had few segmentation faults while writing AVX512 code. SEGFAULTs were caused
by aligned loads used when data alignment can not be guaranteed in compile
time.
test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92257
--- Comment #2 from Ilya Albrekht ---
Thank you for your prompt reply. I missed that __m512i_u type exists to avoid
alignment requirement.
PS. I guess you meant 512 bit?
Regards,
Ilya
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
https://wg21.cmeerw.net/cwg/issue546
Change 17.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67228
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #7 from
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at cimba dot li
Target Milestone: ---
It seems that if the address of a stack variable is never taken, it is treated
by child OpenMP tasks with firstprivate semantics, even though
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
We are seeing a bogus warning on the default constructor for a class template
that wraps a data mem
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
/lhome/software/jojo/csky-toolchain-build-riscv/build-riscv64-linux-glibc-opt4mabi-lp64_march-rv64gc/gcc-riscv/build-gcc-linux-stage2/gcc/xgcc
-B/lhome/software/jojo/csky-toolc
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
void f(){}
% gcc -fpatchable-function-entry=3 -c a.c
% readelf -S a.o
...
[Nr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
--- Comment #1 from Fangrui Song ---
The SHF_WRITE issue has been fixed.
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00271.html will fix sh_addralign
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.cc
inline void foo() {}
void bar() { foo(); }
% cat b.cc
inline void foo() {}
void
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
__patchable_function_entries is not a GC root, and not referenced by a retained
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following simple program is accepted by Clang (trunk) and rejected by
current gcc (trunk) at the time of filing:
template
cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
--- Comment #2 from Alisdair Meredith ---
I am trying to use these extensively as ways to collect related static
assertions in my test suite for and . By using
consteval rather then constexpr, I get notified if any code is unexpectedly
deferred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92672
--- Comment #3 from Cimbali ---
Would it be possible to deactivate that optimization when shared is not the
default mapping? In practice here explicitly setting `shared(i)` has no effect
at all.
Note that I already recommended against such trick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #7 from Fangrui Song ---
> Is -fasynchronous-unwind-tables compatible with -fpatchable-function-entry?
Apparently the Linux kernel does not care about it. To make it usable in
userspace, we should place .cfi_startproc in a reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
--- Comment #1 from Fangrui Song ---
This is similar to --gc-sections
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536) but a bit different.
The only reasonable fix I can think of is to place __patchable_function_entries
in the same section g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #11 from Fangrui Song ---
(In reply to H.J. Lu from comment #8)
> Created attachment 47762 [details]
> A patch to handle targetm.asm_out.post_cfi_startproc
I don't work on GCC, so I am hoping other x86 maintainers can review. (I know
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
C++ currently has two deprecated C++ headers, and .
For quite a while, gcc has warned on #include with
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
This feature request generalizes -fuse-ld=bfd -fuse-ld=gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470
and
-fuse-ld=lld
clang -fuse-ld= also supports the following forms:
-fuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #1 from Fangrui Song ---
Posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html
I agree with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321#c4
we should use a new option, instead of overloading --print-prog-nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
++
Assignee: unassigned at gcc dot gnu.org
Reporter: alxchk at alxchk dot me
> cat test.cpp
#include
#include
int main(int argc, char *argv[])
{
auto x = std::vector({1, 2, 3});
auto y = [x] ()
mutable {
for (auto &i: x)
i ++;
return x;
};
for (const
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: alxchk at alxchk dot me
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
$ cat test.cpp
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: me at williamgrant dot id.au
Created attachment 30469
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30469&action=edit
arm.md fix
The fix for PR target/19599 in svn trunk r198928
: unassigned at gcc dot gnu.org
Reporter: whitequill at abstractions dot me
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
--- Comment #2 from Whitequill Riclo ---
This is the first bug I have reported, so I didn't know where to look to see if
it has been reported before.
Also I can reproduce it over, and over again without fail.
I was a little unnerved when I saw the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
Malcolm Inglis changed:
What|Removed |Added
CC||me at minglis dot id.au
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
--- Comment #3 from Whitequill Riclo ---
I can not proceseed with a project due to this bug, is there anything I can do
in the mean time?
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jbcoe at me dot com
Created attachment 30768
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30768&action=edit
small program illustrating crash
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
Jonathan Coe changed:
What|Removed |Added
CC||jbcoe at me dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
--- Comment #4 from Jonathan Coe ---
Yes, I've built on OS X 10.8.4 using a macports build of GCC 4.8.1.
I've tried adding -pthread when building - it makes no difference to the
crashing.
19 of 20 runs on my machine crash. I think if you managed 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
--- Comment #8 from Jonathan Coe ---
I've pared down the example. The crash is much harder to reproduce now (maybe 1
in 20 runs). Please find code and crash log attached.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
--- Comment #10 from Jonathan Coe ---
Created attachment 30780
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30780&action=edit
OSX 10.8.4 Crash log from smaller program crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
Jonathan Coe changed:
What|Removed |Added
Attachment #30768|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848
--- Comment #21 from Whitequill Riclo ---
The patch worked for me, but now I'm getting a new error that looks like Bug
47052 accept the proposed fix doesn't work because is says DW2 isn't suppored
on 64-bit yet.
I can get around t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52892
Adrien Guinet changed:
What|Removed |Added
CC||adrien at guinet dot me
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53600
Bug #: 53600
Summary: Fatal Error: Can't open module file 'omp_lib.mod' for
reading at (1).
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531
--- Comment #4 from kaladhorn at me dot com 2012-06-08 18:46:11 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Out of curiosity, would there be a technical issue in this case?
> > It sure seemed natural to me.
&g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531
Bug #: 52531
Summary: Compilation fails with polymorphic dummy argument and
OpenMP
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531
--- Comment #2 from kaladhorn at me dot com 2012-03-08 19:33:24 UTC ---
(In reply to comment #1)
> OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you
> are trying to compile is not valid.
hmm that's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
--- Comment #4 from Malcolm Inglis ---
I don't have a copy of the C99 standard, but IBM says [1] that if the function
is called with a pointer to a smaller array than specified with `static`, then
the behavior is undefined. Ergo, there should be a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605
Bug #: 51605
Summary: internal compiler error gfc_trans_block_construct, at
fortran/trans-stmt.c:984
Classification: Unclassified
Product: gcc
Version: unknown
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605
--- Comment #1 from Dan Nagle 2011-12-17 22:45:42 UTC
---
Compiles with fort 12.1, nagfor has a different problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607
Bug #: 51607
Summary: configure: error: GNU fortran compiler is not working
;
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607
--- Comment #1 from David 2011-12-18 09:25:27 UTC ---
Created attachment 26127
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26127
fortran library config log
1 - 100 of 722 matches
Mail list logo
