http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #4 from Laurent Aflonsi ---
When the .gcno graph file is opened for generating the coverage graph
information, the mode used is w+ as this code is shared with updating tools
such as libgcov. Thus, when GCC outputs .gcno files, it may l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #3 from Laurent Aflonsi ---
Created attachment 31086
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31086&action=edit
source patch for trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58869
Bug ID: 58869
Summary: switch -mcu=cortex-a7 conflicts with -march=armv7-a
switch
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
--- Comment #15 from Tobias Burnus ---
Author: burnus
Date: Fri Oct 25 05:47:25 2013
New Revision: 204047
URL: http://gcc.gnu.org/viewcvs?rev=204047&root=gcc&view=rev
Log:
2013-10-25 Tobias Burnus
PR other/33426
* parser.c (cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58867
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Target Mile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868
Bug ID: 58868
Summary: ICE: in count_type_elements, at expr.c:5495 with
-std=gnu++0x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58867
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58867
Bug ID: 58867
Summary: asan and ubsan tests not run for installed testing
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542
--- Comment #11 from Richard Henderson ---
Author: rth
Date: Thu Oct 24 22:27:53 2013
New Revision: 204040
URL: http://gcc.gnu.org/viewcvs?rev=204040&root=gcc&view=rev
Log:
PR rtl/58542
* optabs.c (maybe_emit_atomic_exchange): Use create_input_o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58866
Bug ID: 58866
Summary: sh64: Wrong genmultilib invocation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58759
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131024 (experimental) [trunk revision 204004] (GCC)
$
$ gcc-trunk -m64 -O1 small.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57744
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #2 from Greg Banks ---
Created attachment 31085
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31085&action=edit
source for test case
Here's a test case which doesn't rely on optimisation behaviour
to demonstrate the bug.
me@mac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
Greg Banks changed:
What|Removed |Added
CC||gbanks at sgi dot com
--- Comment #1 from Gr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
--- Comment #5 from Ali Baharev ---
OK, then 8 byte default alignment for loops is the default. If you think it is
not a bug, then let's close this. Sorry for the false alarm.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
--- Comment #4 from Ali Baharev ---
My mistake, sorry.
So, you are saying that the default alignment is 8 byte for loops?
The funny thing is, this code runs 15% faster, if any of the followings are
passed:
-Os
-O2 -fno-align-loops -fno-align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
--- Comment #3 from Andrew Pinski ---
(In reply to Ali Baharev from comment #2)
> Please check with objdump. It's not what I get in the executable.
Yes it is. Read my comment again. we align loops to 8 byte by default but try
to align it to 16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
--- Comment #2 from Ali Baharev ---
Please check with objdump. It's not what I get in the executable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712
--- Comment #5 from Jeffrey A. Law ---
Author: law
Date: Thu Oct 24 17:28:11 2013
New Revision: 204026
URL: http://gcc.gnu.org/viewcvs?rev=204026&root=gcc&view=rev
Log:
PR ipa/58712
* cgraph.c (cgraph_create_edge_1): Add indirect_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
--- Comment #1 from Andrew Pinski ---
We have:
.p2align 4,,10
.p2align 3
so the max number of bytes we will skip is 10 but still align it to a 8 byte
boundary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58789
--- Comment #5 from Martin Jambor ---
Well, IPA-CP devirtualization is required to trigger the bug but it is
a clone materialization problem.
The following line (invoked as a consequence of fold_stmt
devirtualization) in cgraph_update_edges_for_c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58863
Bug ID: 58863
Summary: for loop not aligned at -O2 or -O3
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
--- Comment #1 from Paul Pluzhnikov ---
Created attachment 31084
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31084&action=edit
test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
Bug ID: 58864
Summary: [4.8/4.9 regression] ICE in connect_traces, at
dwarf2cfi.c:
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44646
--- Comment #6 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #1)
> TODO as follow up:
> * Implement type-spec support for "forall" and "do concurrent":
> "(integer(8) :: i = 1:5:2)"
>
> * Try to make use of the constraints for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426
--- Comment #13 from Tobias Burnus ---
Author: burnus
Date: Thu Oct 24 16:25:44 2013
New Revision: 204021
URL: http://gcc.gnu.org/viewcvs?rev=204021&root=gcc&view=rev
Log:
2013-08-24 Tobias Burnus
PR other/33426
* c-pragma.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44646
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Thu Oct 24 16:30:22 2013
New Revision: 204023
URL: http://gcc.gnu.org/viewcvs?rev=204023&root=gcc&view=rev
Log:
2013-10-24 Tobias Burnus
PR fortran/44646
* trans-stmt.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #23 from Paolo Carlini ---
Thanks. I'm sending to the mailing list an updated version, which only proceeds
with do_mpfr_arg1 when !flag_trapping_math && !flag_errno_math.
About the -nan, yes by now we know well that if we don't use mp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #22 from Vincent Lefèvre ---
(In reply to Paolo Carlini from comment #20)
> Thus I clearly realize something: if we do better for mpfr, the issue
> remains that if we do *not* optimize and constants are not propagated, we
> issue libra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58831
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #21 from Vincent Lefèvre ---
(In reply to Paolo Carlini from comment #19)
> If I change fold_builtin_logarithm to pass a true as last argument to
> do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded
> result which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57520
--- Comment #2 from Chunsheng Pei ---
Addition to my previous comments
GCC/clang also reports it could not match f1 at this time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57520
Chunsheng Pei changed:
What|Removed |Added
CC||pei.chunsheng at outlook dot
com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Thu Oct 24 13:54:00 2013
New Revision: 204014
URL: http://gcc.gnu.org/viewcvs?rev=204014&root=gcc&view=rev
Log:
PR c++/58705
cp/
* typeck2.c (check_narrowing): Don't check narro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> The patch will fix the regression part, to be left to optimize is the
> pointer offset association bits which should best be done in GIMPLE
> reassoc which doesn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
Uroš Bizjak changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Summa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #1 from Uroš Bizjak ---
Revision 203876 failed LTO profiledbootstrap [1] with:
../../src-trunk/gcc/genattrtab.c: In function 'simplify_or_tree':
../../src-trunk/gcc/genattrtab.c:2268:1: error: verify_flow_info: Wrong
probability of ed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
Bug ID: 58862
Summary: LTO profiledbootstrap failure: lto1: ICE in
edge_badness, at ipa-inline.c:1008
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58833
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Eric Botcazou ---
>> Would it be possible for GCC in Solaris to auto-configure itself as a 64-bit
>> native compiler by default (instead of the current 32-bit native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #20 from Paolo Carlini ---
Thus I clearly realize something: if we do better for mpfr, the issue remains
that if we do *not* optimize and constants are not propagated, we issue library
calls, which, for command line switches like -fno-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #19 from Paolo Carlini ---
If I change fold_builtin_logarithm to pass a true as last argument to
do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded result
which is infinity, things finally work. Patchlet below. Not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
--- Comment #6 from David Edelsohn ---
Author: dje
Date: Thu Oct 24 12:53:51 2013
New Revision: 204009
URL: http://gcc.gnu.org/viewcvs?rev=204009&root=gcc&view=rev
Log:
Backport from mainline
2013-10-23 David Edelsohn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #18 from Paolo Carlini ---
Now the question is: why we use a library call for log(0) instead of mpfr?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #17 from Paolo Carlini ---
If I play with some constexprs, I understand that, irrespective of the command
line switches, we never fold to a constant the log. However, only for
-fno-math-errno -funsafe-math-optimizations the library cal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #16 from Paolo Carlini ---
Uhm, something isn't going as planned. If I change that check in do_mpfr_arg1
to
!real_isnan (ra), then we always fold __builtin_expl(-__builtin_huge_vall()) to
an exact 0.
However, with *both* -fno-math-err
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
Bug ID: 58861
Summary: No reallocation assignment performed (due to different
kinds?)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #11 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> That is still wrong, __builtin_unreachable is still very much useful even at
> the RTL level (where we expand it as basic blocks without successors).
> Perhaps if-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58852
Sarantis Pantazis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282
--- Comment #8 from vries at gcc dot gnu.org ---
Also required for 4.7 and 4.8.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58859
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|meng at g dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58860
Bug ID: 58860
Summary: tail-merge doesn't merge asm statements with vdef
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58856
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839
--- Comment #3 from Paolo Carlini ---
Yes, as you can see Jonathan is already on it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58805
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839
--- Comment #2 from Andriy Lysnevych ---
Hi Paolo,
You are right. It is not yours commit but next one.
__r.get() returns T* and construction *__r.get() works for any type except the
case when T=void. It causes dereferencing of void pointer that
66 matches
Mail list logo
