Your password was changed successfully!
++ User-Service: http://www.medinova.com
++ MailTo: [EMAIL PROTECTED]
*-*-* Mail_Scanner: No Virus
*-*-* GCC.GNU- Anti_Virus Service
*-*-* http://www.gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103747
Bug ID: 103747
Summary: Passing parameter pack expansion to alias template
with one argument fails as function return type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108180
Bug ID: 108180
Summary: [OpenMP] Passing a class member variable to
firstprivate() erroneously calls its dtor
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105885
Bug ID: 105885
Summary: [Regression]: Spurious warning: "the address of [...]
will never be NULL [-Waddress]" with const char*
template argument
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105885
--- Comment #3 from Markus Ebner ---
> I guess reporters reasoning is that ARG is defaulted to nullptr and that's
> the reason the diagnostic is unwanted?
I don't think it has any todo with whether nullptr is the default value for ARG
or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631
Bug ID: 118631
Summary: Public class member as const reference to protected
member
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631
--- Comment #4 from Jörg Brüggmann ---
Aha. Got it. Thank you!
*** [gmon.o] Error 1
make[1]: Leaving directory `/home/anton/tmp/gcc/objdir/gcc'
make: *** [all-gcc] Error 2
--
Summary: error: ÂPATH_MAXÂ undeclared (first use in this
function) when building cross compiler
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at yourkit dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28097
*** [gmon.o] Error 1
make[1]: Leaving directory `/home/anton/tmp/gcc/objdir/gcc'
make: *** [all-gcc] Error 2
--
Summary: error: ÂPATH_MAXÂ undeclared (first use in this
function) when building cross compiler
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at yourkit dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28098
ror 2
--
Summary: Cannot build cross compiler for Solaris: values-Xa.o: No
such file: No such file or directory
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstr
--- Comment #2 from info at yourkit dot com 2006-06-20 16:38 ---
Actually the problem was solved (in our case) by copying header files from
Solaris machine to $PREFIX/sysroot/usr/include dictory and additing
"--with-sysroot=$PREFIX/sysroot" to configuration options. Binutils
--- Comment #1 from info at yourkit dot com 2006-06-21 08:10 ---
All librarues from /usr/lib (from target Solaris machine) should be copied to
$PREFIX/sysroot/usr/lib
--
info at yourkit dot com changed:
What|Removed |Added
gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at yourkit dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
--- Comment #1 from info at yourkit dot com 2006-06-21 16:03 ---
Created an attachment (id=11721)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11721&action=view)
config.log
I have attached config.log file from directory
/home/anton/tmp/gcc/objdir/i386-pc-solaris2.10/libs
--- Comment #2 from info at yourkit dot com 2006-06-21 16:07 ---
I'm experienced with the similar bug #28125. Please help, I'm ready to provide
any additinal information.
--
info at yourkit dot com changed:
What|Removed
--- Comment #2 from info at yourkit dot com 2006-06-23 10:31 ---
I've charged target from "i386-pc-solaris2.10" to "i386-pc-solaris2.9"
and successfully built cross-compiler, but the resulting compiler
cannot produce 64bit binaries (as expected, because Solaris9
--- Comment #9 from info at yourkit dot com 2006-06-23 12:09 ---
I can confirm this bug.
target=i386-pc-solaris2.10;
host=i386-pc-linux-gnu;
GCC 4.1.1;
BinUtils 2.16.1
Checking multilib configuration...
/bin/sh /home/anton/tmp/gcc/gcc-4.1.1/mkinstalldirs i386-pc-solaris2.10/libssp
--- Comment #3 from info at yourkit dot com 2006-06-23 12:28 ---
I've discovered that if only C language is specified and --disable-libssp is
added (to work around bug #25035) then cross complier can be successfully
built. So the problem somewehere in C++ part.
--
ipermail/python-dev/ 2009-July/090724.html
--
Summary: malign-double witout effect for long double type
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: una
--- Comment #1 from bugtrack at roumenpetrov dot info 2009-07-24 12:40
---
P.S.: issue is tested on 32-bit x86 platform
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845
=/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/missing makeinfo
--split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET="
"SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS="
"exec_prefix=/usr/home/pirsc
nent: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at icomsoftware dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30914
--- Comment #2 from info at icomsoftware dot de 2007-02-23 16:55 ---
I have installed a precompiled binary. You can close this bug.
--
info at icomsoftware dot de changed:
What|Removed |Added
: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mail at sebastianbauer dot info
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x
--- Comment #1 from mail at sebastianbauer dot info 2007-03-21 07:14
---
Created an attachment (id=13240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13240&action=view)
The simple test source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
--- Comment #2 from mail at sebastianbauer dot info 2007-03-21 07:15
---
Created an attachment (id=13241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13241&action=view)
The output of the compiler invocation and the executable.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #7 from info at herberouge dot be 2007-08-25 22:35 ---
Subject: Re: add --enable-intermodule
STOP your email please !
- Original Message -
From: "aldot at gcc dot gnu dot org" <[EMAIL PROTECTED]>
To:
Sent: Sunday, August 26, 2007 12:33 AM
Subject:
construction of search path for include files
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agri at akamo dot info
nassigned at gcc dot gnu dot org
ReportedBy: antony at cosmologist dot info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
ot gnu dot org
ReportedBy: wilbert at jdg dot info
GCC build triplet: several
GCC host triplet: several
GCC target triplet: several
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
--- Comment #2 from wilbert at jdg dot info 2008-04-09 15:36 ---
I just did a fresh build of gcc 4.1.3 from the ports collection under freebsd
6.1
And got this (incorrect) result again:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48
ran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
I see an apparent memory leak introduced in running code between
ubuntu-toolchain-r/test gfortran 8.3.0 OK
Source 20200106 build gfortran 8.3.1 bad (also current 8 and
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
The code below leaks memory (mem grows with each loop interation), but does not
if the "FINAL" is commented. The issue is also present in trunk (10.0.1
20200218), an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #2 from Antony Lewis ---
This may be the test case, though I'm not 100% sure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #3 from Antony Lewis ---
Although my reduced test in the other id case is one problem, it appears that
is not the only memory leak. Someone tested else on various gcc versions and
still found:
versionmemory leak
7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #4 from Antony Lewis ---
Not sure why no one has at least picked up on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
since it is a reproducible regression with a simple test case, an a bug that
effectively kills some previousl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #2 from Antony Lewis ---
I tried it on another system where gfortran 6.5 and 7.4.0 that don't leak, but
8.4.0 does, so in that sense at least I think it is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #3 from Antony Lewis ---
On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
does not (but 9.2.0 does)... so not exactly sure what this means about when it
was introduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #6 from Antony Lewis ---
Thanks for looking in to it. I tried rebuilding my gcc8 docker and rerunning.
It now reports GNU Fortran (GCC) 8.4.1 20200602, however the leak still seems
to be there?
https://travis-ci.org/github/cmbant/CAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #7 from Antony Lewis ---
However the reduced case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
now seems to be OK.
However on trunk, the fix for 94361 seems to have introduced a leak that was
not there before: https://travis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #11 from Antony Lewis ---
It took ages to narrow this down, but here's a simple test case that still
gives a leak with valgrind in gcc-8 HEAD, 8.4.0, 9.3.0 (OK with 7.4.0)
module debug
implicit none
Type Tester
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #12 from Antony Lewis ---
Valgrid report is
HEAP SUMMARY:
==23446== in use at exit: 40,000 bytes in 1 blocks
==23446== total heap usage: 26 allocs, 25 frees, 93,657 bytes allocated
==23446==
==23446== 40,000 bytes in 1 blocks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #20 from Antony Lewis ---
Tried trunk and gcc8, and both look good - many thanks for the fixes!
Is there no way to update 7.x? Since the buggy 7/8/9 version has also
propagated quite widely, if you know any likely workaround that mig
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: renat at idrisov dot info
Target Milestone: ---
Hi All,
when compiling the following piece of code:
```
#include
int main(void) {
char *a = __builtin_alloca(4);
a[0] = 0
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lists.oss at hamme dot info
Target Milestone: ---
Target: avr
AVR GCC 9.2.0 has a critical bug with merging identical constant progmem and
data section symbols to a single
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu.org at mrks dot info
Target Milestone: ---
I found that introducing precompiled headers to my project causes ccache
lookups to fail. I tracked it down to the gcc output not being deterministic:
# /usr/bin/c++ -x c++-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #2 from Markus Dreseler ---
> Try using __DATE__ macro and you will see it is not :).
Can't confirm:
# /usr/bin/c++ -D__DATE__=0 -D__TIMESTAMP__=0 -D__TIME__=0 -x c++-header
-include test.hxx -o test.hxx.gch -c test.hxx.cxx && md5su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #4 from Markus Dreseler ---
> By any chance, is your cc1plus built as PIE? PCH doesn't work in that case.
I don't think so:
# file `find /usr -name cc1plus`
/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus: ELF 64-bit LSB executable, x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #5 from Markus Dreseler ---
I took Andrew's __DATE__ suggestion as a reason to look at how much the files
actually differ. `cmp -l v1 v2 | wc -l` gives me 692634 differing bytes. This
sounds like the difference is bigger than just som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #8 from Markus Dreseler ---
Interesting. Is this implementation documented somewhere?
I can confirm that disabling ASLR results in reproducible gchs:
# setarch $(uname -m) -R /usr/bin/c++ -x c++-header -include test.hxx -o
test.hxx.
Assignee: unassigned at gcc dot gnu.org
Reporter: renat at idrisov dot info
Target Milestone: ---
Created attachment 47640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47640&action=edit
preprocessed file
Hi All,
when I try to use -fpatchable-function-entry on M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #6 from Renat Idrisov ---
Thanks a lot!
: unassigned at gcc dot gnu.org
Reporter: spambait at maniek dot info
Target Milestone: ---
The following code crashes the compiler (most versions on compiler explorer,
e.g. current trunk, or 7.4).
//--
struct point{
int x=0;
};
typedef point array_t[1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57011
Bug #: 57011
Summary: Compiling _GLIBCXX_CONCEPT_CHECKS rejects
vector>
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jos at vandenoever dot info
Currently this code does not compile:
int total = 0;
std::for_each(begin(some_list), end(some_list), [&total](int x) {
total += x;
});
because begin() and end()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515
--- Comment #1 from jos at vandenoever dot info ---
The first line of the code snippet was missing:
int some_list[]={ 1, 2, 3, 4, 5 };
int total = 0;
std::for_each(begin(some_list), end(some_list), [&total](int x) {
total += x;
});
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515
jos at vandenoever dot info changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
--- Comment #3
Assignee: unassigned at gcc dot gnu.org
Reporter: root at heiher dot info
Loongson 3A is MIPS64R2-compatible, so this means that it should based
on ISA_MIPS64R2 (not ISA_MIPS64) ?
References:
http://www.loongson.cn/uploadfile/201204
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
--- Comment #1 from Heiher ---
Created attachment 30409
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30409&action=edit
Patch
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc at buszta dot info
Trying to compile GCC 4.8.1 (SVN trunk also applies) toolchain for
avr-unknown-elf target with standard C++ library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Johan Boulé changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc at buszta dot info
Created attachment 30847
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30847&action=edit
Preprocessed source
Minimal reproducti
||info
--- Comment #6 from Peter Schildmann 2011-09-05
19:45:27 UTC ---
diff --git a/gcc/ada/back_end.adb b/gcc/ada/back_end.adb
index 7172696..fdd06f1 100644
--- a/gcc/ada/back_end.adb
+++ b/gcc/ada/back_end.adb
@@ -206,6 +206,7 @@ package body Back_End is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #5 from Johan Boulé 2012-04-28
14:15:17 UTC ---
I believe my original bug report does not stand as a valid bug. Bug #47857 has
been marked as duplicate but is not: it's a spurious warning. Also, Olaf showed
a test case that seems prob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580
Fernando G. Tinetti changed:
What|Removed |Added
CC||fernando at info dot
||dot info
--- Comment #11 from Roumen Petrov
2012-04-08 12:19:47 UTC ---
Why is still "unconfirmed" ?
Severity: blocker
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Created attachment 31394
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31394&action=edit
OOP module implementing l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #5 from Antony Lewis ---
Thanks for the quick fix!
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
Fo
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: soltys at ziu dot info
Note, I first asked about it on gcc-help, though got no responsens. This does
look like a bug - though obviously I'm not sure if it really shou
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jkroby at p3r dot info
Gcc: msp430-gcc (GNU GCC patched mspgcc-20110716) 4.5.3
Run on msp430G2553
Library used: Energia 0101E0009
compiled on host: Linux version 3.2.0-56-generic (buildd@roseapple) (gcc
version 4.6.3 (Ubuntu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51742
Bug #: 51742
Summary: 4.6.2 v. HP-UX 11.11, PA-RISC: "make bootstrap-lean"
fails: "internal compiler error: Segmentation fault"
(In function '__fixunssfdi')
Classification: Unclas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51742
Steven Schweda changed:
What|Removed |Added
CC||sms at antinode dot info
--- Comment #1
to debug it and see why it segfaults.
I'll try to install gdb, and poke around a little, but don't expect too much.
The back story on this is that I've been adding PPMd compression capability to
the Info-ZIP UnZip program, and I was getting bad behavior on my AIX/PowerPC
and HP-UX/PA-R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51742
--- Comment #4 from Steven Schweda 2012-01-05
21:18:21 UTC ---
> The back story on this [...]
A somewhat condensed test case (1.6MB) should now be available here:
http://antinode.info/ftp/info-zip/unzip610c08_sx.tgz
The READ_ME f
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@antinode.info
While chasing an optimization-sensitive bug in some Info-ZIP UnZip
code, I've been bumbling around for a while, trying to build a recent
GCC on my AIX system ("make bootstrap-lean"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51999
--- Comment #1 from Steven Schweda 2012-01-26
04:55:36 UTC ---
Finally made it all the way through "gmake bootstrap-lean". Got a
few more interesting complaints:
[...]
rm -f stage_current
gmake[3]: Leaving directory `/usr/local/gnu/gcc/gcc-4
=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Created attachment 45333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45333&action=edit
Test case
This code works in 7.3.1, but gives wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
--- Comment #2 from Antony Lewis ---
I think the individual elements are correct, it's the array indexing operations
that are wrong (this is clearer in the longer example; looks a like wrong
stride). E.g. printing this in the main program after c
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
This code gives seg fault in 9.0.0 20181010 and 9.0.0 20190103, OK in 8.2.1:
(same with P pointer or allocatable)
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #10 from Antony Lewis ---
In the latest 9.0 trunk I still see what looks like a similar ICE error (though
I have not tried to isolate it again). See
https://travis-ci.org/cmbant/forutils/builds/483365115
when running test script in
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067
--- Comment #1 from Antony Lewis ---
The error message on this code
subroutine test
type x
end type
type, extends(x):: y
integer ii
end type
type(y) yy
yy%i=1
end subroutine
is
Error: 'i' at (1)
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Follow up to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566, seg fault ICE
with gfortran 6.5-9.0
module test
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #11 from Antony Lewis ---
I posted remaining ICE in 9.0.0 20190119 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
++
Assignee: unassigned at gcc dot gnu.org
Reporter: info at thinkmeta dot de
Target Milestone: ---
enum class X { Y = 0 };
template
struct D {};
template
struct Y;
template
struct Y<_T, D<_Value>> {};
void test() {
Y> y1;
Y> y2; // compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61606
--- Comment #5 from Fernando G. Tinetti ---
(In reply to Jürgen Reuter from comment #3)
> Is it really necessary to keep this one here open? Just stumbled on this via
> the discussion on c.l.f. This was with 4.9 which is no longer supported.
> Pr
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
This worked for a long time in gcc 7, I think it broke in gcc 7.3 (not exactly
sure which minor version). It is also broken in gcc 8 and latest master:
gfortran -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27931
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49915
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
ICE with version GNU Fortran (GCC) 10.0.0 20190618 compiling
https://github.com/cmbant/forutils.git
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927
--- Comment #4 from Antony Lewis ---
Not sure why that rather than other dependency options, been like that for ages
(guessing: maybe because of mpif.h?).
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Created attachment 44818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44818&action=edit
Full test case
Segmentation fault ICE compiling with 6.4. 7.3 or 8.2.0.
sub
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Bounds of vec2 are wrong in this example (0, 9) instead of (1, 10) as expected
(which can lead to all sorts of wrong results). Also in 6.4.
program tester
real(kind
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: westfw at westfw dot info
Target Milestone: ---
Created attachment 45116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45116&action=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #2 from William Westfield ---
I did say that it still happens with 8.1...
However, the 5.4.0 version is the latest version supported by the vendor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55510
Bug #: 55510
Summary: -O3 -msse3 produces an SSE optimization that produces
a Segmentation Fault
Classification: Unclassified
Product: gcc
Version: 4.7.2
St
1 - 100 of 278 matches
Mail list logo
