https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67556
--- Comment #2 from Mohammad Masood Masaeli ---
You're right, sorry.
Thanks for your time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #101 from Kazumoto Kojima ---
> Perhaps the both codes are ok, though something odd happens
> on atomic things anyway.
I've forgotten that some atomic builtins fail with spill_failure
in class 'R0_REGS' for old RA. So libstdc++-v3 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67534
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67547
--- Comment #2 from BENAÏSSA ---
Thank you very much for your reply.
A.Benaïssa
Le Vendredi 11 septembre 2015 13h25, pinskia at gcc dot gnu.org
a écrit :
https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
Francois-Xavier Coudert changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640
Francois-Xavier Coudert changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557
Bug ID: 67557
Summary: Calling copy constructor of base class in constructor
of derived class produces crashing code
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #36 from Dominique d'Humieres ---
> i.e., r227264 (or 4.8, 4.9, and 5.2) is ~3 time faster than r227383.
It is due to r227277 (with r227265 reverted in order to bootstrap Ada).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67527
--- Comment #2 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705
URL: https://gcc.gnu.org/viewcvs?rev=227705&root=gcc&view=rev
Log:
PR libfortran/67527
PR libfortran/67535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535
--- Comment #7 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705
URL: https://gcc.gnu.org/viewcvs?rev=227705&root=gcc&view=rev
Log:
PR libfortran/67527
PR libfortran/67535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67536
--- Comment #1 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705
URL: https://gcc.gnu.org/viewcvs?rev=227705&root=gcc&view=rev
Log:
PR libfortran/67527
PR libfortran/67535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67536
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67527
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #37 from Sebastian Pop ---
I think gcc should stop blocking initialization loops: it should only block a
loop when it contains more than two arrays, one array accessing non-contiguous
elements in memory, and another array accessing co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67558
Bug ID: 67558
Summary: [C++] OpenMP "if" clause does not utilize compile-time
constants
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67519
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557
--- Comment #2 from Markus Trippelsdorf ---
See PR67519 for a possible future compiler warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #2 from Vittorio Zecca ---
The pointer is NULL but the length is zero.
The test case is allocate_deferred_char_scalar_1.exe
on all eight combinations. As in
Executing on host:
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #5 from Jan Hubicka ---
> None of them is applicable to a weakdef with "ld -r".
Yep, GCC simply assumes that incremental linking is not going to happen and it
makes strong assumptions
about visibility in static&PIC binaries.
To suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67519
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66965
--- Comment #2 from Eric Botcazou ---
Author: ebotcazou
Date: Sat Sep 12 16:35:20 2015
New Revision: 227709
URL: https://gcc.gnu.org/viewcvs?rev=227709&root=gcc&view=rev
Log:
PR ada/66965
* gnat.dg/specs/addr1.ads: Remove.
Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66965
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #6 from H.J. Lu ---
(In reply to Jan Hubicka from comment #5)
> > None of them is applicable to a weakdef with "ld -r".
> Yep, GCC simply assumes that incremental linking is not going to happen and
> it makes strong assumptions
> abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #3 from Vittorio Zecca ---
I believe the test case is erroneous. NULL pointers are dereferenced
in subroutines
source_check and source_check4:
if(str4 == '12a56b78') call abort()
and
if(str4 == 4_'12a56b78') call abort()
are deref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67559
Bug ID: 67559
Summary: [C++] [regression] Passing non-trivially copyable
objects through '...' doesn't generate warning or
error
Product: gcc
Version: 5.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #4 from Dominique d'Humieres ---
> If you had a sanitized version of libgfortran you could check them by
> yourself.
Could you please post the exact command line you are using for configure and
make and, if needed, the environment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67447
Mikhail Maltsev changed:
What|Removed |Added
Last reconfirmed||2015-9-12
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67560
Bug ID: 67560
Summary: False positive with -fcheck=recursion
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67560
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67505
Dominique d'Humieres changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
Bug ID: 67561
Summary: [C++14] ICE in tsubst_copy (nested auto lambdas may be
involved)
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
--- Comment #1 from Joel Yliluoma ---
Further reduced example:
template
void DrawView(PlotFunc GetPlotFunc)
{
GetPlotFunc(1)(2);
}
void CalculateLightmap()
{
auto LightmapRenderer = [](unsigned round)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411
Joel Yliluoma changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
Joel Yliluoma changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775
--- Comment #4 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:00 2015
New Revision: 227710
URL: https://gcc.gnu.org/viewcvs?rev=227710&root=gcc&view=rev
Log:
remove STRUCT_VALUE macro
This macro was converted to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775
--- Comment #5 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:06 2015
New Revision: 227711
URL: https://gcc.gnu.org/viewcvs?rev=227711&root=gcc&view=rev
Log:
remove unused defines from sendmsg.c
libobjc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775
--- Comment #6 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:11 2015
New Revision: 227712
URL: https://gcc.gnu.org/viewcvs?rev=227712&root=gcc&view=rev
Log:
stop including tm.h in sendmsg.c
libobjc/ChangeLog:
2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67562
Bug ID: 67562
Summary: Bad result from sourced allocation with class(*)
arrays
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67562
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322
Dominique d'Humieres changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65889
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67562
--- Comment #2 from neil.n.carlson at gmail dot com ---
Please pardon my ignorance (I rarely use gfortran), but is there a 6.0 source
distribution somewhere? The latest I can find is 5.2. Are you talking about
the current trunk? I'm puzzled bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67562
--- Comment #3 from Dominique d'Humieres ---
> Please pardon my ignorance (I rarely use gfortran), but is there a 6.0 source
> distribution somewhere? The latest I can find is 5.2. Are you talking about
> the current trunk?
Yes, you can prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #102 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #101)
>
> I've forgotten that some atomic builtins fail with spill_failure
> in class 'R0_REGS' for old RA. So libstdc++-v3 was configured
> so to undefine _GLIBCXX_A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #103 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #102)
> Ah! I always wondered why those failures disappeared from your nightly
> tests. Did you do this locally in your setup, or has this been committed at
> some ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #104 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #103)
> I did nothing. Looks simply fragile like as other reload ICEs.
> libstdc++-v3 conftest catches it, (un)fortunately.
Ah, I understand. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61930
--- Comment #1 from Oleg Endo ---
I think this is related to PR 29969.
In some cases it might make sense to do mem copy like insns either in SImode
(if displacement addressing is better) or in SFmode (to reduce GP reg
pressure). This is not onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540
--- Comment #5 from Vittorio Zecca ---
On the same line
CFLAGS="-fsanitize=undefined -Og -g -fno-omit-frame-pointer"
CXXFLAGS=$CFLAGS LDFLAGS="-lubsan -ldl -lpthread"
/home/vitti/gcc-5.2.0/configure
--prefix=/home/vitti/1tb/local/gcc-5.2.0-undefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557
--- Comment #3 from Georg Baum ---
Can you please explain why §12.6.2 - 14 is applicable? I do not see any member
function (virtual or not) being called on the partially constructed object. I
still think that this is valid code with well defined
52 matches
Mail list logo